Ian, Thanks for this information. It'll help me and I hope It'll help others that need to use the STR7xx. > 1) USB - does not meet the USB spec. in several areas. No endpoint > pairing. limited endpoint numbering. VERY awkward interface. > Incorrect documentation or correct documentation with incorrect > operation.... I think I'll completely avoid the STR7xx version that has USB. (I'll use the LPC.) USB is enough of a can of worms without poorly implemented silicon. > 2)Timers. Registers need to be set in a specific sequence. This not > documented but we learned this from taking apart the C code. The > timers reset to FFFA ??? of all things and the timers can't be > triggered on less then 5 (=0000-fffa). I thought that the reset to FFFA was lame. Why would the designers implement it that way? (Probably covering up some bug.) > 3)SPI - there are bugs and there is no documentation! Works in master > mode but slave is unpredictable. The problem I think we had was the > slave select signal not meeting some timing requirements. ST agreed > that was likely. There are no timing specs. > After enough emails and calls this is what I got from ST FAE: >>by experiment: SS must be low before the first active clock edge. >>Setup time is less than 24nS. These are not the official datasheet >>numbers but found thru experimentation. SS must also be low during >>setup of the slave port library call: >> >> /* Configure the clock to be active high */ >> BSPI_ClkActiveHigh(BSPI1,ENABLE); >> >> I also found this thru experimentation. Thanks. Sounds like more silicon design problems. > 4)Clock system - 3 clocks. each peripheral has it's own max clock. > so you need to mix and match. Frustrating. The clock/PLL settings that I have right now work. But I found a few of the settings not by design (which didn't work) but by experimentation. > 5) No serial port ISP. > 6) 6 extra pins and 3 extra caps for the core's 1.8V supply > 7) The 1.8V Core backup supply(required) is not very useful since the > minimum RAM retention voltage is 2.7V Didn't even notice this on my pass through the data sheet. I appreciate the heads-up. > 8) the STR71 requires external clocks (not crystals). Needs two if > you want USB Needs 32 kHz xtal for the RTC. 9) The RTC is simply a 32bit register that counts up once per second. This works, but reminds me of the 1980's. Modern RTCs have year/month/day/hour/minute/second registers. Access to the RTC isn't straight forward, either. 10) The ADC is unusable in the design I'm working on. The digital result is signed. (Why?) 0V is about 350 counts up on my chip, and needs calibration for each chip. 2.5V is hundreds of counts down from the top, again unique numbers per chip and needing calibration. I assume that this floats around with temperature changes. MUCH of this chip (the peripherals, not the ARM core) appears to be poorly thought out. Again, like the RTC, a lot of it looks like "1980s technology". > On the plus side, there are complete libraries that work well - > mostly. In contrast the example code is not clear and not commented > (I want to read example code - not decode it) I'm avoiding more and more of the libraries. > If you check the STR71x forum, you will find several instances of the > ST ARM expert moderators explaining that something has already been > fixed in the next lib release, and then users begging for the release > to be released. In general I think the ST forum (or the LPC2000) > would be a good place to do research to separate fact from marketing. > ST is new to ARM7 and their STR71 parts remind me of the early PICs > in their ridiculously complex peripheral interface. Documentation is > very poor VERY poor. I miss the LPC. The peripherals are of poor quality. Almost an embarrassment to use with the ARM core. > The majority of the problems we had were related to the peripherals > but there are hardware issues too. I would suggest investigating the > implementation details of any design that might be applied to the > STR7. > Sorry, that became a bit of a rant. Rant away. I appreciate it very much. I hope that this helps the LPC users here in this forum appreciate the LPC. :-) -Rob www.usbmicro.com > Ian > --- In lpc2000@yahoogroups.com, rob@u... wrote: >> >> >> Ian, >> >> > Sorry, not an answer to your question but my experience with the > STR7 >> > made me switch to the LPC2148 half way through a project. The > STR7s >> > are very buggy and have little or no documentation and each >> > peripheral is overly complicated. I would suggest a careful look > at >> > the STR7 details before you jump in (power supply,clock system, > USB, >> > Timers, SPI ...) >> >> Normally I prefer the LPCs, but right now I'm working on a STR7xx >> design. Can you elaborate on the STR7xx problems that you have had? >> You can email me privately if you wish. (Or reply here to let people >> know why the LPC is better...) >> >> I'd like to get any warnings of problems that I can BEFORE I spend a >> big chunk of time finding them myself. >> >> -Rob >> www.usbmicro.com >> >> > --- In lpc2000@yahoogroups.com, Herbert Demmel <dh2@d...> wrote: >> >> >> >> Hi Guys, >> >> >> >> does anybody have some information when the LPC23xx chips will > come >> > out? >> >> >> >> Currently the only ARM7 with external bus + USB + flash + RAM is >> > the STR7 >> >> as far as I know. I have to plan resources for a upcoming new >> > product, so I >> >> really would like to know, when one can get samples of this chip. >> > It has >> >> been already announced a long time ago to come in the 2nd quarter >> > of 2005 ... >> >> >> >> Regards >> >> Herbert Demmel >> >> >> >> ---------------------------------------------------------- >> >> demmel products >> >> Radnitzkygasse 43 >> >> A-1100 Vienna / Austria / Europe >> >> Voice: +43-1-6894700-0 >> >> Fax: +43-1-6894700-40 >> >> Email: dh@d... >> >> WWW: http://www.demmel.com >> >> >> >> >> >> >> >> >> >> >> > Yahoo! Groups Links >> > Yahoo! Groups Links
Message
Re: [lpc2000] Re: LPC23xx - when ???
2005-12-22 by rob@usbmicro.com
Attachments
- No local attachments were found for this message.