Author Topic: Need some advice on chip selection (Read 9631 times)

blewisjr · « **on:** February 22, 2014, 01:42:56 pm »

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 · « **Reply #1 on:** February 22, 2014, 01:52:08 pm »

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 · « **Reply #2 on:** February 22, 2014, 01:53:05 pm »

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 · « **Reply #3 on:** February 22, 2014, 02:02:52 pm »

Quote from: Marco on February 22, 2014, 01:52:08 pm

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.

Quote from: dannyf on February 22, 2014, 01:53:05 pm

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 · « **Reply #4 on:** February 22, 2014, 02:12:12 pm »

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 · « **Reply #5 on:** February 22, 2014, 02:37:19 pm »

Quote from: dannyf on February 22, 2014, 02:12:12 pm

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 · « **Reply #6 on:** February 22, 2014, 02:50:50 pm »

Quote

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 · « **Reply #7 on:** February 22, 2014, 03:45:37 pm »

Quote from: blewisjr on February 22, 2014, 02:02:52 pm

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 · « **Reply #8 on:** February 22, 2014, 05:10:37 pm »

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 · « **Reply #9 on:** February 22, 2014, 05:49:39 pm »

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 · « **Reply #10 on:** February 22, 2014, 05:52:36 pm »

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 · « **Reply #11 on:** February 22, 2014, 08:24:11 pm »

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 · « **Reply #12 on:** February 22, 2014, 08:57:43 pm »

Quote

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.

Quote

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.

Quote

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 · « **Reply #13 on:** February 22, 2014, 09:11:33 pm »

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 · « **Reply #14 on:** February 22, 2014, 09:13:45 pm »

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 · « **Reply #15 on:** February 22, 2014, 09:18:37 pm »

Quote from: dannyf on February 22, 2014, 09:13:45 pm

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 · « **Reply #16 on:** February 23, 2014, 12:42:19 am »

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 · « **Reply #17 on:** February 23, 2014, 01:09:03 am »

Quote from: dannyf on February 23, 2014, 12:42:19 am

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 · « **Reply #18 on:** February 23, 2014, 01:50:57 am »

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 · « **Reply #19 on:** February 28, 2014, 08:19:17 pm »

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 · « **Reply #20 on:** February 28, 2014, 09:19:14 pm »

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 · « **Reply #21 on:** March 01, 2014, 01:43:14 pm »

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 · « **Reply #22 on:** March 01, 2014, 01:57:00 pm »

Quote

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.

Quote

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 · « **Reply #23 on:** March 01, 2014, 02:53:31 pm »

Quote from: dannyf on March 01, 2014, 01:57:00 pm

Quote
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.

Quote
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 · « **Reply #24 on:** March 01, 2014, 02:59:34 pm »

Quote

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.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Need some advice on chip selection (Read 9631 times)

Share me