Jump to content
Kilrah

New development platform?

Recommended Posts

A few weeks ago, a friend of mine told me that he was going to order an evaluation kit for a microcontroller, for $20. Seeing the price, I asked him to order one for me too, without even asking what it was.

So 3 days ago I received a nice AVR Butterfly evaluation kit.

The size of the box is ridiculously small, but this is not a reference. It consists of a small 45x65x10 mm multi-layer SMD PCB, with an ATmega169V microcontroller as the main actor.

As external peripherals, we find a 5-way joystick (like on an Ericsson T68), a 6 character alphanumeric segment LCD, a buzzer, a thermal and a light sensor, a 512kB external SPI flash, a 32kHz crystal for the RTC, and a RS232 <-> TTL converter for the integrated UART.

That's quite a lot for the size and the price.

It is shipped pre-programmed with a bootloader and a very complete demo program which uses nearly everything that is provided in the controller and on the board.

What interested me was the sources. They can be found on Atmel's site, but they are intended to be compiled with a commercial compiler. After having searched for some time, I found a GCC for AVR processors, called WinAVR. After some more time, I found that someone had ported the original code for use with that gcc. Really nice! :P

The thing is very easy to flash, as the only needed part is a serial cable without any components, thanks to the bootloader. Of course Atmel also provide us with an IDE to program and simulate in assembly, a bit like MPLAB for PICs.

So that means that we have a good hardware for our usage (RS232 e.g. for the GPS, 512kB flash for a datalogger, ...) which is upgradeable (many free ports on headers, including inputs to the 10-bit ADC), and ready-made C routines for all that hardware...

I think it could be a good quick-and-easy way to make projects that are relatively complicated to do with a PIC, and also cheaply.

The discussion is open...

Regards,

Kilrah

Share this post


Link to post
Share on other sites

I was interested in the Butteryfly back when it was first advertised in the trade mags. I was disappointed when I found that the board only seemed to support some canned functions. I guess I misunderstood, since I had no idea it would run fully custom code.

Have you written any personal code and run it on the board yet? I would be interested in your experience in doing that. That is to say, is it a big pain to use the GCC port?

Lastly, do you know if the Butterfly's processor needs an emulator for full hardware debugging, or is that handled by a silicon debugger like some of the newer PIC's? In other words, can I hardware debug directly from the Butteryfly?

Share this post


Link to post
Share on other sites
is it a big pain to use the GCC port?

I recently plunged into AVR/ATmel development enviroment. I bought STK500/502 development boards from DigiKey and loaded free WinAVR software which basically uses GCC. STK500/502 is more expensive than Butterfly but I wanted to be able to program ATMega128.

The programing environment takes some time to set up. After a day or two of reading stuff on avrfreaks.net and looking at some examples I was able to make it work. Suprisingly the WinAVR package has solid progessional appearence. Now with a push of a button I can compile "C" code and write it to CPU. I do debugging on AVR Studio and everything works smoothly - as soon as new code is compiled in PN (programer notepad, part of WinAVR package) AVR studio loads the updated code and I have GUI based debugger. So far I only used software emulation debugging mode, can't say for sure about actual hardware debug.

Regards,

Val.

Share this post


Link to post
Share on other sites

Hmmm... tried to post this one 10 times since tuesday... finally got it!

Well, you must have read strange things.. No, you can just do everything you want with the provided hardware. As I said, you can flash the user code with a simple serial cable with the provided bootloader. If you want to kick the bootloader and flash the whole memory, the ISP pins are brought to a header so we are able to use the serial programming mode. You can also use the parallel method, but in this case you have to move a couple of resistors on the board.

For the moment, I've started by trying to program in assembly as I'm more used to it. I've written a first program that blinks a segment on the LCD, and a second one that generates a running segment on the display.

Concerning C, I've only tried to recompile the source (easy), and then to edit some things like auto-off timer, clock frequency (the ATmega169V is, unlike the 169, specified at a max speed of 1MHz. But I've tried to overclock it at 2, 4 and 8MHz and it still works perfectly. Even Atmel overclock it at 2MHz in the bootloader code to enable serial communications at 19200bps...)

The source code is quite big (14 C files and 17 headers), but it's normal for all the features included. It's very well written and commented, and the different files represent the different function groups (LCD, RTC, serial, sound,...). The guy who ported the code has taken the original one, and replaced the needed instructions, leaving the original ones in comments.

Of course it will take some time to understand everything, but if we do it by parts, using only what we need and not everything in block I would say that only a few hours are needed. Every procedure is well described, so even copy-paste can do it, we only have to have a look at what to give to the functions and what they return...

Honestly I think that it can be a very good solution, but I just miss an idea of something useful I could do with what I currently have to test the C functions to get a real idea.. If you have one... :) knowing I have no GPS and no pressure sensors in stock..

Yes, you can debug with the integrated hardware, but for this you need a JTAG interface. I've spent some time looking for schematics, but I hasn't been a great success... I mean in terms of something that we can make ourselves easily like our JDM programmers for the PICs. I've only come to the schematics of Atmel's interface, which takes 4 pages, uses another big AVR along with about 50 other components...

But it seems to be reliable, not as with the PICs, for what I've read about it. It seems that the debug hardware in the 16F87x family is buggy, and microchip give no support for it.. I have some articles here saying that.

The debug circuitry in the AVR is more complete, like it can handle 3 different breakpoints at the same time.

Here is the user manual of the thing, it says its basic possibilities.

If you want I can post my small programs if you have a board to test them..

I can also list the useful addresses where I found everything but I will need some time to find them again, as I've just saved everything locally.

Regards,

Kilrah

BTW: Happy new year to all :-)

Share this post


Link to post
Share on other sites
Now with a push of a button I can compile "C" code and write it to CPU. I do debugging on AVR Studio and everything works smoothly - as soon as new code is compiled in PN (programer notepad, part of WinAVR package) AVR studio loads the updated code and I have GUI based debugger

Whoa, very interesting.. For the moment I've only used windows notepad to edit C code... Where did you find the info on how to do it?

Thanks :)

Share this post


Link to post
Share on other sites
Where did you find the info on how to do it?

See:

http://www.avrfreaks.com/Tools/ToolFiles/3...nfig_WinAVR.pdf

on page 7 how to cofigure programmer's notepad. Last option of the example sets the call to make file to program atmel device (I believe makefile uses avrdude to talk to device by default).

Regards,

Val.

Share this post


Link to post
Share on other sites

Hehe :) thank you! That thing is really powerful!

I'll start writing a small PWM generation program today using the C source, I need this to test if a DC brushless fan can be PWM-comtrolled.. And this is an idea for an example :P

Share this post


Link to post
Share on other sites
I need this to test if a DC brushless fan can be PWM-comtrolled.

They can. I PWM'd a DC brushless fan for my optical heli-tach project. It works fine, except that the fan's internal tach cannot be used (stable DC needed to do that). I had to add an external tach sensor in its place.

Share this post


Link to post
Share on other sites

OK, thanks for the info.

Must be possible to use the tach if we leave the power applied long enough to get 2 rising edges. By measuring the time needed to do 1 turn, we can calculate the speed. That means overriding the PWM sometimes. Of course it would not work correctly at low speeds.

Anyway, the point of the post was to say that I had finished my PWM generator. It has taken me about 4 hours, including reading and understanding the datasheet on how to use Timer2 for PWM generation, and understanding the pieces of the original C source I've used...

I've removed many unused things, and added routines to control timer2.

Not too many problems, apart some inattention: I hadn't seen that the LCD routines did not update the display by themselves, so as nothing changed I thought at first that the rest of the program didn't work correctly. Other issue: Timer2 PWM output is already used by the DOWN key, so I had to use left/right to change the PWM value instead, and edit the code so it ignores what happens to the pin (otherwise it eats the PWM as if it was button presses, which doesn't work well :huh:)

The program writes "PWMxxx" on the display, where xxx is the current value of the PWM (000-255). If one of the keys is held, the value changes automatically.

This is the confirmation that it's really fast to do something that works, and even more if we take into account that it's my first try to program a microcontroller in C :rolleyes:

Regards,

Kilrah

Share this post


Link to post
Share on other sites

-AT-cyber-flyer:

Have you ever experienced problems with AVRStudio when simulating? I had a problem in my code yesterday and AVRStudio, just crashed while simulating, and not always at the same place :wacko:

Tried to compile and simulate on another PC, and it didn't work either..

Any idea?

Share this post


Link to post
Share on other sites

No AVR crash problems on my side. The biggest problem so far is that the debugger simulates fast PWM mode as if it is normal PWM (with twice as many CPU cycles).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×