Rob Gaddi wrote:>NXP LPC111x is a 50 MHz Cortex-M0. It's available in a 5x5mm QFN and isI prefer visible solder joints if possible. The LPC111x are avaliable also in TSSOP20.>+/-1% over -40 to 85. It's got a 10-bit ADC that will do 400ksps and >has an 8 channel mux out front.Yes, that's great, but they seem to be rather picky regarding power supply: "The device might not always start-up if the power supply (on the VDD pin) does not reach 200 mV. The minimum voltage of the power supply ramp (on the VDD pin) must be 200 mV or below with ramp-up time of 500 ms or faster". That's very bad. Another disadvantage (especially for small cases) is that the cyrstal oscillator pins can't be used for I/O. Oliver -- Oliver Betz, Munich http://oliverbetz.de/
Small controller with good on-chip oscillator
Started by ●February 21, 2013
Reply by ●February 24, 20132013-02-24
Reply by ●February 24, 20132013-02-24
On 2013-02-24, Oliver Betz <OBetz@despammed.com> wrote:> Grown up with 6502, using 68HC-something and Coldfire (rest in peace) > for two decades, I hesitate (but don't refuse) to use 8051 controllers > today. My preferred path is ARM Cortex.If you like to check out (disassembly or compiler listing) the code produced by a C compiler, don't use a 8051. ;-( Well, even if you don't do this, the architecture isn't good for C. (Very limited stack space, only one or two pointers for accessing "external" memory etc.) Sure, it works, kind of, but you can't write "normal C" for these chips. ARM is good. A 4 GB linear memory space, 32-bit registers, etc. Your C compiler will thank you. ;-) -jm
Reply by ●February 25, 20132013-02-25
Jukka Marin wrote:>> Grown up with 6502, using 68HC-something and Coldfire (rest in peace) >> for two decades, I hesitate (but don't refuse) to use 8051 controllers >> today. My preferred path is ARM Cortex. > >If you like to check out (disassembly or compiler listing) the code produced >by a C compiler, don't use a 8051. ;-( Well, even if you don't do this,and not GCC - I strongly disliked it's output for Coldfire. So much unneccesary re-ordering. And the mixed output was completely out of sync (IIRC a long standing bug). Can't wait to check the Cosmic compiler for ARM Cortex. Oliver -- Oliver Betz, Munich despammed.com is broken, use Reply-To:
Reply by ●February 26, 20132013-02-26
On 25/02/13 10:51, Oliver Betz wrote:> Jukka Marin wrote: > >>> Grown up with 6502, using 68HC-something and Coldfire (rest in peace) >>> for two decades, I hesitate (but don't refuse) to use 8051 controllers >>> today. My preferred path is ARM Cortex. >> >> If you like to check out (disassembly or compiler listing) the code produced >> by a C compiler, don't use a 8051. ;-( Well, even if you don't do this, > > and not GCC - I strongly disliked it's output for Coldfire. So much > unneccesary re-ordering. And the mixed output was completely out of > sync (IIRC a long standing bug). >Which Coldfire core were you using? For the bigger cores, re-ordering can make a big difference to the throughput as instructions can be overlapped in the longer pipelines. gcc does not re-order instructions just for fun - it does it because it considers instruction scheduling and memory access patterns to get the fastest code. And of course, you can control the amount of instruction scheduling via optimisation switches (at least to some extent). I found that for some gcc versions (I can't remember which versions or which targets), mixed assembly output could get out of sync - especially with "-fverbose-asm". Using the "-nopipe" option seemed to help, IIRC.> Can't wait to check the Cosmic compiler for ARM Cortex. > > Oliver >
Reply by ●February 27, 20132013-02-27
David Brown wrote:>>> If you like to check out (disassembly or compiler listing) the code produced >>> by a C compiler, don't use a 8051. ;-( Well, even if you don't do this, >> >> and not GCC - I strongly disliked it's output for Coldfire. So much >> unneccesary re-ordering. And the mixed output was completely out of >> sync (IIRC a long standing bug). > >Which Coldfire core were you using? For the bigger cores, re-orderingCF V2 "Kirin 3" (52255).>can make a big difference to the throughput as instructions can be >overlapped in the longer pipelines. gcc does not re-order instructions >just for fun - it does it because it considers instruction scheduling >and memory access patterns to get the fastest code. And of course, youConsecutive accesses to "off-platform" peripherals in the Kirin 3 have up to 12 wait states, but much less (4?) if there is enough time between. GCC delayed all write accesses to the latest possible moment (e.g. function exit) resulting in much slower execution.>can control the amount of instruction scheduling via optimisation >switches (at least to some extent). > >I found that for some gcc versions (I can't remember which versions or >which targets), mixed assembly output could get out of sync - especially >with "-fverbose-asm". Using the "-nopipe" option seemed to help, IIRC.thanks for the hint, although I don't expect to continue Coldfire development since Freescale prefers ARM Cortex now. Oliver -- Oliver Betz, Munich despammed.com is broken, use Reply-To:
Reply by ●February 27, 20132013-02-27
On 27/02/13 11:20, Oliver Betz wrote:> David Brown wrote: > >>>> If you like to check out (disassembly or compiler listing) the code produced >>>> by a C compiler, don't use a 8051. ;-( Well, even if you don't do this, >>> >>> and not GCC - I strongly disliked it's output for Coldfire. So much >>> unneccesary re-ordering. And the mixed output was completely out of >>> sync (IIRC a long standing bug). >> >> Which Coldfire core were you using? For the bigger cores, re-ordering > > CF V2 "Kirin 3" (52255). > >> can make a big difference to the throughput as instructions can be >> overlapped in the longer pipelines. gcc does not re-order instructions >> just for fun - it does it because it considers instruction scheduling >> and memory access patterns to get the fastest code. And of course, you > > Consecutive accesses to "off-platform" peripherals in the Kirin 3 have > up to 12 wait states, but much less (4?) if there is enough time > between. > > GCC delayed all write accesses to the latest possible moment (e.g. > function exit) resulting in much slower execution.Unfortunately, gcc only knows about the core cpu, and (AFAIK) will only consider pure cpu cycles and latencies when scheduling. There is no way for a compiler to know about off-cpu wait states. People often think they can force the timing and ordering of execution and data accesses by using "volatile" - typically, peripherals will use "volatile" accesses. But remember that "volatile" only influences ordering with respect to other volatile accesses - it does not affect ordering with respect to calculations or non-volatile accesses. So if you have a write to a peripheral and you want it to be dealt with /now/, you have to use a memory barrier as well.> >> can control the amount of instruction scheduling via optimisation >> switches (at least to some extent). >> >> I found that for some gcc versions (I can't remember which versions or >> which targets), mixed assembly output could get out of sync - especially >> with "-fverbose-asm". Using the "-nopipe" option seemed to help, IIRC. > > thanks for the hint, although I don't expect to continue Coldfire > development since Freescale prefers ARM Cortex now. >I too used to be a big Coldfire fan (and 68332 before that), but it does not look like the architecture has a bright future. We use MPC cores for some parts, and are moving to Cortex for many others (in the 32-bit space).> Oliver >
Reply by ●February 27, 20132013-02-27
David Brown wrote:>> Consecutive accesses to "off-platform" peripherals in the Kirin 3 have >> up to 12 wait states, but much less (4?) if there is enough time >> between. >> >> GCC delayed all write accesses to the latest possible moment (e.g. >> function exit) resulting in much slower execution. > >Unfortunately, gcc only knows about the core cpu, and (AFAIK) will only >consider pure cpu cycles and latencies when scheduling. There is no way >for a compiler to know about off-cpu wait states.I didn't expect this, but I can imagine a compiler not delaying accesses without benefit. If the value isn't needed later, what is the reason to delay writing it?>People often think they can force the timing and ordering of execution >and data accesses by using "volatile" - typically, peripherals will use >"volatile" accesses. But remember that "volatile" only influences >ordering with respect to other volatile accesses - it does not affectI'm aware of this. Oliver -- Oliver Betz, Munich despammed.com is broken, use Reply-To:
