Need some advice on chip selection

[blewisjr]

Hello Everyone,

It has actually been quite a while since I really have done any mcu development.  Have been so tied up with other things for school I just let it slide as I was short on time and have not really been able to poke in here with updates on my various project.

Maybe a little background is in order first and foremost.  I have experience with both 8 bit PIC and 8 bit AVR chips.  I have completed two main projects so far including a alarm clock and an audio triggered stop watch.  As for preference so far I have preferred the AVR a bit more to the PIC being that a. there are a bit more resources out there and b. the compiler is not totally gimped and c. Atmel studio is quite a nice IDE even though I prefer Linux I felt it was not worth giving up such a good environment to work in.

So I have been " looking to step up my game " a bit and attempting a more complex project.  The issue is I really don't know what kind of chip to use for the project.  I am more then willing to learn a new architecture if it is required so feel free to make any such suggestions.

Essentially I want to build a automated mini drone.  Yes it is that big of a leap.  So far I came up with some basic limiting requirements.
1. Yes it must fly
2. Initially I want to be able to use preloaded flight data from a desktop application I will develop.
3. Once the flight data is loaded into the drone I want it to auto execute the flight data.
4. In general my theory is I will need motors and a way to control the flight direction through levers of some sort to adjust rotor tilt.
5. When it is powered on it should execute the flight data and at end of flight obviously land and power itself down (sleep) until told to fly again.
6. Will probably need some sort of sensors to be able to interpret how far it moved and what elevation it reached in order to execute said data.
7. This is not RC it is totally self controlled.
8. I want this built from scratch for learning as in I do not want to use a kit.

To me this seems rather complex and in need of some reasonable omph but I could be wrong.

Anyone have any suggestions to point me in the right direction from a chip choice perspective.  Not looking for particular model numbers or parts but more of a general idea in the chip direction I should go like 8 bit is fine or you should look into 32bit arm or PIC32 type stuff.

I would also appreciate details into your reasoning for making your suggestion as this can be a neat discussion and learning experience for me.

Thanks in advance guys/gals.

[Marco]

Why not a quad? It is the simplest configuration.

Unless you're looking for a challenge just go for a 32 bit chip with some fast math instructions.

[dannyf]

The go-to chip for that in the western world is AVR: lots of main control boards + ESC controllers are done with those chips. In my view, they are severely underpowered for upward mobility in the future.

If you look at the control boards done in China now, you will notice that many of them are done on STM32 (mostly F1 and some F3 and F4 boards now), simply because more knowhow there is in the 32-bit world than in the 8-bit world. I would say that many of the STM32 Discovery boards with onboard mems sensors would be a great starting point. Particularly the F3 family or the F4 if you use lots of dsp/fp math.

I wouldn't invest a second in PIC32 (or AVR32) myself.

[blewisjr]

Why not a quad? It is the simplest configuration.

Unless you're looking for a challenge just go for a 32 bit chip with some fast math instructions.

Ok so the thought behind 32bit ARM is not insane.  Yes the idea is also to use a quad rotor design simply because it looks really sweet.

The go-to chip for that in the western world is AVR: lots of main control boards + ESC controllers are done with those chips. In my view, they are severely underpowered for upward mobility in the future.

If you look at the control boards done in China now, you will notice that many of them are done on STM32 (mostly F1 and some F3 and F4 boards now), simply because more knowhow there is in the 32-bit world than in the 8-bit world. I would say that many of the STM32 Discovery boards with onboard mems sensors would be a great starting point. Particularly the F3 family or the F4 if you use lots of dsp/fp math.

I wouldn't invest a second in PIC32 (or AVR32) myself.

Yes danny I was thinking the same as far as PIC32/AVR32 seems nuts with the traction of ARM in that market.  So you would suggest STM what about NXP I am not sure how the development tools are in the ARM world as I have never used ARM yet.

[dannyf]

NXP is a more up-market player than STM. So their chips tend to be not as feature rich or as competitive as STM's. However, they have (far?) better documentation and less bugs.

As far as development tools, you are likely going to breach the 32K barrier so you need to either buy a license to use the commercial tools, or use board-tied freemercial tools (LPCXpresso for NXP or CCS for TI, for example), or go with free tools (like CoIDE, emblocks or emide - where support is usually limited). For CoIDE, STM has the best (chip and debug) support so I would go with that.

[blewisjr]

NXP is a more up-market player than STM. So their chips tend to be not as feature rich or as competitive as STM's. However, they have (far?) better documentation and less bugs.

As far as development tools, you are likely going to breach the 32K barrier so you need to either buy a license to use the commercial tools, or use board-tied freemercial tools (LPCXpresso for NXP or CCS for TI, for example), or go with free tools (like CoIDE, emblocks or emide - where support is usually limited). For CoIDE, STM has the best (chip and debug) support so I would go with that.

CoIDE + STM actually looks like a decent choice.  The main reason I can see is that for one CoIDE seems to support all of STM's chips if I am reading their chip support correctly as well as STM uses CoIDE as a recommendation right on their site.

I am not quite sure about all the requirements I need as far as chip features go but I was looking at something like getting a STM32F3Discovery for a easy starting board to get to grips with ARM.  Not sure if it will do what I need will need to look at the specific chip in more detail.
http://www.mouser.com/ProductDetail/STMicroelectronics/STM32F3DISCOVERY/?qs=sGAEpiMZZMt6peTohPPdu3cQUhI1hfuT

Edit: After looking at the chip I don't know if I can solder one of those.  They say it is available in 3 packages from 48 to 100 pins but I can only find a LQFP-100 

[dannyf]

for one CoIDE seems to support all of STM's chips

If anything, that's actually a weakness of theirs: the STM32L for example isn't supported. However, they and ST have done a great job adding chip support recently. So hopefully that will be addressed soon.

[Marco]

Ok so the thought behind 32bit ARM is not insane.  Yes the idea is also to use a quad rotor design simply because it looks really sweet.

Small quads don't need any mechanical tilting or cyclic control, they just change the attitude of the quadrotor as a whole to manoeuvre.

[free_electron]

i would go for a hex rotor.
they seem much more stable, wobble less. i;ve been talking to some people that are 'in' to this. there's a bunch of em a t the techshop making carbon fibre bodies (ultralight) and other things for these machines.
the photo guys ( people that want to lift camera's with these machines ) all agree hex or octal is the way to go simply because of stability. the quads are to 'nervous'.

[senso]

There are a couple flight controllers based around the STM's, for example OpenPilot, the spin-off/branch of that is called TauLabs, there is the VRobotix, and a couple more, there is lots of forums about quads, usually made for each software/hardware flavour, but there is also RCGroups, just roll down until you see the multi-rotor section in the Helis if I'm not mistaken, and there is also the diydrones blog with lots of links and projects and products.

Yes, it seems that the atmegas are able to do the job, and there are really cheap flight controllors based in them.

[Kremmen]

If you want to consider ARMs then my suggestion is either CoIDE + one of the supported chips; STMs are good. Or you could think about an Atmel SAM and Studio. That way you can almost have your cake and eat it. SAMs are ARMs and Studio is the IDE familiar from AVR development (you did use that one?).  @ 128 MHz the SAMs are no mean chips and there is a good selection there as well.

[blewisjr]

Thanks for all the info.  After my looking around it really does seem like ST is one of the better offerings at least in the hobby range to work with.  I found that the STM32F3 actually fits this application quite well and should even be possible to do a hex rotor with the chip.  The chip line is affordable and I was even able to find a LQFP 48, 64, and 100 pin versions and they are actually affordable.  I think the 48 and 64 should be easier for me to solder not sure never did SMD before.

So I started by picking up 2 STM32F3DISCOVERY boards which should be good to get started with.  I grabbed two because it was more viable to pay $8.00 shipping on a $20 order then on a $10 order.  At least they should be good to get started learning on before I tackle the project head on.

I will use CoIDE and the ARM-GCC compiler now just to find resources to learn how to use these chips.  Any suggestions on that outside of the datasheets of course because I already know I will need those.

[dannyf]

the STM32L for example isn't supported.

Just took a look and I was wrong about it: Both 151 and 152 are now supported. Good job.

I started by picking up 2 STM32F3DISCOVERY boards

The F3 is one amazing chip, particularly if you do a lot of mixed signal projects. It can give the Freescale offerings a run of their money.

Any suggestions on that outside of the datasheets of course because I already know I will need those.

I would think about how you intend to drive the chip:

1) via the st library or directly.
2) if via the st library, do you want to have your own layer or not?

I myself took a mixed approach: initially, I used st libraries but through my own layer (so my code is portable from other chips to the STM). Then started to replace the st library piece by piece (when I get some time). So my code now is a mixed bag, 1/4 direct register access and the rest through ST's library calls. This increases performance and retains the code's portability.


Also, I am running gcc-arm 4.6 still.

[blewisjr]

I would initially start with the STM libraries as they are already there so why not.  As I get more comfortable with the chips I would probably end up tearing them apart into my own set of libraries where I am more comfortable knowing what is in there and I know that it is thoroughly tested and of course cross chip compatible eventually weaning me away from the STM libs.  At least this way if I need assembly somewhere I can ensure that it can be used on all chips.  This is because of course if I am going to make the jump and invest in ARM for hobby work I am going to stick with ARM unless doing something really small and it is not worth the extra silicon.

I was looking around amazon.com to see if I could find a book that can help me understand these chips better as they are far more complex then a AVR or a PIC and came across this written by one of the Cortex M designers this it is worth the $50?

http://www.amazon.com/Definitive-Cortex%C2%AE-M3-Cortex%C2%AE-M4-Processors-Edition/dp/0124080820/ref=sr_1_1?ie=UTF8&qid=1393103461&sr=8-1&keywords=cortex+m4

[dannyf]

We talked about it somewhere recently here. It is a waste of your time, unless you intendn to write rtos / design chips, etc.

The datasheets are the best books you will ever find.

[blewisjr]

We talked about it somewhere recently here. It is a waste of your time, unless you intendn to write rtos / design chips, etc.

The datasheets are the best books you will ever find.

Ok thanks I will keep the book on the back burner just in case it interests me at a later time will indeed devour the datasheets hopefully the ST datasheets are at least semi decent.

[dannyf]

You probably want to read the user manual for the ST libraries, the source code / header files, and compare them vs. the device datasheet. CoIDE offers a lot of examples and that helps greatly.

Learning the vendor library is no small task and if you don't have a middle layer, it is frustrating as well.

The usual sequence is this:

1) write a series of house-keeping stuff: how do you want to initialize the mcu, which ports to turn on / off, how to name the leds on the board, how fast the device is running, software delays, etc.
2) write a series of functions / macros to operate the gpio: set/clear/flip pins, put them in input/output mode, PP vs. OC, how fast you want them to run, etc. At this point, you should be able to blink the leds;
3) write a few routines to run systick: typically to set its irq frequency, and being able to install a user handle for the systick isr; At this point, you can blink the leds with the systick, and then you can go back to 1) and recalibrate the software delays;
4) write a series of timer routines: you should be able to specify how often a timer triggers and being able to install the timer isr; You can then blink the leds with timer isr. They are a ton of them on the STM32F3 board;
5) write a series of pwm routines: you want to utilize the OC/pwm features of the timers and do hardware pwm. You will then deal with the AF functions of the chip -> confusing; The above will allow you to control a motor;
6) ancillary routines, like spi, i2c, uart (at least tx), adc, and rtc, etc.
7) if interested, you will also write a few routines to read the onboard mems sensors.

It will be a good learning and challenging experience, especially if you haven't dealt with the device before.

[blewisjr]

You probably want to read the user manual for the ST libraries, the source code / header files, and compare them vs. the device datasheet. CoIDE offers a lot of examples and that helps greatly.

Learning the vendor library is no small task and if you don't have a middle layer, it is frustrating as well.

The usual sequence is this:

1) write a series of house-keeping stuff: how do you want to initialize the mcu, which ports to turn on / off, how to name the leds on the board, how fast the device is running, software delays, etc.
2) write a series of functions / macros to operate the gpio: set/clear/flip pins, put them in input/output mode, PP vs. OC, how fast you want them to run, etc. At this point, you should be able to blink the leds;
3) write a few routines to run systick: typically to set its irq frequency, and being able to install a user handle for the systick isr; At this point, you can blink the leds with the systick, and then you can go back to 1) and recalibrate the software delays;
4) write a series of timer routines: you should be able to specify how often a timer triggers and being able to install the timer isr; You can then blink the leds with timer isr. They are a ton of them on the STM32F3 board;
5) write a series of pwm routines: you want to utilize the OC/pwm features of the timers and do hardware pwm. You will then deal with the AF functions of the chip -> confusing; The above will allow you to control a motor;
6) ancillary routines, like spi, i2c, uart (at least tx), adc, and rtc, etc.
7) if interested, you will also write a few routines to read the onboard mems sensors.

It will be a good learning and challenging experience, especially if you haven't dealt with the device before.

Sounds complex but very fun at the same time I think I will enjoy this.  I would assume most of this information can be scraped from datasheets, examples and the user guide then.  I think the most interesting part is messing with the mems sensors they sounded very useful in the ST market video.  That is a very interesting systematic list as well any reason they are in that order in particular and are there any other tips to help ease the curve of learning all this stuff besides bashing my head off the datasheet until the ah ha moment. 

[dannyf]

They are fun to play with but not that difficult to program to, once you get i2c/spi going. The code dealing with the devices is in the demo package and is fairly straight forward.

[blewisjr]

Well my 2x STM32F3's arrived yesterday and I got a chance to open one of them up.  Getting everything installed on Windows 8 was surprisingly easy.  I did not attempt my Linux laptop but from the windows perspective it was pretty simple.

First I had to find the documentation took a while but I found something like 6 PDF files on the ST site.  I think these are what I need let me know if I am missing something please.

1. STM32F3xx Data Sheet
2. STM32F3Discovery Getting Started Users Guide
3. STM32F3Discovery Users Guide
4. STM32F3xx Peripheral User Manual
5. STM32F3xx Programming Manual
6. STM32F3xx Reference Manual

Lots of manual hope that is the stuff I need 

Then I had to stumble through the site to find the STLink stuff.  Eventually I found STLink Utility and the STLink driver for Windows 8 (Wow they had a signed driver props to them).

Once I got those installed I plugged in the board with my Mini B cable and the demo firmware started to run yey it did not break.  Neat little firmware app going to have to investigate that code at some point and spice it up to be useful.

Once that was done I decided ok I got power but can I see it so I opened up STLink Utility clicked connect and yes all is good.

Decided to install the GCC ARM eabi compiler and CoIDE and that stuff is running not sure if it is working right but the programs run.

Not too bad at all seems like things just work fine and dandy now what do I do?  Or I should ask where do I start now?

[dannyf]

CoIDE comes with stlink drivers so you don't actually need to install separately.

You do need to download, install and configure gcc for use with CoIDE.

After that, you will need to learn to create a project and compile, download code to the mcu. That requires lots of reading.

The steps I outlined earlier would be a good starting point.

[blewisjr]

Well I am finally figuring out how to read this documentation.  Surprisingly everything is there it is just a matter of finding out which pdf file has the information.  I decided to look into GPIO first because from what I understand that seems like a good place to start.  I managed to find the steps needed to configure GPIO by using a combination of the reference manual and example code.  Never realized you need to enable clocks on GPIO with ARM chips that is rather cool that each IO has it's own clock.

Next task I want to light a LED if only I can figure out how to use this damn IDE.  Turns out the STM32F3Discovery does not currently have a project template in CoIDE but the chip on the board is supported. 

Any ideas how I can get the extra firmware files like stm32f3_discovery.h into a project?  Is it as simple as copy and paste into the project folder under my workspace?  This whole component based approach is odd.

[dannyf]

Turns out the STM32F3Discovery does not currently have a project template in CoIDE but the chip on the board is supported. 

You probably want to read the manuals a little bit more. Or you wouldn't go too far.

Any ideas how I can get the extra firmware files like stm32f3_discovery.h into a project? 

You will need to create a project including the relevant parts of the library and then copy over the discovery related files and include them in the project. More details of that can be found earlier in this very thread.

Those files are useful only if you want to compile the demo program or build projects substantially similar to it.

[blewisjr]

Turns out the STM32F3Discovery does not currently have a project template in CoIDE but the chip on the board is supported. 

You probably want to read the manuals a little bit more. Or you wouldn't go too far.

Any ideas how I can get the extra firmware files like stm32f3_discovery.h into a project? 

You will need to create a project including the relevant parts of the library and then copy over the discovery related files and include them in the project. More details of that can be found earlier in this very thread.

Those files are useful only if you want to compile the demo program or build projects substantially similar to it.

I am sorry danny but I am not really the kind of guy who can read thousands of pages of documentation and learn from it.  I find the best way I learn is by attempting something and trying to find the relevant information on the fly.  When it does not work I try to find out why and then make the corrections and try again.  If you mean the CoIDE documentation then I have to say that pdf is rather horrible with very little if any explanation it is mostly just screenshots with a single sentence.  Who knows maybe CoIDE is not the IDE for me but I will give it a reasonable shot before I go to something like straight eclipse with some plugins.  If that does not work I guess I will have to do things the old fashion way with good old vim + terminal + makefile.

Thanks for the responses much appreciated.

[dannyf]

If that does not work I guess I will have to do things the old fashion way with good old vim + terminal + makefile.

The issue isn't the IDE or any tools you use. This (reading and understanding the manuals and datasheet) is a way of life here. Some tools may make it easier for you but no relieve you of reading, lots of readings.

No other way around it.

[blewisjr]

If that does not work I guess I will have to do things the old fashion way with good old vim + terminal + makefile.

The issue isn't the IDE or any tools you use. This (reading and understanding the manuals and datasheet) is a way of life here. Some tools may make it easier for you but no relieve you of reading, lots of readings.

No other way around it.

Never said I was trying to eliminate reading and lots of reading but I can't learn by just reading.  Personally I need something practical so I can focus my reading because all of the material is just reference material in these PDF's.  If I don't have a simple project going like light a LED I have no way to even know where to start reading.  The task of light a led (note not blink the led) focus' my reading on GPIO.  With that in mind I was able to find the relevant information on configuring GPIO in the documentation.  The example program given by ST helped me find the header files to look into etc...  It is just do difficult to sit there and read through a reference manual + datasheet without some kind of goal in mind.  That is just me though.  Oh and yes I did already read the chips data sheet 3 times and can't remember a damn thing lol.  Most of a bulk was electrical characteristics and architecture block diagrams.

Also I do not expect the tools to do all the work never do as most of the time tools screw up anyway.  I was just hoping to see a basic template there for the eval board I have.  It is not there so I will have to figure out an alternative way and hopefully be able to figure out how to save it as a template to use again later.  It is no big deal it is just easier if you can click a few buttons and have your project ready to go and make your tweaks;  instead of having to do all of the steps of setting it up each time you make a new project.

[dannyf]

Never said I was trying to eliminate reading and lots of reading

The point is that you have to understand the chip, libraries and the tools for you to work comfortably with them. That requires tons of reading.

Or your experience will be painful.

If I don't have a simple project going like light a LED

It is very easy to blink an led - as long as you take a methodical approach. See what I wrote earlier about it.

Most of a bulk was electrical characteristics and architecture block diagrams.

Read the reference manual.

I was just hoping to see a basic template there for the eval board I have. 

CoIDE sets up a minimalist template for you and it can be compiled within seconds - that is the beauty of CoIDE -> create a new project, select the chip, pick the components -> hit build and you are done.

After that, you will need to drop in your own stuff in main.c to make it do whatever you want. There are tons of examples within the ide and online too.

You just need to understand the tool to take advantage of it.

[blewisjr]

Well that was simple I was able to get a LED to blink using a simple software delay.  I know I am kind of derailing my own thread but there was something I noticed about CoIDE.  When you create a Project it actually places quite a few files directly into the workspace folder.  This is really weird considering eclipse which this is based off of places each project in its own folder under the workspace.  Does this mean with CoIDE you can only have one project per workspace and thus only one project open at a given time?
I also noticed the linker script seems to be modified on the fly and it is not actually stored in the workspace.  This seems like a VCS nightmare waiting to happen.

Any ideas I can't find anything in the IDE docs about this stuff nor on the CoIDE forums.

[dannyf]

I was able to get a LED to blink using a simple software delay.

Getting a led to blink is very easy. The difficult part is to figure out your way to code / work around the environment so you can maximize return on your (coding) investment. For example, you can make your libraries out of the exercise so in the future you can reuse them.

When you create a Project it actually places quite a few files directly into the workspace folder. 

Those are the library files. Basically, there are two ways to do this:

1) you can configure the library via a configuration file (placed in the project directory) and the interrupt files (customized for your project);
2) or you copy the whole structure into the project directory.

I tend to customize my library files and use a middle layer to access the library calls. Because of that, the CoIDE approach works well for me. Otherwise, I rely on a template to structure my "typical" project settings and copy them to the new project folder to speed up the development process.

This is where CoIDE speeds up the whole thing for me.

DSPLib isn't done the same way as it doesn't require configuration.

Does this mean with CoIDE you can only have one project per workspace and thus only one project open at a given time?

You are correct. workspace doesn't work in CoIDE - they are a few others and you will find them out soon,