Next step up from Mega32 - opinions needed

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Morning folks..

Most of my projects have worked well on a Mega32 but am now looking for something more meaty. USB is not critical at the moment - but soon will be.
My options are in order of ease...

Mega128/256
AT90USBxxx
Or...
jump to the ARM!!

I'm leaning towards ARM (for something new :) ). I'd like some real-world opinions of people who have made similar jumps.
The tools need to be in the GNU domain as only the occasional project is a "for pay" project and most are "for diversion"
AVR32 looks to be too media centric plus the fact that BGA puts it out of my ability to build with it

Thanks in advance

Tom

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

tomasch wrote:
The tools need to be in the GNU domain as only the occasional project is a "for pay" project and most are "for diversion"

WinARM perhaps?

If you go for a big enough ARM you can put Linux on it then you get USB-OHCI, Ethernet, TCP/IP and tons more "for free" - and you'll love NFS mounted debugging with GDB/DDD - possibly using a USB-Ethernet adapter - it's so much easier than the flash cycle we use on AVRs - basically when the compile/link cycle has finished on the host development machine the program is ALREADY visible to the target

Cliff

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

I'm looking forward to some more information about the AT32UC3 line of AVR32s.

They're lightweight versions of the AVR32 architecture -- marketed as microcontrollers instead of Application Processors. They have a reduced clock speed, modified the peripheral set to be more "embedded friendly", incorporated onboard Flash and SRAM, reduced the pipeline, replaced the MMU with an MPU, and they're available in 100-pin TQFP (without EBI) and 144-pin LQFP (with EBI) packages.

I'd classify them as something more directly in competition with the ARM7 range, and I'm curious to see how Atmel manages with marketing two such similar product lines (the SAM7 and UC3) simultaneuosly.

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

Thanks, Cliff

Any specific ARM you recommend?
USB & Ethernet would be great

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

Hopefully those small AV32s will still have the resource to run Linux - embedded 32 bit systems can really benefit from it though, even with the "realtime" patch applied to the kernel, it's "realtimeness" can leave a lot to be desired! 'course that doesn't generally matter on a handheld media player such as the existing AVR32 is targetted towards. But could have implications in things like industrial control - but you maybe wouldn't use a processor this "big" for that? Or, I guess, you could just run it "raw" and miss out on the immense library of pre-existing Linux stuff

Cliff

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

tomasch wrote:
Thanks, Cliff

Any specific ARM you recommend?
USB & Ethernet would be great


The ARMs I deal with are probably too big and application specific to be of any use as "entry level" (the datasheet of one I'm looking at spans 1,134 pages for example!) but the joy of ARMs are that there are so many. Some are in "generic" chips and many are in application targetted chips. If you were thinking of benefitting from Linux I'd look at ARM9 and above (as Linux isn't really Linux without an MMU). If you go for ARM7 and want to try Linux it'll have to be uClinux which is specifically designed to run without an MMU (to some extent this is a good thing for beginning as memory virtualisation takes a bit of getting your head around - course you can always use an ARM9 and not enable the MMU!)

Cliff

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

Atmel is encouraging FreeRTOS for the UC3 lineup of AVR32s, and they're boasting a rather large peripheral support library.

I doubt you could run real Linux on the UC3 family because they don't have the virtual memory manager. uClinux, probably.

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

I remember when I got my first ARM board running Linux that within minutes I had the TFTP daemon running on it and could then TFTP to it from my PC and shortly afterwards I built Apache and had it running a webserver. That's the joy of Linux that any other "embedded RTOS" won't offer (except maybe VxWorks) so I hope there's a port of uClinux to it. Looking at their web page: http://www.uclinux.org/ports/ reminded me that there are, of course, the Atmel AT91s

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

Hum. The UC3 comes in two broad variants - one with an external memory interface, and one without.
Either way, the initial offerings include up to 512 kB of internal Flash, and up to 64 kB of internal SRAM. I'm not convinced that 512 kB of Flash would be enough space to host a fully functional kernel, let alone a root filesystem and applications. (Granted, once you get the kernel up and running, you might decide to put the filesystem elsewhere like NFS or Dataflash...)

And I'm not sure if 64 kB of RAM would be enough either. Perhaps uClinux might be possible, but only on the external bus variants?

I am really just in the very earliest stages of investigating the 32-bit embedded world so I'm open to hearing from the voice of experience.

[edit] This is now thoroughly off-topic, isn't it?

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

I think you *might* be able to pare down a kernel and initrd to get it into 512K but, you are right, it would be tight though it could obviously be held compressed IF there was an external DRAM interface. The real blocker would be the 64K RAM *if* that is the only RAM in the system and no external memory support.

A typical kernel (ARM9) is about 700K and I think our decompressed initrd comes in at about 1.4MB in fact.

Cliff

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

Quote:

[edit] This is now thoroughly off-topic, isn't it?

We are off topic from the forum perspective but an important discussion nontheless. I think many people here are interested in "the next step" i.e. 32bit - but there is a lot to choose from.
I was leary of the AVR32 but now with UC3 line (thanks ifmorrison) it may be very interesting. The question then still becomes do you go larger (Arm9/11) for the Linux ULinux or stay in the dedicated world.
The real answer would be what the project dictates I guess - but that's just it - I don't have a real project (yet) - just want to play in a bigger sandbox.

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

I'd just look for a "general" development board. Olimex, for example, seem to do a few. This one at $116 seems to offer a lot of "goodies":

http://www.olimex.com/dev/sam7-e...

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

If we are talking embedded linux then my mind jumps to the tons of linux wireless router/firewalls. Many of them are based on a broadcom chipset. The have form 2 to 8M flash and 8 to 32M ram. Plenty to run a small linux OS. Most of them have some free I/O ports, sometimes you can abuse them to add SD memory to increase the flash space.
They cost around $50 and come in many varieties, tho most common is the Linksys WRT54G (attention, recent versions are based on VxWorks and have only 2M of flash).

The Olimex board seems to have a too small flash (256k) and ram (64k) to run linux, although it looks very nice and at $115 is not that expensive.

Markus

Markus

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

Didn't Linksys go back to Linux with the newer revisions after the VxWorks fiasco for the WRT54G?

Maby barking up the wrong tree but here goes:
If you want Linux and USB and Network the old Sweex LB000021 or the Edimax BR6104KP routers are interesting(Mips32 based).
Costs are about €25,- for a new one.

The boards are the same, the difference is that the Edimax has two USB ports on them as standard, on the Sweex they are easely added.

ADMtek 5120P (170MHz MIPS R4000) (MIPS32 4Kc)
Flash 2 MB NOR Flash
RAM 16 MB SDRAM

Already runs Embedded Linux, a lot of people hack these for fun so lots of info there
There are even free io pins etc

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

Personally I'd be looking for something with a graphical LCD panel - there's nothing quite like blitting your first .BMP onto an embedded development board. Even better when you can play an animated .GIF ! ARMs can do this kind of thing while AVRs cannot really which is part of what makes them "fun"

Cliff

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

You know, this is starting to sound like homebrew PCs of the early 80' only with a much cheaper and more powerful CPU and a decent and free OS. If I weren't up to my eyeballs, I think I might just jump all over this...

Smiley

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

As soon as you start talking about a Linux capable device you''l get a different kind of beast as the AVS's. With an AVR you can still solder your own stuff and get from zero to 1st prototype working in one evening, including HW and SW. With a Linux Microprocessor your only choice, as small entity is to go with an already assembled board. Starting from scratch is complex, it's not just the BGA, but also the 120pins of the CPU, the 50 pins of the memory, etc. Too big a project for your breadboard.

If you just want to add USB to your gadget and the rest of the app remain reasonably small then a AVRUSBKey is your best bet.

Markus

Markus

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

I think Markus_b has a good point. My tried and true Mega32 is my own design and does *most* of what I need including power rectification/regulation plus all 4 port available in human (0.10") spacing plus RS-232 - all smaller than a business card. It's found its way into many, many projects. I designed the board and had it made (AP circuits)with the TQFP 44 package. Managed to assemle them in the toaster oven :) not sure I want to try that with a TQFP 100 pack though.
Of interest, anyone know of the street date for the EVK1100 from Atmel. Would be nice to "try." If I'm really jazzed by it I'll even attempt a make my own board from it.
Just doing some reading and ARM scares me. Perhaps too big too soon. Lots of code to just blink an LED ;)

T

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

I was just googling around some more looking at ARm dev boards to see what you can get for your money these days. While the "hacked router" is a cheap way in, for a more traditional kind of dev board this one at $120 doesn't look bad:

http://microcontrollershop.com/p...

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

There do seem to be many good evaluation/prototype boards available. The "problem" is that I occasionally do get paid for the project. Then I'm stuck with a 3rd party supplier for the board I need. I prefer having my own PCB - that way I only populate what I need and have a reliable source - me! From a development perspective then, yes, these are viable options. Fun thread!

T

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

clawson wrote:
I think you *might* be able to pare down a kernel and initrd to get it into 512K but, you are right, it would be tight though it could obviously be held compressed IF there was an external DRAM interface. The real blocker would be the 64K RAM *if* that is the only RAM in the system and no external memory support.

A typical kernel (ARM9) is about 700K and I think our decompressed initrd comes in at about 1.4MB in fact.

Cliff


Aha!
The EVK1100 (UC3 starter kit) will come with 32 MB of external SDRAM and 8 MB of external Dataflash in addition to the AT32UC3A0512's built-in 64 kB of SRAM and 512 kB of Flash. I think uClinux would probably fit in that sort of environment.

I really like that the UC3 series has 5V tolerant I/O. Not many competing ARMs can beat that.

Now to figure out how to start a uClinux port...

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

Luke,

Rats! I just typed a reply while I had a VPN client running (which cuts my normal internet link) and lost a long post when I hit [submit]. What I was basically saying was:

"how" and "hce" in AVR32 forum clearly have a deep understanding of the existing (presumably MMU based) port of Linux tothe AVR32 and as such I'd be astonished if Atmel didn't already have the wheels in motion to do a uClinux port for the reduce featureset (non MMU) variants of the chip (most of the work could presumably be done on the existing device with the MMU disabled?).

The main work in porting to uCLinux is getting over the limitation of drivers not being able to mmap() so a "clever" MTD flash driver that makes a serially accessed DataFlash chip look as though it was actually a memory region in the processors address space (such as can be done with mmap() and virtal MMU support) would need to be re-thought (perhaps to just a simple driver that just wiggles the SPI wires as you might find on an AVR8). Similarly something like an LCD panel driver could previously have used a virtualised frame buffer but in uCLinux there had have to be a block of fixed memory specifically allocated for the process and so on.

But, like I say, they wil already have a LOT of it done and I'm sure that even if it's not sponsored by Atmel anyone who gets interested in Linux would be thinking about doing this anyway as a "hobbyist project"

Cliff

(I ctrl-C'd this before posting this time !!)

Last Edited: Thu. Apr 5, 2007 - 05:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Reading further into the datasheet, I think I'm going to 'upgrade' (more like time-warp) to the AVR32UC3 series - now when/where can I get my EVK1100 ?! - I'm goint to try and get a board designed (in eagle) for the smaller chip for when they become available through Digikey.
In thinking about it, I will probably also take a stab at moving from the Mega32 to the AT90USB (or a '128/256) as well. I'm sure the price of a single A32 will be more than double a single USB or '128

T

got to find a way to make this pay!!

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

Just one word of warning - while loyalty to Atmel is all well and good and there may be a lot of promise in the AVR32 range I think that if my financial/employment future depended on it and I wanted to step up a gear to 32bit there'd be no question but to look at ARM (maybe Atmel ARMs to maintain the loyalty?) rather than AVR32. Pick up a trade paper with software engineering jobs in it - how many want ARM? how many want AVR32? Also there is a LOT of pre-exisiting ARM code out there if you are looking for a solution to a problem (Linux ports being not the least of these!)

Cliff