I'm looking into Load/Store 32 bit MCUs with CAN bus for control and sensor interface. There are a lot of families available to choose from. I'm leaning towards the Freescale stuff because it has a nice feature set (up to six CAN buses on one chip) and they have a free assembler. OTOH Fujitsu has some nice stuff
If any one has any suggestions pipe in.
I want a Fat Micro to start, with lots of features to make life easy (multipliers - dividers - big RAM, lots of I/O). Most of the first round effort will go into development, so cost is not the major consideration. Labor is. Price around $30 to $50 per chip onesies. i.e about 1 hour of (cheap) engineering labor. The worst thing that can happen in a development like this is that you do not have enough horsepower to make a design work. Freescale seems to have a good migration path with an FPU in some of their very high end parts. Code migration should be a low effort (don't they all say that?) activity, due to the common core.
I'm planning to write a simple simulator for the chip. Then a FORTH core. A dual stack load/store machine just cries out for a FORTH.
We can cost reduce when we go to high volume production. Or maybe we just let the decline in chip prices do it for us.
Choosing An MCU
Choosing An MCU
Engineering is the art of making what you want from what you can get at a profit.
I agree - Freescale and PowerPC type cores are good. Also check out Renesas in their 32 bit series. They used to be Hitachi and Mitsubishi (I think, H and M are the two lines in Renesas). The SH 32 bit series has lots of CAN, A/D, D/A and other periferals. If you like SPI as well, stick with Freescale, otherwise Renesas has better a better tool chain then Freescale (but it also costs more).
I've had good luck with the Coldfire series, but I don't know if it has CAN on it.
I've had good luck with the Coldfire series, but I don't know if it has CAN on it.
I think I have looked at
Atmel
Fujitsu
Freescale
Infineon
a bit.
All have a very good selection of Power PC and CAN. CAN has a lot to be said for it in terms of how it is structured. It is also qualified for aerospace (I helped with that) and they have turned it into a Safety Bus by forcing a time slot structure on it. This was not possible ten years ago because the CAN interface that was tits then SJA 1000 had no built in timing mechanism that was accurate and deterministic enough. Now most of the chips have a time stamp counter of 48 or 64 bits. Enough in the first case to run 28 years continuously before wrap around. In the second case if you could run the stamp counter at 1 GHz it would take 528 years to wrap around.
It is basically a control bus. Data is going to need a higher speed bus. Probably a chip with 100 T Ethernet. Lousy as a control bus (and any one using it that way should be shot before he murders some one) but it is a very nice way to move large chunks of data. There are Ethernet enabled controllers in the Power PC line so the thing to do may be to put two chips on the high speed data acquisition boards. It will probably call for some quasi dual port RAM. One port to dump the data. Another port to send it on its way. 4 GB of RAM could hold almost two minutes of samples at 20 MSamples/second of 16 bit data. By the time we get around to building such a machine we can have two banks of 8 GB ram for a little over 7 minutes of high speed data collection.
To make all this work we will need a master clock in the lab and all clock distribution cables need to be identical and properly terminated.
Also on the safety critical pieces we will use chips with dual CAN and have the wires separated the way they are aboard ship. Of course aircraft are done that way too. No single point failures.
Atmel
Fujitsu
Freescale
Infineon
a bit.
All have a very good selection of Power PC and CAN. CAN has a lot to be said for it in terms of how it is structured. It is also qualified for aerospace (I helped with that) and they have turned it into a Safety Bus by forcing a time slot structure on it. This was not possible ten years ago because the CAN interface that was tits then SJA 1000 had no built in timing mechanism that was accurate and deterministic enough. Now most of the chips have a time stamp counter of 48 or 64 bits. Enough in the first case to run 28 years continuously before wrap around. In the second case if you could run the stamp counter at 1 GHz it would take 528 years to wrap around.
It is basically a control bus. Data is going to need a higher speed bus. Probably a chip with 100 T Ethernet. Lousy as a control bus (and any one using it that way should be shot before he murders some one) but it is a very nice way to move large chunks of data. There are Ethernet enabled controllers in the Power PC line so the thing to do may be to put two chips on the high speed data acquisition boards. It will probably call for some quasi dual port RAM. One port to dump the data. Another port to send it on its way. 4 GB of RAM could hold almost two minutes of samples at 20 MSamples/second of 16 bit data. By the time we get around to building such a machine we can have two banks of 8 GB ram for a little over 7 minutes of high speed data collection.
To make all this work we will need a master clock in the lab and all clock distribution cables need to be identical and properly terminated.
Also on the safety critical pieces we will use chips with dual CAN and have the wires separated the way they are aboard ship. Of course aircraft are done that way too. No single point failures.
Engineering is the art of making what you want from what you can get at a profit.
Infineon and DAVE
I have worked with a number of these micros before, the biggest difference seems to be in the tool chains and how fast you can get up to speed on them.
One thing about the Infineon processors is that they supply a program called "DAVE"--Digital Application Virtual Engineer, or something like that. What this does is bring up a block diagram of the chip and allow you to visually configure the chip (back end low level drivers) and produce very nice, very well documented C-code that plugs into the tool chain.
Literally this can save weeks on a project, and it teaches very good programming style and modular structure for embedded C code.
(I know you are a fan of FORTH, but this is quite well done).
--G
PS: We also have a dsPIC working directly from MATLAB quite nicely, that we are using to develop a small UAV autopilot.
One thing about the Infineon processors is that they supply a program called "DAVE"--Digital Application Virtual Engineer, or something like that. What this does is bring up a block diagram of the chip and allow you to visually configure the chip (back end low level drivers) and produce very nice, very well documented C-code that plugs into the tool chain.
Literally this can save weeks on a project, and it teaches very good programming style and modular structure for embedded C code.
(I know you are a fan of FORTH, but this is quite well done).
--G
PS: We also have a dsPIC working directly from MATLAB quite nicely, that we are using to develop a small UAV autopilot.
Yeah. Nice idea. And as soon as they "improve" the tool chain it produces different code.
I'm planning on meeting FAA type requirements for DOC and tool chain traceability. Not to mention program structure and testing. As long as you can't capture their tool chain you are screwed.
Plus the C model for stack thrashes (excuse me I mean context changes) encourages a less than atomized program structure. Violating one of the first rules of good design and testability. Keep the elements short and testable.
There is an ANSI model for FORTH and although it is not my favorite I intend to conform with it by the time I declare the project finished.
I'm planning to use SwiftX from FORTH Inc. as my development platform. And the free 55xx Assembler from Freescale.
http://www.forth.com/swiftforth/index.html
http://www.freescale.com/webapp/sps/sit ... _Tools_Tab
They are both no charge so any one interested can join in.
I'm planning on meeting FAA type requirements for DOC and tool chain traceability. Not to mention program structure and testing. As long as you can't capture their tool chain you are screwed.
Plus the C model for stack thrashes (excuse me I mean context changes) encourages a less than atomized program structure. Violating one of the first rules of good design and testability. Keep the elements short and testable.
There is an ANSI model for FORTH and although it is not my favorite I intend to conform with it by the time I declare the project finished.
I'm planning to use SwiftX from FORTH Inc. as my development platform. And the free 55xx Assembler from Freescale.
http://www.forth.com/swiftforth/index.html
http://www.freescale.com/webapp/sps/sit ... _Tools_Tab
They are both no charge so any one interested can join in.
Engineering is the art of making what you want from what you can get at a profit.
I have looked seriously into the Power PC architecture and it is a pile of steaming dogy do. ARM is much better. And they have free tools as well. Plus there are more different kinds of chips and mfgrs. Not as high end in terms of features as the Freescale stuff. Probably good enough.
What makes me say the above? Well, I started to do some coding. The Power PC does not do stacks well at all. Neither chip has a real return stack (except for interrupts). But they are much easier to make in the ARM architecture.
What makes me say the above? Well, I started to do some coding. The Power PC does not do stacks well at all. Neither chip has a real return stack (except for interrupts). But they are much easier to make in the ARM architecture.
Engineering is the art of making what you want from what you can get at a profit.
Free ARM assembler with limited C compiler:
https://www.keil.com/demo/eval/arm.htm
I can test the assembler I'm writing against that.
Nice exposition on ARM:
http://www.arm.com/miscPDFs/9658.pdf
and for non-programmers:
http://www.peter-cockerell.net/aalp/html/frames.html
Some nice chips:
http://focus.ti.com/mcu/docs/mcuprodove ... milyId=454
http://www.arm-development.com/
https://www.keil.com/demo/eval/arm.htm
I can test the assembler I'm writing against that.
Nice exposition on ARM:
http://www.arm.com/miscPDFs/9658.pdf
and for non-programmers:
http://www.peter-cockerell.net/aalp/html/frames.html
Some nice chips:
http://focus.ti.com/mcu/docs/mcuprodove ... milyId=454
http://www.arm-development.com/
Engineering is the art of making what you want from what you can get at a profit.
If you did something sneaky like adding an instruction to turn one or two of the registers into a data stack it would be a perfect machine. Of course with the ability to use any register as a stack with instructions it is not too much short of what I would like.drmike wrote:Yeah, ARM is everywhere. I haven't really used it much, but it is always in the list of choices of every project I've dealt with. Right now I'm up to my eyebrows in VHDL, so I leave all the "high level" assembler stuff to software guys :)
I never did get deep into VHDL. I mostly used the Xilinix tools which did not require VHDL.
Engineering is the art of making what you want from what you can get at a profit.
MSimon, I think you'd like the 68000 architecture. 8 general data registers. And 8 address registers, any of which can be used as a stack pointer for push or pop. Not a proper RISC design in some aspects, bit it kind of feels like one when coding. Too bad there aren't more micro controllers based on the design. Forth and other stack based languages would love to be implemented on such a processor. Separate stacks for interpreter, language data, and language call.
-
SpacemanSpiff
- Posts: 2
- Joined: Mon May 05, 2008 3:21 am
- Location: Indiana, USA
I like the 68000 family and have done code in it.
I hate the way they handle bytes. Other than that a very nice machine.
What I'm looking for is a SOC. PPC and ARM seem to dominate in the 32 bit area. There is some very neat stuff out there. Like CAN and Ethernet on one chip. Beautiful for the 20 MSPS data collector I have in mind.
BTW the PPC is a real turkey. If you can avoid it you ought to. It was not made for efficient execution of machine code. Also they have a very funny notation for describing how it operates. Bit 0 is the MSB. Who thinks like that?
I hate the way they handle bytes. Other than that a very nice machine.
What I'm looking for is a SOC. PPC and ARM seem to dominate in the 32 bit area. There is some very neat stuff out there. Like CAN and Ethernet on one chip. Beautiful for the 20 MSPS data collector I have in mind.
BTW the PPC is a real turkey. If you can avoid it you ought to. It was not made for efficient execution of machine code. Also they have a very funny notation for describing how it operates. Bit 0 is the MSB. Who thinks like that?
Engineering is the art of making what you want from what you can get at a profit.
Lots of vendors offer the ARM GNU assembler and a crippled C compiler for free. Since I don't expect to be doing much C that is fine. I have downloaded a couple (Keil is one) and will report back after I have tried them.SpacemanSpiff wrote:MSimon,
I personally like the ARM chips, especially from Freescale. But I always use the GNU gcc toolchain; it has a pretty broad feature set, including the capability to have mixed ARM/Thumb projects.
The Thumb stuff is nice but I don't expect to have any significant code space problems. The difference in price between a 128KB device and a 512K device is not significant for the size of the projects contemplated at this time. And by next year bigger devices will be available.
It could always be added to the tool set if it is an issue.
Engineering is the art of making what you want from what you can get at a profit.