Being that I'm reasonably experienced with AVR development (have about 3 projects laying around here, like TV-out, PS/2 keyboard->Atari 7800 adapter), and I have a JTAG ICE mkII... I'd like to keep using it to play with the Meggy.. Since the Arduino software only supports RS232 and things emulating RS232, that's sort of.. out. Fine, I know AVR studio just fine...let's get the port listing, and see what we've got?

The 'programming information' available seems to focus on 'intro to C' programming, or maybe it's 'intro to AVR'. I'm not sure.

Anyway, when will the REAL documentation be available?

* What is the state of the device after exit from the bootloader?
* Where can you get the latest Meggy bootloader if you should trash it?
* What AVR ports map to what things on the board?
* What is the command set to the LED controller chips?
* The bitfield for the buttons would be nice, but not required.

There's lots of nice artwork there, but.... whatever happened to a real programming manual? With something this small, it could be a paragraph:

Ex: The buttons are tied to Port X. The LED controllers are on port Y. The datasheet for these can be downloaded from here. The speaker is bit 7 on port Z. The serial port can be accessed through UART0, and is available on pins 1, 3, and 7 of the programming connector.

Will something like that become available at any time?

Oh, and Vista absolutely hates your zip files. For some reason, every time there is a folder, say "Examples", there's a a 0 byte file named "Examples" in the same directory. Vista's too stupid to notice that one's a file and one's a folder, and refuses to extract the files. That's just a Vista rant.

Another question is, why force people to use the low-end publicly available tools? Yes, it's nice that they are available. However, they don't seem to be compatible with AVRStudio and it's wide range of device support. For someone who just bought their first AVR project, an investment in an JTAG ICE might not be appropriate. However, since everything's distributed as source for the Arduino compiler, rather than read-to-run .hex files for AVRStudio, even trying out someone's game is impossible.

I find your set of complaints and assumptions more than a bit surprising.

You claim to be "reasonably experienced" with AVR, to the point that our programming guide and example code are useless child's play to you, and yet you apparently haven't bothered to (or don't know how to) read the schematics, code examples, and data sheets that contain the answers that you need. Saying that our documentation is not "real" on that basis is a poor argument. If you want microscopic detail about the LED drivers or how to read the buttons, it's all there.


If you had taken the time to read the intro page of the programming guide, you would know that it's not an introduction to AVR programming, or to C programming, but to our API, as we say, "using easy high-level commands to get Meggy to do cool stuff." The documentation covers two layers of the Meggy Jr RGB API-- both the low-level part and (in much more detail) the high-level part. There are quite a few examples, both simple and complex. But here's the thing: you don't need to use our API. Nobody is making you. As it says right there, you can "start with the circuit diagram and build up your own code from scratch."

Since you're apparently comfortable with using the JTAG ICE mkII, why not just use that? You *can* use AVRstudio-- program through the Meggy Jr RGB's ISP programming port (rather than the bootloader) and do debugging through the debugwire feature of the ATmega168. No bootloader is needed. Period. You can copy over the parts (if any) of the Meggy Jr RGB library that you find acceptable.

We are not forcing you to use any particular tools. Arduino is based on AVR-GCC; it's not a toy. You can pick whichever IDE, libraries, and compiler that you like-- Arduino, AVRstudio, or just AVR-GCC and a command line. If you'd rather use commercial tools, that's fine too. The hardware does not care.

If you want ready-to-try .hex files, you can use the Arduino software to generate them for you, and upload them with AVRstudio. Generating those files requires (for each example program) opening the file and clicking one button; you really should be able to do this. We *will not* advocate distributing the programs as ready-to-run hex files, because different files are required for people with Meggy Jr kits based on the '168 and '328 require different hex code-- distributing hex files only ends in tears.

I apologize for not finding the schematic. It was on the project page, not on the programming page, and in my frustration, I missed it. It answered all of my questions I was looking for.

I did figure out how to build the .hex and .elf files with the Arduino compiler, and got the sample games uploading. I backed up the device first, so I can always restore the original software if I want.

For your typical user (the person who stops by a place like Maker Fair and goes, "Oh, cool...a handheld game console I can build myself", forcing them to learn to use a compiler just to run games is... an unfortunate decision. Compilers are a class of programs which accept source code and emit errors. I'll have to look at the differences between a 168 and a 328 again. When I was looking at them for another project, they appeared to accept the same code (bearing in mind the memory size differences).

And why the Arduino IDE? I'm not going to say that AVRStudio is some user friendly slice of perfection, but... at least it's the standard, and it's also free. Arduino seems to have some... very different ways of doing things.

Anyway, again, I apologize for missing the schematic.

The differences between the '168 and '328 are subtle. The fuse byte configuration is slightly different for no apparent reason, there are some library differences (that's a pre-compile problem), and there are some electrical differences. None of these, except for the memory size change, is an improvement. Another problem with hex files is that they need to be different if the bootloader is used, or not, with an appropriate adjustment of the fuse bytes.

We used to be a bit closer to your camp in how we presented our AVR projects. Many of our early projects (and some of our continuing ones) were based on different AVR types, and were based in AVR-GCC. We taught people how to download the different AVR-GCC based packages for Mac, Windows, and Linux, and told Windows users how to use AVRstudio as well.

A little more than a year ago, we realized that the Arduino had become the absolute de facto standard microcontroller platform for our community-- for hobbyists, artists, students, and the other groups most likely to use our products. There have been some *hundreds of thousands* of Arduino and Arduino-compatible boards sold in the last few years. That's a *huge* community of potential users for us, who are already comfortable with the Arduino environment. Since the modifications to make our circuits Arduino compatible were trivial, it was no-brainer to make the switch. For the first time, people started contributing code back to us, our sales numbers increased dramatically, and so on. It's been a tremendous change. Are we giving up on people who know how to program AVRs on their own? Certainly not, but most of them can either work with Arduino, or at least copy the good parts of the libary to where they would prefer to use it. (We'll think about putting together some standalone AVR-GCC makefiles for Meggy Jr as well....)

Now, I know *hundreds* of people that use Arduino, but I could count on one hand the number of AVRstudio users that I know-- even if I include you. Even if it were fairly popular amongst our readers, we still would not use it as the primary basis for programming examples, because it's Windows only. Yes, the majority of our readers use Windows, but others use Macs, and others Linux-- and our design requirements for kit projects is that they can be used no matter what kind of computer the end user has.

Do we love the Arduino IDE? No. But it's popular, open-source, free, cross-platform, and supported by a tremendous community, which makes it very useful.

As far as forcing users to "learn to use a compiler just to run games," that's a bit of a stretch. The Arduino package hides the compiler pretty well. The user needs to open the program, open the file, select board type and serial port, and hit the button. There's no "learning to use a compiler" in that process. It's invisible and automatic.

If, on the other hand, we required the user to open up AVRstudio, open a hex file, create a AVRstudio project file from it, select target options, configure the fuse bytes, deal with four windows full of unnecessary details, and so on, we're not improving the process in any way that I can see.

Arduino is *by far* the simplest way that I know to reprogram Meggy Jr RGB-- regardless of what file type you're starting with. If you can suggest any cleaner way to distribute and install programs for Meggy Jr (either as code or as binaries) I'm all ears, but AVRstudio certainly isn't it.

Hmm, I'll have to read the datasheets more carefully next time.

I agree. The process of building and uploading code in AVRStudio isn't trivial, nor straightforward.

I'm rather surprised that anyone would use the Arduino IDE for more than a first project or two. Think of the things it's missing:

1. Multiple document interface to modern GUI standards (it may be there, but it's not right by Apple or Microsoft design docs)
2. Multiple code file support. Again, it may be there, but thanks to issue #1, it wasn't obvious.
3. Yet another editor paradigm. When it said, "Upload sketchbook to device", my initial thought was it was some type of graphics editor. It's 2009. We call files...well...files.
4. A processor simulator. Yes, it doesn't help talking to the LED matrix, but the AVRs have a lot of internal hardware that's a pure black box without a simulator/JTAG.
5. A standard language. Yes, it's "BASED" off of C/C++, but.. it's not going to run any C program but it's own style thanks to the built in code that forces you into the "setup"/"loop" entry points. edit: And what if you don't want a loop? My TV-out project was interrupt based. It spent most of it's time asleep.
Edit: 6. Extensive, extensive help. I'd have to say I've had little complaint about the AVRStudio help. Particularly in the programming sections.

Now, I'll admit I'm pampered by Visual Studio, which can be running your program, detect a crash, analyze it, show you the offending line, offer quick suggestions on usual fixes, and then links out to further resources if you're still lost. However, even editors like Textpad/BBEdit can have multiple files open at once. And even Eclipse (shudder) calls things "Projects" and "Files".

As to uploading pre-compiled universal binaries.... as I think about it, this just wasn't something that the AVRs or the dev tools were designed for. Would be interesting to see a compiler that would automatically compile and package up multiple CPU variants of the code, and then the bootloader could figure out which one to write. But, then, that would be another non-standard tool.

Edit: I guess the part that makes this unfortunate is that. we've basically agreed that AVR programs can only be usefully distributed as source. Thus, we all have to agree on the same compiler. The only thing that can compile an Arduino program is the Arduino editor. Thus, to write sharable games, I'd have to work with one hand behind my back, as I think the editor is... not very mature. IDEs are hard to write, and the Arduino IDE is just another example of that.

I really wish that the Arduino IDE had additional white space and better code highlighting-- most IDEs make it much easier to read long files. Not to mention ways to jump to specific parts of the code.

The Arduino IDE *does* support multiple code files (see here) but does not support having more than one window open at a time. You can #include additional code files or put them in separate tabs within the main window. (Why it's this way is completely beyond me. The parent project, Processing, has the same basic IDE, but allows multiple windows.)

I personally don't feel much need for a simulator. I've found it just fine to send debugging data over the serial port or (sometimes) use the graphical display to watch a number of registers. If this is something that you use often, you are almost certainly better off sticking with a different system.

Arduino is a "friendly" brand name wrapped around C++, with a bunch of libraries available, and certain hardware initialization code that is normally executed. When I start a program for Arduino, I usually write straight C that compiles in AVR-GCC, then copy and paste my code into the Arduino window. The part of main() before the main loop goes into setup(), and the main loop goes into loop(). Stuff before main goes outside those functions, of course. If your program is interrupt based (as many are), you can leave loop() empty-- that's a common trick. You can even put your own main loop inside setup, such that it never leaves-- that works too. The only "Arduino" function that I use regularly is the millisecond timer, millis(), but that can be replicated outside as well.

There is actually a lot of help and reference data at the Arduino site. I usually keep the extended reference page open while using that environment.

I just did a google search about programming with the Arduino libraries from within AVRstudio. Looks like it's slightly difficult because AVRstudio does not support C++... which maybe suggests that I should put together an independent non-arduino library for Meggy Jr RGB. That won't help with all of contributed code, but we can at least get our own examples up.

Also, on the topic of "binary" uploading, since Arduino is open source, it wouldn't be too hard to strip it down to a custom version of the program that *just* uploads programs to Meggy Jr-- where you wouldn't have to look at code or pick through unnecessary menu items.

Yeah I noticed right away that the Arduino tool was not really yet a true code editor app, but who cares it shouldn't need to reinvent the wheel. You can still use whatever editor you like (Notepad++ is FREE and good or Slick Edit or Ultra Edit etc). You can have the code file open in both places at once and I think there was a 'read only' or 'external editor' option or some such bit in Arduino IDE. Use the editor to edit, and then arduino for the compiling, libraries, sketches/projects, board communications and such. Its like bread and butter!
Steve