NXP's DIP28 ARM chip isn't Vaporware anymore

[bingo600]

Yummy
http://hackaday.com/2012/09/09/the-easiest-way-to-dive-in-to-arm-programming/

If they only were to get here in EU land 
I mean at a decent shipping cost.


/Bingo

[HardBoot]

I sooo wish there were more DIP ARM chips... imagine ARMduino... would cost about the same and have the power to drive little DIY consoles/computers.

[PeterG]

These look like nice boards.

http://dx.com/p/open103z-standard-stm32f103zet6-stm32-arm-cortex-m3-scm-development-board-w-pl2303-usb-uart-module-148517?item=194

Regards

[cwalex]

I sooo wish there were more DIP ARM chips... imagine ARMduino... would cost about the same and have the power to drive little DIY consoles/computers.

Digilent make some 32bit arduino compatible boards. Not ARM but still pretty powerful, and cheap.

http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,892&Cat=18

[westfw]

the NXP ARM-in-a-DIP chip has "only" 32kB of flash space.  Am I wrong to be worried about that?  It's not so much that I expect 32bit RISC code to end up much larger  than 8bit code for typical algorithms, but my observation is that there tend to be more complex peripherals associated with the ARM chips, and just initializing everything takes a significant amount of space.  (Arduino's "BLINK" sample is about 1k on an AVR, and 5k on PIC32, for example.)  Add a larger ISR and function prolog/epilog, and the fact  that algorithms code up to similar sizes may be irrelevant to typical microcontroller applications ("Algorithms?  What algorithms?  I initialize X, Y, and Z and shovel bytes around...")

[mikeselectricstuff]

the NXP ARM-in-a-DIP chip has "only" 32kB of flash space.  Am I wrong to be worried about that?  It's not so much that I expect 32bit RISC code to end up much larger  than 8bit code for typical algorithms, but my observation is that there tend to be more complex peripherals associated with the ARM chips, and just initializing everything takes a significant amount of space.  (Arduino's "BLINK" sample is about 1k on an AVR, and 5k on PIC32, for example.)  Add a larger ISR and function prolog/epilog, and the fact  that algorithms code up to similar sizes may be irrelevant to typical microcontroller applications ("Algorithms?  What algorithms?  I initialize X, Y, and Z and shovel bytes around...")

Code density on ARMs is fairly comparable to 8-bit, especially with the various Thumb variants. 32K is plenty. 1k/5k for blinking LEDs is just the result of a bad (or badly configured) compiler that includes unnecesary library functions in the final code.  Although initialisation can take more space, more complex peripherals may well end up saving handler code, and you're rarely using a large proportion of the peripherals on any given design.

[nctnico]

the NXP ARM-in-a-DIP chip has "only" 32kB of flash space.  Am I wrong to be worried about that?  It's not so much that I expect 32bit RISC code to end up much larger  than 8bit code for typical algorithms, but my observation is that there tend to be more complex peripherals associated with the ARM chips, and just initializing everything takes a significant amount of space.  (Arduino's "BLINK" sample is about 1k on an AVR, and 5k on PIC32, for example.)  Add a larger ISR and function prolog/epilog, and the fact  that algorithms code up to similar sizes may be irrelevant to typical microcontroller applications ("Algorithms?  What algorithms?  I initialize X, Y, and Z and shovel bytes around...")

ARM-Cortex uses the 16 bit Thumb2 instruction set which is very compact. Using the thumb1 instruction set I managed to put a TCP/IP stack, BSD socket layer, DNS resolver, DHCP client, telnet client, web server, web client and an application into 32k of flash. Its just a matter of keeping things compact. On a Cortex you don't have to worry about interrupt routines at all. Pushing & popping is completely handled by the hardware. Just feed the interrupt controller an address of a standard C routine and everything works fine. NXP is going to pull in a lot of Microchip's business with this chip.

[gxti]

I'm using 10K out of 32K on a STM32 project right now, most of that is standard library stuff that never gets called that gcc does not trim out.  And that's after omitting all the files for peripherals I'm not using. That said, incremental changes to my code don't increase the size much at all, so figuring out how to chop down the peripheral library should reclaim quite a lot of space. If someone knows how to do it with gcc, don't hold back :-)

[nctnico]

I use the standard C library that comes with MSPGCC which I compiled for ARM. Dunno about the latest version but when I created my version it required editing the makefile. I'm quite sure an IDE (like Eclipse) can turn the seperate files into a single library as well. The key thing to know is that each C library function should reside in its own C file so the library becomes a collection of seperate objects. The linker will only link in the objects which are referenced from the project.

In most cases printf causes the inclusion of about 2k of libraries. If you don't need fancy formatting than you can write your own printf function. Here is a starting point: http://www.xappsoftware.com/wordpress/2011/01/17/a-tiny-printf-for-embedded-systems/

[andersm]

That said, incremental changes to my code don't increase the size much at all, so figuring out how to chop down the peripheral library should reclaim quite a lot of space. If someone knows how to do it with gcc, don't hold back :-)

Use -ffunction-sections when compiling, and --gc-sections when linking.

Using printf and friends can cause the floating-point math emulation libraries to be pulled in. Newlib has special integer-only versions (iprintf etc.) to avoid that issue.

[gxti]

Magnificent! Went from 11254 bytes to 5334 bytes. Very handy because I fried the 32K flash part I was using, and snipped it off and replaced it with a 16K part because I only had one 32K part left and was afraid it might get blown up immediately, too. So now I have breathing room still.

[Psi]

On a Cortex you don't have to worry about interrupt routines at all. Pushing & popping is completely handled by the hardware. Just feed the interrupt controller an address of a standard C routine and everything works fine

wow, that's pretty awesome.

[nctnico]

Even more awesome is that you don't need any assembly code to start the processor. You can do the entire initialisation in C code. In the beginning of the flash there is an array which has the reset vector (pointer to main), address of the stack and the interrupt vectors. You can use an array of pointers to fill it:

Code: [Select]

//Interrupt table. First entry is the stack pointer the 2nd points to main
const TCortexIrq CortexIrq  __attribute__((section("vectors"))) ={
.__initial_sp=(uint32_t) _data + 4092, //SP at the end of the memory
.Reset_Handler=(uint32_t) main,
.HardFault_Handler=(uint32_t) hardfault_handler,
.TIMER32_0_IRQHandler=(uint32_t) timer_handler,
//.I2C_IRQHandler=(uint32_t) i2c_irq_handler,
.UART_IRQHandler=(uint32_t) UART0_IRQHandler,
};


[firewalker]

Is ARM PITA using free software (gcc toolchain)? I had a quick look and I thing it PITA to set it up for a particular ARM micro. In GNU/Linux (and for Win32 with WinAVR) for example the AVR family set up is really trivial. I am not comparing of course.

An IDE like Keil, CrossWork, IAR is the way to go starting with ARM micros?

(I should start a new thread probably)

Alexander.

[ElektroQuark]

Yes, firewalker, please, start a new thread. I'm interested too in the subject.

[poorchava]

Too bad that it's AVNET generally sells bulk quantities. For some stuff they offer lower quantities, but the shipping cost is outrageous ($60 for shipping from EU warehouse to another country in EU?!?!)

[T4P]

Too bad that it's AVNET generally sells bulk quantities. For some stuff they offer lower quantities, but the shipping cost is outrageous ($60 for shipping from EU warehouse to another country in EU?!?!)

We'll wait for digikey and farnell then 

[westfw]

[on cortex] Pushing & popping is completely handled by the hardware.

Well, for half the registers.  If the compiler ABI handles the other half, that's swell.

I have to admit that AVR is particularly annoying in the amount of code used for ISR prologue/epilogue.   A whole lot of vectors, and a whole lot of registers to save for each one...

[Trigger]

Arrow has them in stock for US$1.51
http://components.arrow.com/part/detail/52563173S13441N7788

[rolycat]

Arrow has them in stock for US$1.51
http://components.arrow.com/part/detail/52563173S13441N7788

Does anyone know why those 'in stock' components have a 12-week lead time?

Availability
In Stock:
(Ready to Ship) 556
Lead Time:  12 Weeks




 

[enz]

Arrow has them in stock for US$1.51
http://components.arrow.com/part/detail/52563173S13441N7788

Does anyone know why those 'in stock' components have a 12-week lead time?

Availability
In Stock:
(Ready to Ship) 556
Lead Time:  12 Weeks

If you would order for example 1000pcs you would only get the 556pcs from stock and have to wait 12 weeks for the remaining 444pcs.

Martin

[mrflibble]

These look like nice boards.

http://dx.com/p/open103z-standard-stm32f103zet6-stm32-arm-cortex-m3-scm-development-board-w-pl2303-usb-uart-module-148517?item=194

Regards

Took a look at it just now, but it does seem to be a tad pricey... Certainly compared to some of the boards being pushed by ST, TI et al.

[Trigger]

Arrow has them in stock for US$1.51
http://components.arrow.com/part/detail/52563173S13441N7788

Does anyone know why those 'in stock' components have a 12-week lead time?

Availability
In Stock:
(Ready to Ship) 556
Lead Time:  12 Weeks

The Lead Time is how long it takes them to get more.  I've already ordered and received 20 chips from them.  They shipped hours after I'd made the order.

[westfw]

Arrow has them in stock for US$1.51

Oh my.  I don't recall seeing the MSRP before.  at $1.50, this thing is suddenly more interesting, even if the package is a bit surprising in its wide-ness.

[saigai]

If they only were to get here in EU land 
I mean at a decent shipping cost.

This is the reason I probably won't get to play with a dip arm for a long time.. will have to wait until the Chinese start selling it on ebay with free shipping. Samples from NXP are also out of question.

Meanwhile.. thumbs up to TI for sending me free samples of their stuff, free shipping!