The Embedded Pi: good hardware but how to use?

[uberscubajim]

[edit to add this paragraph] This thread refers to the Embedded Pi product sold by Farnell/Element 14. It's web site is here:
http://www.coocox.org/epi.html

I just bought one of these at the Elephant and Castle Mini Maker Faire (which was excellent by the way).

The hardware looks excellent and has the potential to be very interesting.

However, there is (as far as I'm concerned) a fatal flaw. In order to program the ARM processor on the board you need to use a Windows development environment. For me this is a terrible flaw! Not being able to use the Pi itself to program the chip is a real, major serious issue. This is a frightful pity as it spoils what would otherwise be an excellent little piece of hardware.

There also seems to be some associated issues with how you get your compiled code onto the ARM on the board. There is significant talk of have to use an embedded systems programmer (more hardware?). This doesn't seem like a very good idea.

Now, of course, the entire point of this forum is solutions. Clearly the Pi itself is more than capable of compiling code for the M-series ARM on the board (it's a compiler option, specifically -march=cortex-m3 I believe) and the CooCox operating system is open source. So no problem creating object code then! I'm sure there must be some way of uploading it to the processor (using the serial port has been mentioned).

I'm not looking for a fancy IDE (to starting) just a simple GCC, link and upload will get us started.

Any thoughts on this from anyone? Especially CooCox themselves!

Regards,

Jim.

[joan]

Never understood the point of that add-on for the Pi.

[uberscubajim]

Well... In theory it's a nice idea. The embedded ARM can do the real-time work (in a similar way that an Arduino would) but with significantly more processing power. It can then talk to the Pi over a faster interface (I'm assuming it connects SPI or I2C here).

At least in theory it's a good example of having a “real time” co-processor. However, the Windows dependence severely restricts it and is a terrible loss.

Jim.

[Twinkletoes]

There is NO Windows dependence. You can plugin a keyboard and mouse directly into the pi and program in vi or nano or any other text editor and compile in gcc.

You can also cross compile from a PC or Mac running either Windows or Linux.

You can ssh from any device and program from there if you want to do it remotely.

So you have choices. You can do it whichever way you want. No extra hardware (apart from keyboard, mouse and screen) required.

[uberscubajim]

So, how can I program the Cortex-M3 on the embedded Pi from Raspbian? The IDE coocox provide is windows specific.

Remember, I'm not talking about the Broadcom ARM on the Pi, I'm talking about the STMicroelectronics M3 on the add-on board.

[jamesh]

So, how can I program the Cortex-M3 on the embedded Pi from Raspbian? The IDE coocox provide is windows specific.

Remember, I'm not talking about the Broadcom ARM on the Pi, I'm talking about the STMicroelectronics M3 on the add-on board.

I think some sort of link to what you are actually talking about may help - because It also initially thought you were talking about programming the Raspi itself.

[Twinkletoes]

Sorry, misunderstood. Might come from the fact that I'm using the Pi as an embedded platform without any add on boards.

[joan]

See http://www.raspberrypi.org/phpBB3/viewt ... 10#p378110 and other posts by the same guy.

[uberscubajim]

It was those posts that indicated the need for a Windows PC.... It just emphasises the problem.

[joan]

It was those posts that indicated the need for a Windows PC.... It just emphasises the problem.

I just posted the link for the benefit of those who wondered which unit was being talked about.

[uberscubajim]

I've come to the conclusion that although the hardware looks very interesting and there's no problem with the design the dependence on Windows effectively ruins it. This is a great pity!

What makes it worse is that from initial look the potential is great but the specific implementation has fatal drawbacks. If there were a Pi-based ability to compile code for the ARM M3 on the board then it would be a great product.

[elektrknight]

What makes it worse is that from initial look the potential is great but the specific implementation has fatal drawbacks. If there were a Pi-based ability to compile code for the ARM M3 on the board then it would be a great product.

What are you talking about?

You just login on the Raspbian based Pi and use built-in compiler to built your Cortex-M3 code ex: "test.c" with these options:

Code: Select all

gcc -mcpu=cortex-m3 -mthumb -c test.c

Granted you need to have support libraries for your MCU but these days CMSIS takes care of that http://www.arm.com/products/processors/ ... andard.php plus there is a myriad of other open source resources.

[uberscubajim]

Thanks for that reply.

I know that I can compile code using the Pi's compiler. What's missing are suitable run-time libraries (the libc type stuff), perhaps some other libraries to make talking to the hardware easier (as provided by CoIDE on Windows) and a method for uploading that software onto the M3 on the board (though I believe there is a python program called something like stm32load that does this, it looks like there's some form of serial loaded on the board like optiboot on the Arduino).

I hadn't heard of CMSIS before your posting (thanks for the pointer!) and I guess that's my big problem. It would have been very nice to have had some details with the board rather than a Windows-based IDE. In fact, looking at CMSIS it looks to be just the job!

What I love about the Pi (and I'm a great fan) is the ability to solve problems by coming to the boards here. What I dislike about the Embedded Pi is that I need to. A very few pointers in the documentation and all this could have been avoided.

[elektrknight]

What's missing are suitable run-time libraries (the libc type stuff)

libc - grab newlib nano https://github.com/32bitmicro/newlib-nano-1.0 liberated from GCC ARM Embedded toolchain by yours truly

a method for uploading that software onto the M3 on the board

Serial - stm32flash by Geoffrey McRae will do fine http://code.google.com/p/stm32flash/

USB - make friends with gnumonks and dfu-util at http://dfu-util.gnumonks.org/

ST-Link - nicely handled by texane's stlink https://github.com/texane/stlink

JTAG Debug - can not go wrong with OpenOCD and gdb http://openocd.sourceforge.net/
You could even use GPIO pins on P1 to implement bit-banged JTAG interace to your
MCU. Gives you full JTAG for the price of couple of wires, but you need to be a bit
careful when you do it and you have not heard it from me

I hadn't heard of CMSIS before your posting

But you have probably used it

It would have been very nice to have had some details with the board rather than a Windows-based IDE.

When does any IDE give you details? And why would you be using 100+MB of eclipse java bytecode and countless
MB of additional support "fat" to do the job that can be done with a Nano text editor, gcc+gdb plus make or cmake?!

Want to run and debug your code on Raspberry Pi? Then head to QEMU website http://wiki.qemu.org/Main_Page.
Raspi can emulate embedded Cortex-Mx code faster then most of the MCUs run it natively.

What I love about the Pi (and I'm a great fan) is the ability to solve problems by coming to the boards here. What I dislike
about the Embedded Pi is that I need to.

Hm, drop the capital case "Embedded Pi" and start doing embedded pi!
In no time you will be solving real problems instead of trying to figure how to fit a square peg (win32 tool) in a round (Pi) hole.
Well, there is a good example on how to do it in time of crisis, just watch Apollo 13 movie but unlike the astronauts you have
plenty of choices!

[uberscubajim]

Now that's the sort of information I was looking for! Thanks a lot!

So it looks like I'll be writing a blink program from scratch to prove to myself that I can use everything.

I wasn't actually asking for an IDE. Personally I hate them, I'm completely with you on this: I much prefer to drive it all myself from a makefile. And I'm absolutely not wanting an IDE on Windows (as provided by CooCox).

So, with all this information it looks like I should be able to write a basic program for the Embedded Pi (the board) using the tool chain you've described.

I'd just like to point out to all those reading this thread that I'm referring specifically to CooCox's Embedded Pi board (specifically its ARM M3 processor) as sold by Farnell and not to the Raspberry Pi itself. There's been some confusion about this!

[uberscubajim]

Ok, I'm having a really stupid day. I can't figure out that configure parameters to build the nano library on a Raspberry Pi. I've set CFLAGS to be "-mcpu=cortex-m3 -mthumb" but I'm not sure how to set the target constraints.

Of course compiling “hello world” with "-mcpu=cortex-m3 -mthumb" works but I bet it won't download to the M3....

I'm very close to getting all this working! Exciting times. Hopefully others will find this thread so all can benefit. I may even have to write some of it up....

[elektrknight]

.. but I'm not sure how to set the target constraints.

" Embedded Pi" based on STM32F103RB, hm let me see, cloned from The Maple perhaps? http://leaflabs.com/devices/maple/
Just follow the link to the goodies.

P.S.
All this reminds me of this old movie "One Flew Over the CooCox's Nest" or something like that.

[liam_leee]

Hi guys，good news. Now that we've solved the uploading problem to use the Raspberry Pi itself to program the STM32 on Embedded Pi, See the reference：http://www.raspberrypi.org/phpBB3/viewt ... 45&t=49574

[uberscubajim]

Hi elektrknight,

Thanks for the link to the maple documentation and code. I now have a plethora of information and libraries (ARM's CMSIS, newlib nano and now maple). These are indeed excellent resources!

I'm still having difficulty cross-compiling nano on the Pi for the M3. When I run the configure script I need to give the correct flags so that it'll compile for the M3 rather than for the Pi itself. Do you have any suggestions here?

Similarly, it looks like the maple code uses a cross compiler from an x86 linux box. Again, not intrinsically a bad choice and a small tweak should make it able to use the Pis native compiler.

However, what I think we'd all like to see is it native compiled on the Pi. It's so very close! We have the uploader and we can compile code. We even have libraries to control the hardware (thank you maple) as well as do other things.

What's missing is the low-level stuff to turn compiled code and libraries into an executable. In other words driving the linker properly and the crt0/1 stuff (the code that calls main after setting up the stack pointer and anything else you need to do).

On the vague subject of uploading I notice that maple can compile either to flash or ram (flash is the default). However it also notes that flash is where the bootloader is. Is there a problem here with overwriting the bootloader and not being able to upload any more without using JTAG or other ISP tools?

Once again, many thanks for your help!

Regards,

Jim.

[elektrknight]

I'm still having difficulty cross-compiling nano on the Pi for the M3. When I run the configure script I need to give the correct flags so that it'll compile for the M3 rather than for the Pi itself. Do you have any suggestions here?

Already solving real problems

On my Pi I keep all embedded tools in /32bitmicro which explains the "--prefix" and couple other options to configure.
However, if you decide to use newlib-nano I would recommend looking up how to build and configure newlib.
Here is an example for size optimized build.

Code: Select all

  $ ../../newlib-nano-1.0/configure --host=armv6l-unknown-linux-gnueabi --target=arm-none-eabi --prefix=/32bitmicro --with-build-time-tools=/32bitmicro/bin --with-sysroot=/32bitmicro/arm-none-eabi --disable-shared --disable-newlib-supplied-syscalls --enable-newlib-reent-small --enable-target-optspace --enable-multilib --enable-interwork --disable-libssp --disable-nls --with-gnu-as --with-gnu-ld

But there is also a bunch of compile flags needed, again optimizing for size.

Code: Select all

OPTIMIZE="-ffunction-sections \
	-fdata-sections \
	-Os \
	-fomit-frame-pointer \
	-fno-unroll-loops \
	-mabi=aapcs \
	-DPREFER_SIZE_OVER_SPEED \
	-D__OPTIMIZE_SIZE__ \
	-DSMALL_MEMORY \
	-D__BUFSIZ__=64 \
	-D_REENT_SMALL"

OPTIMIZE_LD="-Os"

export CCASFLAGS_FOR_TARGET="-mcpu=cortex-m3 \
	-mthumb \
	-mfix-cortex-m3-ldrd \
	-D__thumb2__"
	
export CFLAGS_FOR_TARGET="-mthumb \
		-mcpu=cortex-m3 \
		-mfix-cortex-m3-ldrd \
		-mfloat-abi=softfp \
		${OPTIMIZE}"
		
export CXXFLAGS_FOR_TARGET="-mthumb \
		-mcpu=cortex-m3 \
		-mfix-cortex-m3-ldrd \
		-mfloat-abi=softfp \
		${OPTIMIZE}"
		
export LDFLAGS_FOR_TARGET=${OPTIMIZE_LD}

As you can see newlib-nano is very customizable.

Similarly, it looks like the maple code uses a cross compiler from an x86 linux box. Again, not intrinsically a bad choice and a small tweak should make it able to use the Pis
native compiler.

All these are just gcc flavors in various candy wrappers, sometimes in more then one.

What's missing is the low-level stuff to turn compiled code and libraries into an executable. In other words driving the linker properly and the crt0/1 stuff (the code that calls main after setting up the stack pointer and anything else you need to do).

That would be the "32bitmicro Embedded Build System".

On the vague subject of uploading I notice that maple can compile either to flash or ram (flash is the default). However it also notes that flash is where the bootloader is.
Is there a problem here with overwriting the bootloader and not being able to upload any more without using JTAG or other ISP tools?

Maple firmware has a secondary bootloader placed in user flash that does some interesting things
with the USB. STM32 built-in bootloader resides in memory that is not part of the user accessible
flash. So you have a choice either use Maple bootloader and for the price of some lost flash blocks
get extra flexibilty or just use the built-in one. Incidentally JTAG based flashing or uploading does
not usually rely on the built-in bootloader code.

[uberscubajim]

So close!

After installing makeinfo (via texinfo) and setting all the environment variables I was able to run configure OK.

However, when I type make it works for a while until the first actual compile which is

arm-none-eabi-cc -B/home/jim/nano/build/arm-none-eabi/newlib/ -isystem /home/jim/nano/build/arm-none-eabi/newlib/targ-include -isystem /home/jim/nano/newlib-nano-1.0-master/newlib/libc/include -B/home/jim/nano/build/arm-none-eabi/libgloss/arm -L/home/jim/nano/build/arm-none-eabi/libgloss/libnosys -L/home/jim/nano/newlib-nano-1.0-master/libgloss/arm -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" -DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. -I../../../../../newlib-nano-1.0-master/newlib/libc/argz -Os -D__NO_SYSCALLS__ -fno-builtin -g -Os -c -o lib_a-dummy.o `test -f 'dummy.c' || echo '../../../../../newlib-nano-1.0-master/newlib/libc/argz/'`dummy.c

when I get:

/bin/bash: arm-none-eabi-cc: command not found

So, very close but not quite there yet. It needs to use the gcc compiler with the correct flags.

Also thanks for the information about the bootloader.

[liam_leee]

Hi ALL, good news. Now we have done the work to compile the Embedded Pi's code just on Raspberry Pi, and program the Embedded Pi just through Raspberry Pi. Even more interesting is we can expend Raspberry Pi's ADC(and later PWM will be too) function with Embedded Pi.

http://www.raspberrypi.org/phpBB3/viewt ... 45&t=52260
http://www.raspberrypi.org/phpBB3/viewt ... 45&t=51499