Good night everyone, I'am reading this forum and the main site for some time, and being an AVR user I got bite by the ARM processors world, after getting one LPCXpresso 1768 board and one STM32 discovery board I would like to know if there are some tutorials in the terms of a getting started, how to flash a led and how to use the basic functions(like timers, adc, dac, spi, i2c and the sorts) of one or maybe both processors, I have a little preference by the ST arm's, because I can see some projects of it in the internet(like the openPilot for example) but none about the NXP arm's, if some one as suggestions about getting started with this powerful processors just let me know.
Thanks in advance to this community, and yours great products like the bus pirate and the logic analyser.
Hi senso -
We have hardware guides for LPC and STM32, but no programming guide yet:
http://dangerousprototypes.com/docs/Mai ... _overviews (http://dangerousprototypes.com/docs/Main_Page#Processor_overviews)
For LPC microbuilder.eu has some extensive tutorials. I'd also guess there's quite a bit of beginner stuff for the STM32 discovery because it's a starter kit.
I have been searching about this for some time, maybe more than 1 month and I dont really know what to do/choose, using a simple compiler like the CodeSourcery I need to create makefiles and I dont know really how to do that, I cant even create makefiles for an avr project :(
For the LPCXpresso there is the codered IDE that compiles up to 128Kb, thats more than enought for what I do, but I think I will chose the STM32 arm's because I can get free samples from then and if I understand correctly they have a serial bootloader in a ROM memory, so I dont need a JTAG programmer(at least not essencial, but I'm following the BusBlaster project and will get one when they are good to use ;) )
So, I think that one of the most complete guides about setting up a toolchain for STM32 arms is the wiki of the OpenPilot project:
http://wiki.openpilot.org/Flight_Softwa ... _Toolchain (http://wiki.openpilot.org/Flight_Software_Development#Development_Toolchain)
Its all very well explained, but I dont really understand if the makefiles are handmade or if the Eclipse IDE takes care of that, and this brings me to my other option, which is the Attolic True Studio, a friend of mine as already shown me how to edit a small config line and add the Yagarto files so the Attolic True Studio will give out the build-size and some other small things, that makes it almost perfect, but I like to know what is going on, so maybe I should try the tutorial from the OpenPilot guys, but then again, makefiles and not really knowing how to even make a simple blinky because I dont know what files I should include to have the CMSIS and the registers definitions up and running for each arm model is intriguing me.
What is your opinion sir?
As far as I know, both chips have a serial bootloader. Some LPCs also have a USB bootloader. The quick start guides have my notes from reading the datasheets, and include the bootloader info on each chip.
I think most make files are copied from other make files and edited as needed. There are tutorials on make for the daring.
Thanks for your comment, I dont understand is if make for the daring is the name of some site or just a reference/idea saying that I should search a bit about it, if its the latter, no problem and I will indeed search about the subject,
After some more reading and searching I think I will settle for the CodeSourcery and Eclipse, and OpenOCD, following this great tutorial:
http://newwiki.openpilot.org/display/Do ... t+on+Linux (http://newwiki.openpilot.org/display/Doc/Software+Development+on+Linux)
I have yet another question to you, the BusBlaster can be used as an JTAG programming tool, right?
And it will work with the OpenOCD at least to program Arm chips, and CPLD's as after reading about then here I got some curiosity about then!
EDIT: I have been reading the Wiki about the BusPirate and it says it can also act as an Jtag programmer, that would be awesome, the BusPirate looks like a great tool for general testing and hacking, having it act also as a Jtag programmer would be top notch, is this info correct?
[quote author="senso"]
Thanks for your comment, I dont understand is if make for the daring is the name of some site or just a reference/idea saying that I should search a bit about it, if its the latter, no problem and I will indeed search about the subject,
[/quote]
"for the daring" = "for the adventurous" or "for those who are prepared to learn something new".
I've been programming in C on and off for three decades and rarely use makefiles. On the odd occasion that I have, they're very simple :) They're very convenient for software distribution as they enable an end user to compile and install a program with a simple "make install" (assuming the Unix Gods are smiling) without really needing to know C or anything else other than how to find a terminal, unarchive a file and type "make install". I also use makefiles occasionally to document various compiler and linker options for external libraries not of my making (otherwise I'm liable to forget the magic incantation to make it all work).
I guess what it all boils down to is: you should probably learn enough to make a simple makefile, but there's really no need to be toooo daring :)
I have yet another question to you, the BusBlaster can be used as an JTAG programming tool, right?
And it will work with the OpenOCD at least to program Arm chips, and CPLD's as after reading about then here I got some curiosity about then!
Yes, that is correct. Bus Blaster is a high-speed JTAG debugger that is designed to work with OpenOCD and urJTAG 'out of the box'.
EDIT: I have been reading the Wiki about the BusPirate and it says it can also act as an Jtag programmer, that would be awesome, the BusPirate looks like a great tool for general testing and hacking, having it act also as a Jtag programmer would be top notch, is this info correct?
I would not recommend the Bus Pirate JTAG for a beginner. There are some tutorials on the wiki, but lots of people still struggle with it.
Edit: and it's super duper slow too.
Do you have a release date for the BusBlaster?
I hope that in the future I can also help in the development of this great projects, I have some (very very) basic knowledge about makefiles, but only simple ones to use the gcc compiler and only to compile files in my computer, nothing about cross-compiling, but I can get some help for my teachers and some friends.
Last year I used an old 80186 dev-board made by my university and for the ease of use of the Assembler I made a little makefile, but it had only 4 lines, so it was very simple to create.
Thanks for your suggestions, mr. Ian and mr.Trev.
Bus blaster v1 should be available soon for $35 or so. Bbv2 is going to production now, and will be available in 4 to 5 weeks.
I will wait for v2, I dont have no rush ;)
Thanks again.
In sifting thru the world of inbeded DSP, a couple of interesting ARM related aspects came into view. a. That TI offers floating-point DSP inbedded with ARM. b. That 3D graphics are offered as an inbedded feature with DSP and ARM. Re: OMAP35x Graphics SDK 3
Does anyone have interests or experience in either of the cited aspects?
It would be very, very keen to combine these features to obtain a common support and source strucure for this combo. This relative to my interest of bringing these features together for a Precision Analog application and for lab purposes in general. As of yet, the fit of other parameters for AP remain to be evaluated.
The 3D graphics are a natural application to display FFT result repetitions as a spectrogram of frequency versus time versus amplitude. Sometimes this is called a waterfall display. (Color does not interest me.)
[quote author="Bustar"]Does anyone have interests or experience in either of the cited aspects?[/quote]I have interest, but no direct experience yet. I am actively working on a TMS320VC5506 project, and I would like to learn ARM at the earliest opportunity. The TI options that you mention have been on my list of things to do for quite a while. Currently, the USB support in the C5506 means that I can combine all of the programming into a single firmware, so my current design does not have a second processor.
That raises a question for me: Is the TI DSP+ARM product line something that the programmer sees as two processors? ... or just one? I mean, do you end up writing a DSP firmware that talks to the ARM for control, and then ARM firmware that exchanges data with the DSP and controls displays and USB and other higher-level features?
I'm also just starting with ARM, with the STM32VLDISCOVERY board.
As I have minimal experience with MCU's (and programming in C) I'm sticking with Atollic and/or Keil uVision (ST provides step-by-step tutorials to get these up and running) and using the Standard Peripheral Library examples to get the hang of the programming part of things.
There are examples for most peripherals in de firmware package (from [url=http://www.st.com/internet/evalboard/product/250863.jsp]http://www.st.com/internet/evalboard/product/250863.jsp (http://http://from%20http://www.st.com/internet/evalboard/product/250863.jsp)[/url]).
I dont know if u already read through this (http://http://dangerousprototypes.com/forum/index.php?topic=1043.0) topic yet, but lot's of usefull links in there aswell.
senso:
I have used STM32. While it does have a bootloader I didn't find the peripheral library written with low level in mind. They seemed to only be writing for CMSIS, which as far as I understand is this standard to make sure all Cortex M3s play nice, everything was a pointer to a pointer, it was a mess. I started just writing a header file from scratch from the datasheets. It is a nice chip and very available but I didn't love it for sure.
I haven't used the LPCs.
I think Ian mentioned microbuilder.eu, their LPC board stuff looks quite nice. I am finishing up a ARM board that should be available in a month or two that is designed for beginners. It will be more feature rich than most of the microbuilder stuff at similar cost. It is going to be based on a Luminary Micro (now part of Ti) part. The software library is really really good, if you want to just get your feet wet with ARM and can't wait look for an inexpensive development board on Mouser/Digikey for Luminary there is a really basic one for Crossworks I think which you can get a 150 dollar license for personal use to.
If I were just doing personal projects I would use Crossworks because it is very very nice. I remember the kit with the Luminary board was linked to the board so it was probably not even 100 dollars. Depending on what you want on your development board even Ti's are as little as 50 or 60 dollars.
I don't use Crossworks because the commercial license is 1500 ( still way less than the 4000 IAR charges), you can set up your own Makefile/GCC toolchain. I will have tutorials on how to get started with ARM on my board with as little as a TTL serial port, but I am rather busy at the moment. This weekend I am just verifying the final PCB revision.
Edit:
PS, the best STM32 tutorial I ever read was: http://fun-tech.se/stm32/OpenOCD/index.php (http://fun-tech.se/stm32/OpenOCD/index.php)
Many thanks for the link, will read it a few times, and then I will try to install it, and use the Olimex files as a base to tweak to use with the STM32 discovery.
I still dont understand all about the make files, but thats a mather of time (I hope).
Mr.drwho9437 the peripheral lib is not in fact a big big problem for me, I started with Arduino, and 2 weeks later I was using AvrStudio and plain C, and no library bloat from the Arduino crew, it can be good to make something in short time, but all their libs are just a great mess and very slow and made from people that are used to programm in pc's with loads of ram and not a small micro-controller.
I will settle in the future with the ST chips, or if you really think that the TI ones are better, I will switch to TI, as I can get samples from both of then, but not from NXP.
Thanks for all the help provided here!
I think you misunderstand what I mean by peripheral library. By that I meant the header files even to access hardware, in place of *0x1234567 = blah.
The main advantage I see to the STM32 is really that the parts that are made are pretty nicely distributed. Same for LPC. The Ti stuff very few parts that are made are stocked in the big distribution houses.
The STM32 and all ARMs are much more complex to setup than an AVR. For instance the AVR 8-bits have no clock tree. The STM32F103s have them and the connectivity line is different than the performance line in how the clock tree works.
I would be sure that the peripherals you want are there. I wanted USB host, external memory interface and I2S on a chip, STM32 doesn't have any such chips.
To be clear in say AVR you might say something like PORTD = 0xFF; Or uint8_t myvar; myvar = PIND; and it is because of the hard work the AVR Libc folks did.
I never found anything that nice on STM32. There was a header file but all references to memory were via pointers, I forget exactly what the structure was like but was basically GPIOD->REGISTER_NAME = blah or something like that. That might not sound that bad, but I found the examples hard to read until I had put in a solid day on them.
Before deciding on a chip or board, I suggest you write some code and just compile it without the board. This will help you understand what is involved with the toolchain (unless you have plenty of cash then just buy a board).
There are other toolchain things too... for instance in the WinAVR environment you don't have to fool with linker scripts because you just say what the part is and it knows the memory layout.
I have never used Arduino or netduino because the name of the game in embedded land is optimization.
Peripheral libraries for hardware setup are good things, you can waste a lot of time on setting up hardware and performance wise it is a run once when you turn it on kind of overhead. The Ti/Luminary library is quite well optimized actually, the only way to really make it faster would be to code it in ASM or remove some of the safety stuff it does. Some routines check for things but if you know the exact machine state you might avoid the checks and save a few lines of code.
I already have the boards, one STM32 discovery and on LPCXpresso 1768 because they were given to me, so no money spent on them.
Yes, I also know that without Keil or similar software I will have to do a lot of work that I dont usually do to compile a simple program to an AVR, but I'm an electronic and telecommunication student in University, so I'm in the right place to learn, but I will not have much help, in my university they only work with pics and almost all are the 18F family, so talking about ARM's with my professors is a lost cause, but they are gurus using linux and making custom anything runing in linux, so the makefile question will be aided by then, the rest of the compiler chain will be a great challenge to me.
Even without actually creating the compiling tool-chain I have already read some code and its exactly like you say, full of pointers, I can get samples of the 256k flash chips or more, and I will only use the ARM's as an hobby tool, so I might just use what is done in the CMSIS libs, creating those from scratch is really to much for me :/
I only use the arduino as an easy to use breakout board for the atmega328 and the FTDI chip, the rest in done under the AvrStudio, and I dont really understand what you want to mean about optimizing, but the WinAvr uses gcc so it is a optimizing compiler.
In fact I think that the examples have another bad thing, they use 4 or 5 .c and .h files just to make a simply blinky demo, thats pretty irritating to read 10 lines of code in 10 different files.
[quote author="drwho9437"]There are other toolchain things too... for instance in the WinAVR environment you don't have to fool with linker scripts because you just say what the part is and it knows the memory layout.[/quote]That's great if all you need is simple layout of RAM versus I/O and registers. But with the strange memory limitations of the PIC, e.g., you often need the linker script to place certain data structures in specific parts of memory - particularly for USB functions. But I haven't used the USB AVR yet.
[quote author="senso"]
I only use the arduino as an easy to use breakout board for the atmega328 and the FTDI chip, the rest in done under the AvrStudio, and I dont really understand what you want to mean about optimizing, but the WinAvr uses gcc so it is a optimizing compiler.[/quote]An optimizing compiler can mostly only optimize the C code that you write. Beyond a certain point, even an optimizing compiler cannot create efficient code unless your programming is organized in a certain way. The Arduino environment is notoriously inefficient at accessing I/O port registers. I think it's so bad that the port is accessed with really slow bit masks, rather than taking advantage of the hardware. At the opposite extreme, the MPLab environment provides data structures for accessing I/O, and the compiler produces very efficient opcodes that update the port pins in a single cycle. I'm not saying the PIC is more efficient than the AVR, just that you can't use the typical Arduino programming environment if you want the same efficiency. That's the kind of optimizing being discussed.
I know that, an Arduino running Arduino libs takes something like 40 to 80 clock cycles to togle one pin, using the normal programming methods its done in one clock cycle.
Wish me luck, I will now start the Arm gcc toolchain install/build!
I think that I can say sucess!
But I just think, after reading and following the nice tutorial given by mr. drwho9437 I have created/compiled my toolchain, but in this part:
http://fun-tech.se/stm32/gcc/compile_blinky.php (http://fun-tech.se/stm32/gcc/compile_blinky.php)
When the tutorial author says that I should not get any errors or warnings I get this:
tiago@tiago-laptop:~/stm32-example/projects/stm_h103$ make clean
rm crt.lst a.lst main.lst crt.o main.o main.out main.hex main.map stm32f10x_rcc.o stm32f10x_gpio.o
rm: impossÃvel remover `crt.lst': Ficheiro ou directoria inexistente
rm: impossÃvel remover `a.lst': Ficheiro ou directoria inexistente
rm: impossÃvel remover `main.lst': Ficheiro ou directoria inexistente
rm: impossÃvel remover `crt.o': Ficheiro ou directoria inexistente
rm: impossÃvel remover `main.hex': Ficheiro ou directoria inexistente
rm: impossÃvel remover `main.map': Ficheiro ou directoria inexistente
make: [clean] Erro 1 (ignorado)
tiago@tiago-laptop:~/stm32-example/projects/stm_h103$ make
.compiling
arm-none-eabi-gcc -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb main.c
main.c:76:6: warning: conflicting types for 'myDelay'
main.c:61:14: note: previous implicit declaration of 'myDelay' was here
main.c:90:6: warning: conflicting types for 'Clk_Init'
main.c:43:4: note: previous implicit declaration of 'Clk_Init' was here
.compil
arm-none-eabi-gcc -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb stm32f10x_rcc.c
.compili
arm-none-eabi-gcc -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb stm32f10x_gpio.c
..linking
arm-none-eabi-ld -v -Tstm_h103_blink_rom.cmd -nostartfiles -o main.out main.o stm32f10x_rcc.o stm32f10x_gpio.o
GNU ld (Sourcery G++ Lite 2010.09-51) 2.20.51.20100809
...copying
arm-none-eabi-objcopy -Obinary main.out main.bin
arm-none-eabi-objdump -S main.out > main.list
tiago@tiago-laptop:~/stm32-example/projects/stm_h103$
So, I get 4 warnings, the only difference is that I used the most actuall release of CodeSourcery, have I done bad by choosing it?
Yet another twist, I think that while I don’t have a JTAG programmer, and since the LPCXpresso and the Discovery boards both need proprietary software to program then that only runs in Windows I will try to install CoCox, as it supports both boards and I can use the ST-LINK to program the Discovery and FlashMagic as someone said to program the LPCXpresso.
What is your opinion about CoCox?
I think that in fact it boils down to the same things, all of this different compilers and/or IDE's uses gcc and the same libs under the hood, or I'am wrong?
senso,
You can download a compiler for the LPCXpresso from Code-Red Technologies, which will allow you to do anything up to 128K bytes of code. It uses gcc for the compiler, and a custom eclipse for the IDE, and all is in one easy to install package. They have it for Windows and Linux, and it has the software included to program the board you have.
You can also get the CodeSourcery Lite compiler, Eclipse, and the GNUArm plugin for eclipse and you won't need to write makefiles either way. With the CodeSourcery route you will need to find a linker script, but I just used one from the sample code from the NXP site. Dig around a little and you'll find everything you need.
You can also program the NXP chips with a simple USB to ttl serial converter and the lpc21isp program. I have done the LPCXpresso board and my own this way.
LPCXpresso - http://lpcxpresso.code-red-tech.com/LPCXpresso/ (http://lpcxpresso.code-red-tech.com/LPCXpresso/)
CodeSourcery - http://www.codesourcery.com/sgpp/lite/arm (http://www.codesourcery.com/sgpp/lite/arm)
GnuArm plugin - https://sourceforge.net/apps/mediawiki/ ... =Main_Page (https://sourceforge.net/apps/mediawiki/gnuarmeclipse/index.php?title=Main_Page)
LPCXpresso support stuff at NXP - http://ics.nxp.com/support/lpcxpresso/ (http://ics.nxp.com/support/lpcxpresso/)
Info about programming with ISP - http://mbed.org/users/chris/notebook/pr ... -hardware/ (http://mbed.org/users/chris/notebook/prototype-to-hardware/)
Cheap USB to serial ttl cable - http://store.diydrones.com/FTDI_Cable_3 ... 2r-3v3.htm (http://store.diydrones.com/FTDI_Cable_3_3V_p/ttl-232r-3v3.htm)
For STM32 you can use True Studio from atollic, it's Eclipse based, but you have no makefile to handle! everything is automatically handled like on any C project on Eclipse.
and the main advantage is that with TrueStudio there are no flash or code limits ...
http://atollic.com/download/Atollic_Tru ... arison.pdf (http://atollic.com/download/Atollic_TrueSTUDIO_Feature_comparison.pdf)
Regards
Finally got some time to do a fresh install of the CodeSourcery Lite, Eclipse and the suggested Eclipse plugin from the GnuArm project, it all seems to be fine a working, now, I'm with a little trouble, all the examples that I have from STM are just include after include after include of files and I cant even understand why so many included headers and respective sources all scattered around 7 or 8 folders.
Do any one know of a simple project for Eclipse that I can import and do a dummy compile, another thing, how can I define to what micro-controller I want to compile, from what I saw in the Attolic TrueStudio I just select the desired target micro-controller in a list and the IDE does all the house keeping, but using CodeSourcery and Eclipse I don't have those little things, can someone help me?
Many thanks to all the great information that everyone as just posted here!!
EDIT:
I think my problem is using Windows..
Although the old tool-chain that I tried gave some warnings that I couldnt correct, I think that I will switch back to ubuntu and send an email to the script author and see if he can help me.
After another tutorial lol..
https://sites.google.com/site/stm32disc ... evelopment (https://sites.google.com/site/stm32discovery/open-source-development-with-the-stm32-discovery/setting-up-eclipse-for-stm32-discovery-development)
I cant even get started, the STM32 CMSIS compliant lib is non existent in the webs!
Do anyone know where to find it?
I'm pretty sure it's in the STM32VLDISCOVERY firmware pack (AN3268) located right here (http://http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/stm32vldiscovery_package.zip)
Its almost, the one included with the examples is the old lib, and not the 3.3 one.
Looks like the file vanished from the surface of the internet.
This is driving me crazy!!
Without the so said 3.3 version after more than 1h following this tutorial:
https://sites.google.com/site/stm32disc ... evelopment (https://sites.google.com/site/stm32discovery/open-source-development-with-the-stm32-discovery/setting-up-eclipse-for-stm32-discovery-development)
I got a bunch of errors because it was made for that lib and not for the old libs.
There is so many people out there using ARM's and I cant get to put one compiler up, I think that I will install CoCox, looks like ready to use, lets hope for the best, but I will only try that tomorrow or next week, I'm dead lol.
Well, I see that almost all the DP projects have PIC's, I will PIC's in my university, PIC's have nice IDE's that work, a simple PicKit3 program any Pic out there and there are Pic's up to 32 bits, if I feel the need for speed/power, and I can get free samples, I think I will ditch the Arm world if CoCoox doesn't work right..
EDIT:
YAY!!!
CooCox compiles dummy while(1) loop and also its built in blinky demo!!
Finally it works!
Congratulations! ;) This is on Ubuntu though right? On Windows setting attolic/keil up was really easy. And how are you going to flash it, with the stand alone ST-LINK utility? or do you already own a seperate programmer?
Also, does this solution offer some kind of debugging? I'm not really sold on either Attolic or Keil, and coocox looked nice too.
Cool! I have been looking for a solution for Ubuntu with using the ST-LINK utility. If you managed that, this is great! If not, can you give some info about how to program etc?
Unfortunately no, I'm running CooCox in Windows Vista 32bits, I'm waiting for BusBlaster v2 to be released and then I will switch back to Ubuntu.
This tutorial:
http://fun-tech.se/stm32/index.php (http://fun-tech.se/stm32/index.php)
Compiles, but its the one that gave me warnings, I dont know if I made something wrong, but you can also try it, and if you get the same warnings send an email to the tutorial author, I have already done that and I'm waiting for its response.
I think that most of the errors that I get following tutorials is because I'm using windows and not Ubuntu where Gcc is in its native home.
I'm also waiting for some response from ST about the V3.3 Std Pheripheral lib for their chips.
Its so annoying that every commercial ARM compiler uses GCC and a lot of freely developped libs and the ask huge amounts of money for them..
I have a big list of tutorials, some of them will eventually work under ubunut/linux, here they are:
http://fun-tech.se/stm32/index.php (http://fun-tech.se/stm32/index.php)
https://sites.google.com/site/stm32disc ... t+on+Linux (https://sites.google.com/site/stm32discovery/open-source-development-with-the-stm32-discovery/setting-up-eclipse-for-stm32-discovery-developmenthttp://newwiki.openpilot.org/display/Doc/Software+Development+on+Linux)
http://sourceforge.net/apps/mediawiki/g ... =Main_Page (http://sourceforge.net/apps/mediawiki/gnuarmeclipse/index.php?title=Main_Page) This is an Eclipse Plugin.
http://open-bldc.org/wiki/Building_ARM_Toolchain (http://open-bldc.org/wiki/Building_ARM_Toolchain)
http://newwiki.openpilot.org/display/Do ... t+on+Linux (http://newwiki.openpilot.org/display/Doc/Software+Development+on+Linux)
The last one is biased a lot to the OpenPilot project, but it may work for other processor than the ones they use.
I think that the basic is installing CodeSourcery and then the Std Library files, and do the rest with Makefiles and linker scripts and what not, but I still dont know how to do that :/
Maybe the best thing to do is read the getting started guide from CodeSourcery and learn about Makefiles, and linker scripts that look even worse than the makefiles that I can almost read now
http://www.codesourcery.com/sgpp/lite/a ... elease1592 (http://www.codesourcery.com/sgpp/lite/arm/portal/release1592)
There are also some more links in this topic that are worth visiting, if some one get a toolchain working under linux/ubuntu talk about it here!
Another questions for the Ubuntu/Linux pros.
In this script:
http://www.fun-tech.se/stm32/gcc/index.php (http://www.fun-tech.se/stm32/gcc/index.php)
Cam I change the gcc and Newlib to the most recent versions just changing its file names/download places and it will work or there is something more under the hood that will break?
@ brian
This may be rather out of date, but in doing some STM32 scanning, was feeling interested and surprised by your findings per your statement that follows ---
I
I would be sure that the peripherals you want are there. I wanted USB host, external memory interface and I2S on a chip, STM32 doesn't have any such chips.
Have some feelings there may be some misunderstandings caused by the flyer descriptions.
The trailing notes were collected in bits and pieces.
a. Some times the circuit flyer refers to I2S as SM Bus/PM Bus.
b. Their DMA section references memory source and destination operations. And they also mention that 80 GP I/O's are assignable to the 18 pins used for external interrupts. That seems rather obsecure, as a possible external memory expansion.
c.They do feature the STM32 as a low pin count unit. So they may lack room for ext memory additions. Unless you have resolved the answer, maybe it is worth a call to follow their advice to call their local sales agent.
My flyer notes are as follows - - -
STM32F100x4 STM32F100x6
STM32F100x8 STM32F100xB
Low & medium-density value line, advanced ARM-based 32-bit MCU
with 16 to 128 KB Flash, 12 timers, ADC, DAC & 8 comm interfaces
â– Up to 8 communications interfaces
– Up to two I2C interfaces (SMBus/PMBus)
â– DMA
– 7-channel DMA controller
– Peripherals supported: timers, ADC, SPIs,
I2Cs, USARTs and DACs
2.17 I²C bus
The I²C bus interface can operate in multimaster and slave modes. It can support standard
and fast modes.
It supports dual slave addressing (7-bit only) and both 7/10-bit addressing in master mode.
A hardware CRC generation/verification is embedded.
The interface can be served by DMA and it supports SM Bus 2.0/PM Bus.
2.14 DMA
The flexible 7-channel general-purpose DMA is able to manage memory-to-memory,
peripheral-to-memory and memory-to-peripheral transfers. The DMA controller supports
circular buffer management avoiding the generation of interrupts when the controller
reaches the end of the buffer.
Each channel is connected to dedicated hardware DMA requests, with support for software
trigger on each channel. Configuration is made by software and transfer sizes between
source and destination are independent.
The DMA can be used with the main peripherals: SPI, DAC, I2C, USART, all timers and
ADC.
I2s and I2c(smbus) are 2 different things. SPI1 on stm32 can work in i2s mode.
for memory interface you would have to reach for the larger parts.
for usb it's usb access line and higher (performance and communication line)
@robots
Thanks for the reading and for your contributions.
Needed to be alerted about I2C versus I2S.
GET FREE LPCXpresso!
http://www.nxp.com/campaigns/cortex-m0/ ... ub=gallery (http://www.nxp.com/campaigns/cortex-m0/index.php?sub=gallery)
@Bustar
Yes only the connectivity line supports I2S (and the performance XL devices) with good audio accuracy and has USB hosting. Connectivity line does not have an external memory interface.
I2S is like SPI (4 wire), while I2C is 2 wire.
@senso
While it isn't for STM32 you can find out how to do a full windows JTAG toolchain on my website now:
You will have to ignore the part about the development board I will be selling in a few weeks though...
http://teholabs.com/docs/toolchain:jtagwin (http://teholabs.com/docs/toolchain:jtagwin)
You probably just need the "Install and setup Cygwin, OpenOCD, and other utilities" section.
You can hack my makefile and linker to your device when I post them I think. But that stuff needs some cleanup before I am done, and I am busy for the next week.
[quote author="senso"]Another questions for the Ubuntu/Linux pros.
In this script:
http://www.fun-tech.se/stm32/gcc/index.php (http://www.fun-tech.se/stm32/gcc/index.php)
Cam I change the gcc and Newlib to the most recent versions just changing its file names/download places and it will work or there is something more under the hood that will break?[/quote]
There are two things I did differently from that script (other than execute each step manually):
1) Update to the latest versions of everything. This eliminates the need for the patch against binutils. However I believe there might be a small bug in the latest version of binutils that affects you if you're trying to do particularly fancy stuff (Specifically something to do with an instruction needed by FreeRTOS, which is the only example I have failed to compile with that toolchain)
2) Replace all instances of STM32/STM with ARM - the toolchain works just as well on other ARM CPUs like the Luminary Stellaris series
Note: There is the possibility something released between late December when I did my toolchain build and today that might break something. However many of my packages were newer versions than those listed in the fun-tech script.
There is only little thing that I dont understand, if CodeSourcery says that it have all what is needed to compile C code to an ARM target why do we need to recompile/have a dedicated gcc compiler in a folder just for the codesourcery?
I am a big linux noob, so if you can explain it to me I would love to year, learning is always a good thing.
[quote author="senso"]There is only little thing that I dont understand, if CodeSourcery says that it have all what is needed to compile C code to an ARM target why do we need to recompile/have a dedicated gcc compiler in a folder just for the codesourcery?
I am a big linux noob, so if you can explain it to me I would love to year, learning is always a good thing.[/quote]
You don't. The tutorials on building your own toolchain are for those who do not wish to use the Codesourcery releases for whatever reason (unsupported distro, wanting to learn more about the toolchain, concerns about possible limitations in the Codesourcery tools.
For example, the CodeSourcery page claims that the free "lite" edition does not include JTAG debug support - many of the tools above cover building OpenOCD and GDB. CodeSourcery Lite has all you need to compile, but apparently not to debug.
A question, is possible program an ARM with another device other than a JTAG debugger? Something like a USB or UART bootloader?
The STM and the NXP ARM's already have built-in serial bootloaders, I think you can use then with FlashMagic and a simple FTDI breakout.
We have a couple quick start guides on the wiki that describe the bootloader available in the major arm cpus.
Hi senso,
My board is finally out. See http://teholabs.com (http://teholabs.com) and http://teholabs.com/docs/eridani:overview (http://teholabs.com/docs/eridani:overview) for the product page and docs respectively.
Like STM and NXP there is a serial bootloader on it. So you just need a virtual com port, but a JTAG is better...
I have tutorials on how to do several toolchains for it, I hope they are written so that even a 'linux noob' can do them. :-)
I have already took a sneak peak at it and they look great.
Thanks for the information sharing also congratulations for your nice dev-board.