I love 8-bit AVR but need more power!

Go To Last Post
109 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been really happy working with the 8-bit AVR line of uCs, but now I need something with more horsepower.

I'd love to find a platform with the following qualities:

    * C/C++ compiler (Free would be great!) * Enough horsepower to read/buffer a 150kB TCP/IP stream with a lot of cycles left.
    * 16/32 bit floating point performer
    * Two+ UART (more is better)
    * One+ SPI (more is better)
    * 2-Layer PCB friendly packages
    * USB
    * Existing Libs/Drivers for peripherals, Ethernet, etc. (something without the need for an OS would be ideal)
    * Many speed grades/pin counts.
What platform(s) do you look to when you need more oomph than an 8-bit AVR can provide?

I have too many hobbies.
s-conductor.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm thinking the Luminary (now TI) Stellaris range found http://www.luminarymicro.com/

Driverlib is your library. lwip handles the higher IP/TCP stack. USB is handled by another library. Toolchain is based off GCC, so you COULD roll your own, or use the codered one. Documentation is quite complete, but PLEASE read the errata sheet carefully.

Also, I think this thread should be in some other board.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

timgoh0 wrote:
I'm thinking the Luminary (now TI) Stellaris range found http://www.luminarymicro.com/

Driverlib is your library. lwip handles the higher IP/TCP stack. USB is handled by another library. Toolchain is based off GCC, so you COULD roll your own, or use the codered one. Documentation is quite complete, but PLEASE read the errata sheet carefully.

Also, I think this thread should be in some other board.

Thanks for the info. I'll start reading right now.

Do you have a recommendation for a more general uC message board? I thought about posting this in general electronics on this board, but figured this forum made the most sense.

I have too many hobbies.
s-conductor.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you go ARM/Cortex (which I would second as an excellent choice), try the sparkfun.com ARM forum. arm.com also has a forum.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Start by getting an LPCXpresso to learn the basics of ARM - the entire "package" includes using the Eclipse IDE as a front end to arm-gcc (a tailored version from "Code Red"). When you have the basics then pick from thousands and thousands of ARM alternatives.

EDIT: fixed typo.

Last Edited: Wed. Sep 1, 2010 - 02:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, you beat Leon to it this time......

(suggesting alternate brand microcontrollers that is)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XMOS is another option:

http://www.xmos.com

For prototyping, the XC-2 board does Ethernet out of the box, and the other stuff can easily be added to it. If the application fits on the two-core device, a double-sided board would be feasible.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

XMOS is another option:

Yeah there are so many suppliers of XMOS out there and so many different models to chose from between $1 and $100 that it's the obvious choice really.

Oh no, wait a minute, that's ARM isn't it? ;-)

Quote:

Cliff, you beat Leon to it this time......

(suggesting alternate brand microcontrollers that is)


I think it was the OP who started it? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And when the errata sheet from Luminary scares you (there's a nasty couple of errors) or their delivery dates get you tired (they still haven't released the µC I used that was due over a year ago), you look at other sources. NXP and ST are the two prime candidates in my mind at the moment. The Luminary ones are great in theory, and the integrated Ethernet controller is awesome... in theory. I've been burned. Have a good look at the errata sheets.
Regarding performance: 150 kBit/s data should be a cakewalk. I used UDP and could serve up data at close to the theoretical limit of the 100 Mb/s Ethernet connection. Using TCP will limit it rather harshly though, since the internal RAM you have to use to buffer packets runs out in microseconds. But 1 Mb/s should be perfectly doable. Just pick the µC that has the most RAM you can find. You'll want it, trust me.

But I agree with clawson - for your first venture, the LPCXpresso is awesome.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TI OMAP35x but no Ethernet (can use usbnet and usb-eth software as an equivalent, or, added hardware). BeagleBoard uses a OMAP35x; BeagleBoard-XM adds Ethernet.
You'll need a watt or two to use these options.
Other options with reduced capability are Freescale i.MX233 and i.MX512, Atmel UC3A0 or UC3A3, multiple Atmel ARMs:
http://www.atmel.com/dyn/products/param_table.asp?family_id=605&OrderBy=1454&Direction=DESC#

Quote:
* 2-Layer PCB friendly packages
TI's 0.65mm pitch BGA for OMAP35x can be on a 4 layer PCB.
http://focus.ti.com/lit/an/spraav6b/spraav6b.pdf
EDIT: Ethernet addition.

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Sep 1, 2010 - 08:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OMAP is one of the most complex ARMs I've used - why would one start the ARM journey on something so complex? Wasn't the datasheet somewhere between 1,000 and 2,000 pages long? It'd be like learning to drive in a Bugatti Veyron.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
OMAP is one of the most complex ARMs I've used - why would one start the ARM journey on something so complex?
It's the only one I'm aware of that meets almost all of mhatter's requirements with (hardware) floating point being the long pole. If the requirements can be reduced (32 or 64-bit fixed point instead of floating point) then easier MCUs can be used. In the near future are Cortex-M4 and UC3C that have hardware floating point.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
It's the only one I'm aware of that meets almost all of mhatter's requirements with (hardware) floating point being the long pole. If the requirements can be reduced (32 or 64-bit fixed point instead of floating point) then easier MCUs can be used. In the near future are Cortex-M4 and UC3C that have hardware floating point.
While a hardware FPU would be awesome it's not a requirement. The single instruction 32Bit multiply on the Cortex-M3 is more what I really meant. See: 8bit multiply vs Cortex-M3

I wish I would have read about ARM (specifically Cortex-M3) a long time ago. I have applications that use Mega128's where a cheaper (and faster) ARM would have been a much better choice.

I've ordered a LPCXpresso-1768 (god I hate that name) to start experimenting with. Thanks for the recommendations!

It seems like the big question with ARM is really in which tools you prefer using. IAR, CrossWorks, CodeRed, etc. With my taste I'll probably end up preferring IAR. :roll:

I have too many hobbies.
s-conductor.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, these 8 bitters with more than 65536 bytes of flash are a mess. Paging memory, 64KB at a time.

Kind of like how the PIC micros page 256 bytes at a time. Or used to. Not sure, I de-PICed years ago.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A peer of mine likes Netburner (http://www.netburner.com).

Not sure about the FPU, but the other requirements look good. I believe the IDE is free (Eclipse based), and has free tools to download to reprogram over TCP/IP.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using IAR at the moment, and it's not the greatest, editor-wise. It's probably possible to move the editing part out easily... actually, why wouldn't it be possible to just do the editing in Eclipse, which I'm used to? Still, I'd need to swap back and forth for debugging and downloading, and it feels like I'd be maintaining two workspaces.
Another downside with IAR is that if you're developing commercially, the license cost is... lets say 'prohibitive' for small scale products.
I had a chat with a regional manager from IAR, who said that an eclipse-based version was in the works. Might have to inquire about that again...

I used Code Red earlier, it's Eclipse-based, and rather nice. It has its oddities, but so do all of them, I suppose. However, I got into a huge spat with them about licensing though. I bought a dev kit that was supposed to be licensed unlimited, but locked to the board. Somwhere between ordering and receiving the dev kit that license was quietly changed to 3 months. Big problem for a 6-month Master's Thesis. They weren't very customer-friendly then, blaming the dev kit manufacturers, who were blaiming Code Red, and trying to put us in between.

I'd like to try Keil next time I get a choice, maybe it's better.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I used Code Red earlier, it's Eclipse-based, and rather nice.

Second that - it's very easy to use and it's great that NXP chose to pair with Code Red for the Xpresso's - hopefully you won't have the kind of support nightmare that TrainzStoffe had. For simple support the Xpresso forum is very good: http://knowledgebase.nxp.com/lpc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've just started getting problems with the Code Red software (3.4.6), nothing builds any more. I'm downloading the latest version, hopefully that will work. I've just got one of the LPC1343 boards, and want to try it.

I much prefer Rowley CrossWorks - they wanted to bid for the LPCXpresso project but NXP weren't interested.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:

I much prefer Rowley CrossWorks - they wanted to bid for the LPCXpresso project but NXP weren't interested.

I'm also a fan of CrossWorks. The included tasking library is a very nice bonus too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I posted my problem to the LPCXpresso forum, and got a very quick reply from Code Red. I downloaded a new version of msys.dll from their web site which solved the problem.

The CrossWorks Tasking Library is nice; I often just use it for interrupt handling, without the RTOS stuff. The IDE is what I really like, though. Atmel should have bought it for the new version of Studio.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
I posted my problem to the LPCXpresso forum, and got a very quick reply from Code Red. I downloaded a new version of msys.dll from their web site which solved the problem.

The CrossWorks Tasking Library is nice; I often just use it for interrupt handling, without the RTOS stuff. The IDE is what I really like, though. Atmel should have bought it for the new version of Studio.

It's good to hear Code Red support is on top of issues. After becoming a little more comfortable with ARM, I'll explore CrossWorks and IAR.

Is the J-Link the de facto programmer/emulator?

I have too many hobbies.
s-conductor.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
I posted my problem to the LPCXpresso forum, and got a very quick reply from Code Red. I downloaded a new version of msys.dll from their web site which solved the problem.

@Leon

Is that dll needed for the new version of CodeRed ?

I still have the "Previous vers" installed on an XP SP3 machine. But haven't used it the last month or so.

I'll give the codesourcery lite a go , when i hit the 128K limit in the CodeRed suite. I have Xpresso 1768's.

Btw: Does anyone know if the compiler won't generate more than 128K code , or the Jtag/Debugger/Programmer just refuses to Program / Debug or both ?

Meaning if you can generate more than 128K Code , but then have to program/Debug via Jlink or Bootloader

/Bingo

Last Edited: Thu. Sep 2, 2010 - 06:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I asked Code Red that. They haven't used that dll with the new version, so anyone having a similar problem with that has to download the fixed dll. It's a very rare problem, apparently, and can affect anyone using software based on Cygwin. The new version 3.50 worked OK for me.

Rowley have their own JTAGs (I use their CrossConnect Pro), but they also support the Segger J-Link. It has a good reputation, but is quite expensive.

Leon Heller G1HSM

Last Edited: Thu. Sep 2, 2010 - 06:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
Rowley have their own JTAGs (I use their CrossConnect Pro), but they also support the Segger J-Link. It has a good reputation, but is quite expensive.

For non commercial a J-Link can be obtained for low money .. Think around 60€

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

They haven't used that dll with the new version, so anyone having a similar problem with that has to download the fixed dll. It's a very rare problem,

There's a problem in GCC running on some Winx64 platforms which involves a replacement MSYS too - so possibly not THAT rare.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another option-
http://www.coocox.net/CooCox_CoI...

It looks like Eclipse for beginners, and has some nice repository code (like sd card, lcd). I don't know if its any good, but its the first thing I'm trying if I go >128k nxp. They (and everyone else in China) have a cheap debugger, also.

(I also just noticed Nuvoton is making a variety of M0's)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I checked CooCox a bit , and i think the licensing was strange

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's always the Codesourcery gcc build that has no code limit. Whilst they are nice, the CodeRed tools tie you into their libraries so if you want to escape to 'normal' gcc, then you might have a few issues. My first experience with LPCExpresso was very positive - the CodeRed tools are well set up and the demo code very useful. I ported some AVR code across to use the USB CDC interface and it was all quite painless. Whereas if you go 'off the beaten track' and make your own environment using Eclipse, openocd,gcc etc then you're in for a bumpy ride. The $256USD price for 256k CodeRed is a good investment!

Xmos - Leon got me into them! Worth a look from interests sake. Definitely a different way of doing things. Single source, yes, but what is the AVR?

Has there been any mention of the PIC32? Time will tell how it fares for our Microchip friends. Anyone had some experience?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The PIC32 is a nice chip and MIPS has some advantages over the ARM. Microchip's tools are excellent and I like being able to use MPLAB and the ICD 3 for every device they make, including the PIC32. The peripherals are very good (identical to those on the 16-bit PICs) and it's pin-compatible with the latter devices with the same number of pins, making upgrading very easy. Extensive (free) software libraries are provided for most applications. I'm designing a board for a client with two PIC32 chips on it.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did the Chevy Corvair use a MIPS for the ECU?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You obviously know nothing about it! Why don't you try it for yourself, or at least read a data sheet?

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Did the Chevy Corvair use a MIPS for the ECU?

What?? Is it unsafe at any speed?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

XMOS is another option:

Yeah there are so many suppliers of XMOS out there and so many different models to chose from between $1 and $100 that it's the obvious choice really.

Oh no, wait a minute, that's ARM isn't it? ;-)

Quote:

Cliff, you beat Leon to it this time......

(suggesting alternate brand microcontrollers that is)


I think it was the OP who started it? ;-)

You don't seem to understand the XMOS architecture. They are very high performance general-purpose devices, with peripherals implemented in software rather than hardware. The AVR is single-source, as is the AVR32, and many other more popular devices, such as PICs.

ARM chips from different manufacturers aren't compatible with each other, BTW. The peripherals will be different and they won't be pin-compatible, necessitating a board design and considerable software changes.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

ARM chips from different manufacturers aren't compatible with each other, BTW

Thanks Leon, I wasn't born yesterday, I know this. But it is FAR easier to port ARM to ARM than XMOS to "whatever the hell claims to be compatible with them, oh wait a minute, there isn't anything so you are f**ked if supply dries up"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mhatter wrote:
What platform(s) do you look to when you need more oomph than an 8-bit AVR can provide?
x86 (as in PC).
mhatter wrote:

* Many speed grades/pin counts.
I am sure you would be satisfied by the pin counts... :-P

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

ARM chips from different manufacturers aren't compatible with each other, BTW

Thanks Leon, I wasn't born yesterday, I know this. But it is FAR easier to port ARM to ARM than XMOS to "whatever the hell claims to be compatible with them, oh wait a minute, there isn't anything so you are f**ked if supply dries up"
Humm. And I thought, Cliff, that you DO prefer AVRs to '51s.

Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lots of AVR users seem to have been f**ked by Atmel's inability to get their chips made. :) XMOS devices are easy to obtain in any quantity. At least one company is buying unmarked chips and supplying them as ASICs, with their own marking on them.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Leon,

The key questions are do they have their own fabs and do they have more than one of them?

Anyone remember the crisis in the DRAM market that was caused when a typhoon hit the Far East and wiped out the main fabs (flooding) temporarily? That one cost our company millions of dollars as I think we had no choice but to use Micron as a source in USA - naturally they were far, far more expensive than Eastern suppliers. At least a second (or rather third/fourth/fifth) source was actually available in that case as DRAM is generic.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They use TSMC, like most other people (90 nm and 45 nm). TSMC is building Fab15, an enormous new facility which will process over 100,000 12" wafers a month. XMOS will probably move to 28 nm quite soon.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just about any which way you turn, to change devices means work. The days of the multisourced micros like the 8051/52 are long gone. Even with fpgas, going from Xilinx to Altera causes pain and where do they get their stuff fabbed? It keeps us engineers employed as outside forces mean things need to be changed/updated etc due to chips becoming obsolete or unavailable.
I'm pondering the course of action with a mega2560 project that has been resurrected - do I stick with the AVR or jump over to an ARM or similar architecture device? I don't need the performance and the requirement is 4 uarts. I need to do a board spin and the code would be easy to port across. Chip cost really isn't an issue. Luminary/TI probably won't get a look in since most of their devices don't have uarts that support RS485 without using timers etc for a workaround. NXP is compelling due to the free tools (CodeRed) as I'm not going to get anywhere near the 128k limit. XMOS would be overkill. ST and Microchip might be worth a look.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Altera and Xilinx both use TSMC.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
Altera and Xilinx both use TSMC.
Leon,

I would really like to know, what makes you to make broad claims like this - which by the way is false.

I don't know about Altera, but Xilinx manufactures at UMC and Toshiba.

Jan Waclawek

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read it somewhere, recently. I think it only applies to their latest 28 mm devices, on reflection. I've just found it:

http://www.eetimes.com/electronics-news/4087890/Xilinx-confirms-Samsung-TSMC-in-UMC-out-at-28-nm

It says that Altera has used TSMC for years.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
I read it somewhere, recently. I think it only applies to their latest 28 mm devices, on reflection. I've just found it:

http://www.eetimes.com/electronics-news/4087890/Xilinx-confirms-Samsung-TSMC-in-UMC-out-at-28-nm

Ah, so. I stand corrected and apologize.

Still, if FPGA type A is manufactured in fab X and FPGA type B in fab Y, it is still single-sourced. You can't know beforehand which of the products will suffer some sort of cutback for watever reason. Moving between FPGA families of the same manufacturer is not trivial, either.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
You obviously know nothing about it! Why don't you try it for yourself, or at least read a data sheet?
When MIPS was avante-gard in the late '80's/early 90's, I did some amazing things with early DEC Workstations using MIPS. Then came DEC's Alpha chip/workstation which trumped the dickens out of MIPS.

With ARM so multi-sourced and pervasive, in my opinion, it's risky or foolish to design-in PIC32 *or* AVR32 for something to be produced in volume for years. That notion isn't a data sheet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I much prefer Rowley CrossWorks - they wanted to bid for the LPCXpresso project but NXP weren't interested.

Perhaps because the compiler is GCC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Code Red uses gcc as well, and Eclipse. It has had lots of problems, whereas CrossWorks has always been very reliable.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
Code Red uses gcc as well, and Eclipse. It has had lots of problems, whereas CrossWorks has always been very reliable.
Crossworks has an elegant IDE, very capable. But the underlying compiler is GCC. That's not a bad thing, of course, but curious, in that GCC is public domain and mixed in with a for-profit product. There are 3 or so products that do so.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's nothing wrong with that, it's permitted by the gcc license.

They considered writing their own compiler, as they have done for the MSP430, AVR and MAXQ, but decided that it wasn't necessary. They did write their own libraries, though. They are more efficient than the standard ones.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
That's not a bad thing, of course, but curious, in that GCC is public domain
It is not public domain.

Stealing Proteus doesn't make you an engineer.

Pages