Building the Best Controller

How does the motor control hardware on this AVR cpu compare to the PIC chips?

It's hard to beat the dsPIC line for motor control hardware. They have crazy amounts of support for SMPS and motor drives in hardware.

As an example, you could set up a dsPIC to do the following:

Drive three H-bridges fully synchronously with programmable dead times
Use an onboard comparator to monitor current to ground and automatically go to a PWM safe-state (i.e. all open or one phase to ground or whatever) if current exceeds a limit
Use a special-event trigger to simultaneously capture current and voltage on all three phases
Automatically capture phase zero crossings on a separate timer channel to do sensorless control

Plus the usual onboard stuff - UARTs, comparators, references, A/D converters, system clocks,

I've been using them for years and have yet to use them to their full capability.
 
dsPICDEM MCLV Development Board $150 available Nov 3.
This board is capable of driving a 48V 15 Amp motor, BLDC or PMSM, in sensor or sensorless operation.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537020
 
Microstick for dsPIC33F and PIC24H Development Board $25 available nov 4
supports dsPIC33FJ64MC802 which has 8 PWM channels
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en548414
 
billvon said:
How does the motor control hardware on this AVR cpu compare to the PIC chips?

It's hard to beat the dsPIC line for motor control hardware. They have crazy amounts of support for SMPS and motor drives in hardware.

As an example, you could set up a dsPIC to do the following:

Drive three H-bridges fully synchronously with programmable dead times
Use an onboard comparator to monitor current to ground and automatically go to a PWM safe-state (i.e. all open or one phase to ground or whatever) if current exceeds a limit
Use a special-event trigger to simultaneously capture current and voltage on all three phases
Automatically capture phase zero crossings on a separate timer channel to do sensorless control

Plus the usual onboard stuff - UARTs, comparators, references, A/D converters, system clocks,

I've been using them for years and have yet to use them to their full capability.


Sounds like a great choice in the PIC, and nearly identical to the ATmega32M1.

it is pretty amazing how much stuff is in these small chips. It is not necessary to "beat" the PIC for motor support, merely to have adequate support in whatever chip is chosen.

That feature set looks pretty similar to the AVR. The real question is does the AVR have the hardware support that is needed for the project.

I left PIC micros because of the arcane instruction set, inefficient architecture, lack of quality free tools and the poor support for flash reprogrammable chips. The AVRs also had much higher throughput per clock. The PICs have improved since then in the flash support area but they probably still have the same instruction set and architecture. The instruction set and architecture are poorly suited for compilers, so the code generation is quite difficult. One advantage of the PIC was the instruction set was smaller so if writing assembler was the goal it was quicker to learn PIC than the much larger instruction set of the AVR. The AVR instruction set is much more like a real computer than a micro. It was developed much later than the PIC and it was made to be compiler friendly. If you are writing a compiler, the AVR is a much better architecture / instruction set to work with. As I recall the PIC didn't have a proper stack so many standard programming techniques did not work.

When I made the transition from PIC to AVR I found there was a bit of a learning curve to gcc-avr, but that it generated better and tighter code than the PIC compiler that I had started with, or than the teaser commercial AVR compiler I tried. I have packed truly amazing amounts of realtime C code into a couple of K in the AVR. GCC has an amazing amount of man-years of development effort in it.

The advantage of the PIC on this project is probably the greater number of folks on here who have PIC experience vs AVR experience. If folks are interested in learning a new tool chain the AVR may be a great opportunity. If they want to keep doing what they're familiar with then the AVR is going to be a problem for them and the PIC could be a better choice.

The main advantage of the AVR is probably the availability of quality free tools. The greater throughput per clock may or may not be important.

Is there a quality free PIC compiler? That would change the equation. Even a good low cost compiler might be possible if everyone was willing to pay for it.

There are free toolchains for the Xilinx and Altera FPGAs so that is always another possibility. If high performance is needed. A combination of a CPU and an FPGA is hard to beat, performance and capability wise. Reacting to fault conditions at the sub microsecond level is very straightforward in an FPGA. The Alteras are a better choice for new users with a better tool chain and a simpler architecture to learn, according to FPGA experts I know. I recall seeing a C compiler for FPGAs but I have not worked with it.

I have not done BLDC motor control with either PIC or AVR so I cannot comment from that particular perspective. Looking through the AVR documentation I see a lot of application notes on BLDC controls as well as in-chip hardware for it, so clearly this is an application area they support.
 
FWIW I find the dsPIC line very useful for this application. Also Cygnal micros, but the compilers for Cygnal are not as affordable (Keil).
 
Pretty much agreeing with Alan re PIC vs AVR. Unless someone does know of a free pic compiler, we should probably go with the processor that we can all easily obtain the same tools.
I've been using PICs since they were the latest thing, and have never used anything else, because I didn't want to face the learning curve, but am fine with it for this project, if only so I can follow along with the real programmers. :)
Or unless it's determined that the PIC hardware really is significantly more suitable of course?
It doesn't seam to me that the development board should be a very significant factor in determining the processor(s). There will be few of them, and hopefully, thousands of the end product (as it evolves over the next few decades?), most of the users of which will want compilers.
Bob
 
I am just a lurker from the sidelines but I cant help jumping in regarding MCU choice.
You REALLY should look into using something ARM based. All the major vendors are going there (except microchip) and there are loads of MCUs to choose from, Atmel, TI, ST, Analog, NXP etc. And they have lots of flash and ram and peripherals for motor control. GCC for ARM is topnotch and you can use Eclipse and loads of other tools, even JTAG debugging is DIY cheep. Many of them can run OSs like uCos, RTEMS, FreeRTOS and some even ucLinux. And they are not expensive, I belive you can get a ARM MCU for under $1 (in quantities).

And it is so much nicer to work with a 32bit architecture compared to 8biters. And look at http://www.olimex.com for lots of devboards that are really feature rich but low cost.

Just my 2c but I do embedded development for a living and would not use an 8bit MCU for a new project unless there was an enormous series i.e millions of units.
 
pelle242 said:
I am just a lurker from the sidelines but I cant help jumping in regarding MCU choice.
You REALLY should look into using something ARM based. All the major vendors are going there (except microchip) and there are loads of MCUs to choose from, Atmel, TI, ST, Analog, NXP etc. And they have lots of flash and ram and peripherals for motor control. GCC for ARM is topnotch and you can use Eclipse and loads of other tools, even JTAG debugging is DIY cheep. Many of them can run OSs like uCos, RTEMS, FreeRTOS and some even ucLinux. And they are not expensive, I belive you can get a ARM MCU for under $1 (in quantities).

And it is so much nicer to work with a 32bit architecture compared to 8biters. And look at http://www.olimex.com for lots of devboards that are really feature rich but low cost.

Just my 2c but I do embedded development for a living and would not use an 8bit MCU for a new project unless there was an enormous series i.e millions of units.

Welcome to ES! Interesting suggestion.

I have not developed for the ARMs though I have bought some in recent phones.. I normally use bigger chips at work and smaller ones at home...

I did some quick searching and grabbed an inexpensive ARM from Digikey that lists PWM Motor Control capability just to get an idea of what is in a typical ARM cpu that has motor control hardware. This LPC1756 is under $8 in 100 quantity and is in an 80 pin package. It is a pretty big chip 12mm square and a challenge to solder with 20 leads on each side but it is do-able if you have a microscope and hot air soldering equipment. It takes a chunk of board space and makes board layout challenging due to the number of conductors converging on the space. This probably pushes the board design into multilayers and increases cost.

The hardware complement in this chip is significant. The datasheet is a bit confusing since it covers many related chips.

This part has multimode USB, two CANbus, four UARTs, two I2Cs, 100 mhz CPU, 256K flash, 32k sram, six 12 bit ADCs, one 10 bit DAC, six PWM outputs, and a few other things. It has three internal busses.

Looks like a bit more of a learning curve than the AVR or PIC but is a very capable chip. It is probably more suited to "one chip does everything" than the multiple CPU approach I was suggesting.

This is just one example of a motor controlling ARM, there are many others.

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=568-4791-ND

If these are going to be considered we need specific chip suggestions and development boards.

I found another ARM that has Field Vector motor control support hardware, but didn't quickly find a price on that one.

http://www.toshiba-components.com/microcontroller/TMPM370.html
 
There are lots and lots of options. The ST32 line looks very interesting also, right now a local distributor has a EVM for 10 EUR ($15) https://www1.elfa.se/data1/wwwroot/assets/datasheets/STM32_discovery_eng_manual.pdf , hard to beat..
 
I think the ARMs are pretty amazing parts. They run the smart phones and the iPad. But a the same time I wonder if the learning curve is steeper than folks here want to tackle.

Perhaps Pelle242 can comment on the comparative difficulty of executing at a fairly straightforward motor control project on each of these architectures (PIC, AVR and ARM) and the comparative learning curves when coming from some PIC experience?

Who is actually going to program these chips? It would be good to have some fit of the primary developers and the tools. In addition to being a suitable tool, it has to be something the primary developers want to work with, or at least are willing to work with.

I envision the motor control portion being done by very few people, and the higher level functions being more open and easier for many folks to contribute to and customize. This in some sense argues for separate chips for the functions.

What are folks interested in doing?
 
Gents – I’m willing to try, however I do not have experience with the lower-level languages. :oops:

My forte is C#, SQL, XML, bin/hex; most anything having to do with Interface, dB, and reporting stuff. My plan is to assist on the end-user programming experience.

~KF
 
Alan B said:
Perhaps Pelle242 can comment on the comparative difficulty of executing at a fairly straightforward motor control project on each of these architectures (PIC, AVR and ARM) and the comparative learning curves when coming from some PIC experience?

In my experience from mentoring and training people most of the learning curve, i'd say 90%, comes not from the architecture but from the development environment , CM, tools etc. AVR has a great "ecosystem" of tools and other resources, ARM probably has a bit more (probably only x86 has a richer ecosystem) so in that regard its pretty even. For the rest of it my opinion is that it is easier to write code for a 32bit architecture than a 8bit one. If you look at C language and compilers it works better for 32bit, 8bit C is a bit of an afterthought and usually requires "shoehorning" things.
In addition the extra legroom you get with larger memories also makes things easier (or sloppier... :) ).

Actually often , at work, we help customers to build a "platform" for their board that includes drivers for peripherals, a preintegrated RTOS, all the compiler/debugger tools preconfigured, sample projects, documentation and training. All that helps reduce the learning curve. And most definitely that can be done for a project of this type. That is definitely something I can see myself contribute regardless.

I think the main reasons for ARM would be that there are so many devices to choose from and most vendors are moving towards ARM even in very low cost devices. It simply is the future. (hmm im starting to sound like I sell these things :) )
 
Purchasing an ARM per motor seems a bit extreme.

Another approach would be an AVR per motor (20 pin $1.50) plus an ARM for the central processor.

Or the ARM could be used for the first motor and central cpu, and the AVR for each additional.

Pelle242, did you use RTEMS? Been wanting to use that OS. Had a presentation at work the other day from the RTEMS folks. Bit of a learning curve but looks worthwhile for projects that need a RealTime OS. (Not sure this motor controller needs one, however).

Lots of choices. How do we want to work this choice?
 
I'm not a processor expert, so I won't advocate for any particular architecture, but I think one of the 16-bit architectures is probably the best solution here. I'll agree that 8-bit MCUs are probably a little weak, but a 32-bit ARM is way overkill. Speed is somewhat important for motor control, since it has to be real-time, but it doesn't require a lot of compute horsepower. I'm also very leery of the complexity of developing for a more advanced platform like ARM. Even with some members on here being generously willing to help build a framework for the application, the rest of us will be dependent on them. I think something with a more hobbyist-friendly development environment is better if we want to make this something that people will be able to tweak and play with on their own. If we use a more complex architecture I'm afraid it'll be more limited to just a small core of developers.

That's just my 2 cents.
 
I don't know how hard it is to code for, but my phone uses a little 1ghz ARM/qualcom v7 snapdragon QSD8250 processor. It draws a fraction of a watt, has incredible 1ghz processing power and speed, and it's smaller than my thumbnail.

http://en.wikipedia.org/wiki/Snapdragon_(processor)

I read they were under $8 each, but I'm sure that's in a very large quantity.

Likely all wrong for this application, but just a suggestion.
 
I also prefer an arm core uC. I propose a M3 core. The STM32 is a good choose. This uC is also used in the OPEN BLDC Project.
*http://open-bldc.org/wiki/Open-BLDC
* http://www.esden.net/blog/
They have already a pcb and a first running fw.

The the Arm m4 core will have additional DSP function but it's quite new. Only Freescal with the Kinetis ARM Cortex-M4 Microcontrollers have some very powerfull devices.
http://www.freescale.com/webapp/sps/site/homepage.jsp?code=KINETIS

A cool feature would be a bluetooth2serial modul. Than a android base cellphone/mediaplayer could be the GUI.
For example a http://www.archos.com/products/ta/archos_43it/index.html?country=us&lang=en.
 
Alan B said:
Pelle242, did you use RTEMS? Been wanting to use that OS. Had a presentation at work the other day from the RTEMS folks. Bit of a learning curve but looks worthwhile for projects that need a RealTime OS. (Not sure this motor controller needs one, however).
Not really. I looked at it a few years ago when it was new and had quite a bit of attention. Now days it looks like FreeRTOS has more traction and seems to have more supporters and many of the ARM (and AVR) devices has FreeRTOS ports made for them.

Alan B said:
Lots of choices. How do we want to work this choice?

One approach might be to hold of with designing the CPU board and instead specify an interface and then make simple adapter boards that standard EVM boards can hook up to. The the ARM/AVR/dsPIC factions can battle it out and whatever path has the best progress wins and gets designed into the final board.
 
pelle242 said:
Alan B said:
Lots of choices. How do we want to work this choice?

One approach might be to hold of with designing the CPU board and instead specify an interface and then make simple adapter boards that standard EVM boards can hook up to. The the ARM/AVR/dsPIC factions can battle it out and whatever path has the best progress wins and gets designed into the final board.
I like that idea a lot. Lets the rest of the design move ahead full speed while also allowing each faction that wants to do a CPU design to also continue at the same time. Helps to keep the open-source design concept more firmly "in front" too!
 
liveforphysics said:
I don't know how hard it is to code for, but my phone uses a little 1ghz ARM/qualcom v7 snapdragon QSD8250 processor. It draws a fraction of a watt, has incredible 1ghz processing power and speed, and it's smaller than my thumbnail.
....

The Snapdragon has HD decoding, Cellular modem and GPS. I can think of applications for the GPS and Cellular for the ebike controller, but the HD is going to be hard to use. :D
 
Alan B said:
liveforphysics said:
I don't know how hard it is to code for, but my phone uses a little 1ghz ARM/qualcom v7 snapdragon QSD8250 processor. It draws a fraction of a watt, has incredible 1ghz processing power and speed, and it's smaller than my thumbnail.
....

The Snapdragon has HD decoding, Cellular modem and GPS. I can think of applications for the GPS and Cellular for the ebike controller, but the HD is going to be hard to use. :D

But it doesn't have any built in RAM and flash. And it probably is in a BGA with 1000+ balls. And you have to sign a few inches of NDA to see any documentation...
But it is a amazing chip, just not for this application.

But something that can be done is to hook up a bike controller MCU to a smartphone by USB (i think some phones have USB OTG) and run a app on the phone that displays information from the controller maybe similar to cycle analyst.
 
That had been done before through bluetooth and wired, even from a few years back.
 
Are there any smartphones out there with a decent sunlight readable display? I think this app is going to need something with a reflective/transflective display. Most are monochrome. You can get color reflective displays, but they are generally pretty sucky.
 
Should we focus some effort on building a simple (best) controller prototype? Not the final thing at all, but something to let folks get started with some hardware and software. Rev 0. Start simple and improve.

Scale the requirements way back to get things moving for this prototype.

I'd like to see something that would be useable on a bike with common motors we already have. So we can swap it into our systems for some real world testing and development. Get that homemade controller grin going!

I would suggest some simplified "prototype requirements" like:

The prototype should be useful, not a tangle of wires on a bench. It should be able to run on a bike with a common motor at reasonable voltages and currents. The actual capability would come out as the detailed design evolves, but something along the lines of existing controllers. Something reasonably easy to attain on the first try.

Use readily available through hole parts for this prototype. Designed so someone with some soldering skills can make it. Easy to repair and mod.

Limit the PCB to one that we can readily get in small quantities at reasonable cost. Use a free design tool that is easy to learn and make a public open schematic and layout so folks can make their own version of it with their own improvements. One such solution I'm aware of that works this way is expresspcb. There are undoubtedly others, pick one. Their 2 layer plated through miniboard is 3.8 by 2.5 inches and costs $51 for three boards and they turn it around in a few days. They have free software for schematics and pcb design that takes a couple of minutes to learn. It is 1.25 ounce copper, so plan for bare wires to be added to support reasonable currents if needed, but again this is not a mega controller (yet). It is the baby that will grow up later.

We can get creative and put some parts on the backside of the board if needed, but keep it serviceable. ONE pc board. Leave the fancy master CPU till later, just do the motor control board. A compact (probably six) FET unit. Standalone.

Use FETs that are readily available, through hole, low cost and fit on the board - constrain by space but keep it simple to start. Not a huge number of them. How many will fit on this board? We want to keep the price moderate, we may be blowing some of these boards up as we try out software ideas, etc. I'd rather blow up smaller numbers of FETS while testing just from a practical standpoint, even if it means testing at lower current.

Voltage - again, what is simple, will fit, and will be useable by most as a test platform for the controller technology (not the performance edge of bike motors). Perhaps not a switching regulator on this first prototype. Add that later? Unless someone has a small footprint trusted design in hand.

Use a micro with open high level software tools. This might mean the AVR since other suggestions either are surface mount only or don't have free high level tools. Choose the most capable fairly common through hole chip with the best hardware for motor control that is well supported for the purpose (app notes, sample code, etc) and low in cost.

Scale other requirements back to what is essential to make it operate on a bike. Throttle, ebrake. Detectors for sensorless control if they will fit (this will be an important software development area). Toss the things that are not really needed like 12V outputs, etc. This is a platform for developing experience and software. To do that well it needs to be run on the bikes. It should be easy to reprogram without necessarily removing it from the bike. A jack on the board that can be brought out with a cable. AVRs can be programmed with a six pin cable, a laptop and a 15 dollar programmer.

Extra inputs/outputs as available for other things. What does the chip have room for? Like a skilled woodworker, find the "grain" and work with it. Do what is easy and put off what is hard for a future model.

Then we make a few and get started. Once some hardware is out there this project might really take off. Share some software. Write some code, rewrite, throw it out and write it again once the needs are better understood.

It might make sense to split off another thread to focus on this "Basic Prototype". Keep this thread for planning the best controller, and have a focussed thread for some more basic prototypes. More here http://endless-sphere.com/forums/viewtopic.php?f=2&t=22630.
 
I think that’s a great idea Alan_B :)

We should run with what we have agreed with:
  • Alpha Version of an MPS.
  • Cobbled up a FET board 6 & 12 (or one in the same to save cost) and leave room for breadboarding a motor driver.
  • Take a stab at the Common Interface to join the boards.
  • Open up the floor to MCU: Third-party package or breadboard.
I would not drop essential features crucial to supporting the MCU & FETs. If the plan of the first version is to stay in the lab and not become mounted on a real bike then sure it makes sense to delete auxiliary circuits, however that would defeat the purpose of testing MPS circuitry. Maybe some folks want to test that bit: I know I would :D

~KF
 
Back
Top