Best approach for AVR32 beginner ?

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

Ok, I consider myself fairly knowledgeable about AVR development with GCC and AVRStudio under Windows, but know nothing about AVR32 (yet).

Just got my STK1000 and connected power, I see the AVR32 logo (although it looks like a funky image or lots of dead pixels).

The CD with the kit says BSP 0.93. I noticed that the Atmel web site has BSP 1.0 and I downloaded/burned the ISO but didn't install it yet. Elsewhere in this forum there is mention of a beta version 2.0.

Questions:

1) Should I be afraid of any AVR32 tool installations on the same machine that is being used for heavy duty AVR and VisualC development, or has everything been tested to coexist without conflicts.

2) Which version is recommended for a total beginner? 0.93, 1.0, or the beta ?

3) For very simple programs that can be debugged with the occasional printf, will I need a Linux computer or is it possible to compile under Windows and shuffle the SD card back and forth?

4) If there is no practical way around having a Linux computer, what is recommended for a total Linux beginner? I have writted device drivers for Unix many years ago but never had a need to install Linux.

Probably have some older RedHat or LinSpire CDs around the office, but I guess it is probably better to download whatever is most suitable for AVR32 and dedicate one of my computers just to that. What Linux version is recommended and what type of computer? PentiumIII, IV, or D ?

Thanks!

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

Re question #2, speaking as an expert not a beginner I'd say newer is better ... less buggy, more complete. AVR32 is still very new, those are real concerns. So either 1.0 or the beta; and the beta is newest. In either case I think you will need to upgrade U-Boot almost the first thing, so it may be worth using 0.93 to familiarize yourself with how things are supposed to work before diving in. The upgrade is easy with a JTAG mkII, and I'm told the beta has a nice tool for it also. (Hmm, my STK came with the 1.0 BSP ...)

Re #3, there's a network connection available, and you should use it! My config happens to be NFS root served from a Linux box, so I never shuffle MMC/SD cards at all. (In fact, the 2.6.20 kernel doesn't have that driver yet ...) You'll want a serial console, those can hook up to Windows too (or so I'm told).

Re #4, since I only boot WinDOS about once a quarter, I wouldn't know. But you didn't say what kind of development you're doing. Someone said that kernel compilation isn't robust under cygwin (on Windows); I don't know if that's true. But in general, I'd recommend you grab Ubuntu and install it on a decent development machine; I have K7s with 1 GB each, and decently fast disks (~40-50 MB/sec streaming) and they're just fine. Quad Opterons are nice too.

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

RayKAvr wrote:
1) Should I be afraid of any AVR32 tool installations on the same machine that is being used for heavy duty AVR and VisualC development, or has everything been tested to coexist without conflicts.
Nope, I have one computer at work which dual boots Windows and Linux, both of which have tools for both AVR8 and AVR32 installed. No issues for me but I have heard that the version of Make which ships with WinAVR doesn't play too nice with Cygwin. Make sure you have real make from the Cygwin setup.exe.
RayKAvr wrote:
2) Which version is recommended for a total beginner? 0.93, 1.0, or the beta ?
There isn't a huge difference between 0.93 and 1.0 from a runtime POV, there are a few tool changes though. In any case I'd install the tools from 2.0Beta as there are a few things worked out. http://www.atmel.no/beta_ware has the BSP2.0Beta. As for the runtime stuff, well, BSP2.0Beta uses Linux 2.6.18 with almost-the-official-mainstream-patchset while BSP0.93/1.0 uses Linux 2.6.16 + a-bunch-of-stuff-which-is-almost-completely-replaced. As such using the runtime stuff off 2.0Beta will mean the least amount of change in any kernel code you write. If you aren't writing kernel code, there isn't too much of a difference. Once again, newer is better, if for nothing more than a few extra drivers.

As mentioned above, the version of UBoot which is on the STK1000 won't read UBoot images made with the version of UBoot from later BSPs. The BSP2.0Beta comes with a really easy tool for upgrade if you don't have a JTAGICEmkII from your AVR8 work. If you do, then so much the better! Nothing standing in your way.

RayKAvr wrote:
3) For very simple programs that can be debugged with the occasional printf, will I need a Linux computer or is it possible to compile under Windows and shuffle the SD card back and forth?

No need for a Linux box, you can use FTP to move files to/from the STK1000 or as you say, shuffle the SD card. Note that the SD card is formatted EXT2 so to read it under Windows you'll need something like http://www.fs-driver.org/ . You'll be able to see the printf's on whichever console you connect to, either over serial or telnet. The former will of course require something like Hyperterminal or better, Realterm.
RayKAvr wrote:
4) If there is no practical way around having a Linux computer, what is recommended for a total Linux beginner? I have writted device drivers for Unix many years ago but never had a need to install Linux.
I like Ubuntu because it Just Works. That and it's mirrored by my ISP so I get all my Ubuntu action off the meter :D . Ubuntu also has precompiled binaries of all the AVR32 dev tools so installing them is a synch. Ubuntu should run fine on a PIII but if it's a bit laggy, try Xubuntu which uses a more light-weight window manager. The same toolchain from atmel will work.

Good luck!

S.

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

Squidgit andf Mojo, thanks very much, your detailed responses are very helpful. Right out of the box the STK1000 responded to http requests by serving a web page, so it is on the net. It also gives me a prompt on a terminal window, so ftp should work.

No clue yet whether I will need to modify kernel. All I want to do is grab video feed off a camera sensor, encode, and stream over the net. Kind of like the LinkSys, Panasonic or Samsung webcams except also show local preview on LCD.

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

I would definitely recommend the 2.0 beta. There are quite a few improvements that have gone into it, including several non-trivial bugfixes which are quite hard to backport. So 2.0 beta should actually be less buggy than 1.0 even though it's a beta. Also, the avr32-specific device driver model has changed to something more compatible with the rest of the kernel, so if you're going to write drivers, switching to 2.0 now will give you less surprises in the future.

Not to mention that some of the most important parts of the BSP 2.0 kernel are made up of patches that have been reviewed by the Linux Kernel community. The BSP 1.0 kernel has never been through that kind of public review, which means that the overall code quality is probably significantly lower.

Userspace should be compatible, so programs compiled with the BSP 1.0 toolchain should run just fine on 2.0. It does not necessarily work the other way around, but usually it does.

Except for one thing though: the BSP 1.0 version of gcc uses short enums by default, while the BSP 2.0 version does not. This breaks the ABI, but code that depends on knowing the size of enums tends to be broken with short enums anyway, so upgrading and recompiling all programs and libraries will actually fix a few problems. One example of this is the RPC code in uClibc; the BSP 2.0 version of busybox can mount NFS filesystems while the BSP 1.0 version can not.

As for u-boot, it's indeed unfortunate that it needs to be upgraded in lockstep with the toolchain (more specifically, the mkimage utility.) This is because the number used to identify the AVR32 in the uImage files produced by the BSP 1.0 toolchain conflicts with the Blackfin number in upstream u-boot. AVR32 now has an official number upstream, so once you upgrade u-boot to the BSP 2.0 version, you won't see this particular problem again.

And if you're doing development on other architectures using u-boot as well, you can simply grab a recent upstream version (1.1.6 or later I think) and mkimage will Just Work for AVR32 if you're using the BSP 2.0 version of u-boot (or the upstream version, of course.)

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

RayKAvr wrote:
No clue yet whether I will need to modify kernel. All I want to do is grab video feed off a camera sensor, encode, and stream over the net. Kind of like the LinkSys, Panasonic or Samsung webcams except also show local preview on LCD.

You'll probably end up writing a bit of Kernel driver code to set up a DMA transfer to get the data out of the ISI and store it somewhere useful. At a first glance, if you're only using the LCD as a preview device, I'd probably sack the framebuffer device driver and just DMA the preview stream of the ISI straight over to the LCDC inside the kernel. If you need access to the LCD from userland too then things becomes slightly trickier. One way around this I guess would be to have a userspace interface to your driver which can switch control of the LCDC between your preview stream and the the Framebuffer device, still allowing you to use the LCD for menus etc, just not as overlays to real-time video. Note I'm referring to sacking the Linux Framebuffer Device (/dev/fb0), the LCDC will still need a framebuffer (lump of memory to store all those pixels) somewhere.

I must admit I haven't looked in to either the ISI or LCDC too closely, my project doesn't use either, but methinks that's about the best way to do it.

S.

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

Thanks squidgit... so much to learn. Ubuntu was easy to download and run and even played nice in a Windows XP/MCE environment. I had never heard of Ubuntu before and without your time-saving tip I probably would have thought it is an irrelevant niche product.

I'm still quite amazed by the prospect of running similar code on the desktop and on an embedded device.

Having a lot of fun with 8-bit AVR development but I know that I need the major step to ARM or AVR32 up as soon as video is involved in any way. One of these days I have to open up one of the above mentioned network webcams to see what processor is used there.

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

I've never tried out the preview feature of the ISI, but I would imagine you would have to use the framebuffer driver to initialize the LCD controller and set up a framebuffer the usual way, possibly double-buffered. Then the ISI driver must somehow obtain the address of this framebuffer and set up DMA directly into it.

I'm not sure what existing interfaces can be used to do something like this. Maybe the ISI driver should provide a custom ioctl() to set this up.

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

how wrote:
I've never tried out the preview feature of the ISI, but I would imagine you would have to use the framebuffer driver to initialize the LCD controller and set up a framebuffer the usual way, possibly double-buffered. Then the ISI driver must somehow obtain the address of this framebuffer and set up DMA directly into it.
Certainly the LCDC needs to be initialized and it has to have a lump of RAM devoted to a framebuffer, I was thinking that these steps would be done by the custom driver. If the work from the Framebuffer device driver can be reused, so much the better! I imagine it will have to be double-buffered though, yes. In fact, the ISI example in the AP7000 datasheet has this path triple-buffered, though that seems a little excessive! I've never written to the framebuffer from the kernel but I don't imagine there'd be any trick to it.
how wrote:
I'm not sure what existing interfaces can be used to do something like this. Maybe the ISI driver should provide a custom ioctl() to set this up.
The stumbling block for me was letting the ISI driver know the address of the framebuffer. If this is part of the ioctl() then userspace has to know about kernel memory addresses (no. just no.) but I can't think of any other way without being messy and manually feeding the ISI driver the fb address during board-init.

S.