Unflushed Buffers

Welcome to AVRFreaks who have come to check out my blog through my forum posts. I’m just starting out on the AVR platform but have found your advice helpful and productive. I noticed a small spike in new visitors lately.

I apologise for the slow speed of the site lately. I’m having bandwidth issues. The site is run off an ADSL2+ link but I have chewed through my cap this month due to a couple of remote offsite backups. Should be back to normal next week. I might move the site to a virtual machine hosted elsewhere, but I will have to configure a new server with specific needs (LAMPS with SVN, VPN, etc) since many web hosting companies do not offer SVN, mod_python and some not even PHP5 (PHP4 is sooooo 2004!).

In the meantime I’ve added some simple code snippets for the AVR to the SVN. You can take a look at them here. These were to test small parts of BeerReg2 which is coming together nicely and hope to have more news about that project within the week.

A silly notion of a wandering mind. Right now this is on the backburner, but I may come back to it one day soon when I get stuck on something else. Was a good intro to USB and Linux driver development.

Right now I have an old Windows box with the AVRFlashv2 programmer for the EasyAVR board running so I can program the board with my avr-gcc compiled programs built on my Linux workstation. Eventually I’d like to get rid of the Windows box. I’ll probably end up making a serial programmer that can plug into the PORTx pin headers on the board to side-step the USB programmer altogether but I thought I’d spend a couple of hours checking out USB and Linux.

Since the USB programmer on the EasyAVR is undocumented, I spent some time sniffing the USB packets with SnoopyPro. I ended up with a bunch of log files for each action of the programmer (erasing, writing the flash, writing the eprom, programming the fuse and lock bits, etc). I found each transaction rather convoluted, and probably unnecessary. For example, I flashed two different .hex files, and the USB packet transfers were almost identical apart from packets 64-66 where the program was sent to the device using an Isosynchronous transfer.

My next step was to get Linux to do some basic communicating with the dev board. I found this Linux Journal article explaining kernel USB driver basics. Initially I wrote a kernel USB device driver based on the USB skeleton driver, and got the driver to acknowledge the existence of the device. I then got it to send and receive some Bulk Transfers of things like “0501″ to see how the device would respond and it did so according to the previous USB packets I’d sniffed earlier.

A bit more googling and reading I found that I could talk to the USB bus using the userspace USB library libusb. I was all set to start writing a little programming or shell where I could send and receive packets as a test to the device (see source below), when I noticed that libusb v0.1 which comes with Ubuntu, did not support the asynchronous transfers. Looking at the USB packet logs, the program is flashed to the device using these Isosynchronous transfer packets. Doh!

The development branch of libusb (v1.0) does support asynchronous transfers via kernel callback functions. I’ve gotten the source (from the Sourceforge SVN) to compile with some difficulty but since it’s getting late and I haven’t finished other stuff, this will have to be explored at another time.

My initial easyavr1.c:

/*    $Id: easyavr1.c 4 2008-05-14 07:29:31Z faulteh $
*
*     Version 0.1 ($Rev: 4 $)
*     $Author: faulteh $
*     $Date: 2008-05-14 17:29:31 +1000 (Wed, 14 May 2008) $
*
*     Description:
*         Testing source for communication with EasyAVR over USB on Linux
*
*/

#define EASYAVR_IDVENDOR 0×3e1a
#define EASYAVR_IDPRODUCT 0×0200

#include <stdio.h>
#include <usb.h>

static struct usb_device *findEasyAVR(uint16_t vendor, uint16_t product)
{
struct usb_bus *bus;
struct usb_device *dev;
struct usb_bus *busses;

usb_init();
usb_find_busses();
usb_find_devices();

busses = usb_get_busses();

for (bus = busses; bus; bus = bus->next)
for (dev = bus->devices; dev; dev = dev->next)
if ((dev->descriptor.idVendor == vendor) && (dev->descriptor.idProduct == product))
return dev;

return NULL;
}

int main (int argc,char **argv)
{
// Get hold of the USB device
struct usb_device *dev;

dev = findEasyAVR(EASYAVR_IDVENDOR,EASYAVR_IDPRODUCT);

// We didn’t find it
if (dev == NULL) {
fprintf(stderr, “Dev Board not found.\n”);
return 1;
}

// We found it, now we can send stuff to it.
printf(”Found Dev Board\n”);

return 0;
}

OK I’m a new user on AVR Freaks but I have been reading a lot of articles in their forums and wiki this week. Since I just wrote my last post reviewing all the AVR IDE’s I’ve been using as I get my footing on this platform, I thought I’d help the Wiki by writing instructions on installing and using the AVR Plugin for Eclipse, since this seemed to be missing from the wiki.

View my instructions on the Wiki.

The first draft was a bit longer, but I accidentally browsed away from the page and lost my edit!! Doh!

This is kind of a review of sorts of a few items. Lately I’ve been trying to find efficient development tools to go with my AVR development board from Microelectronika. This board came with their MicroBasic IDE/Compiler, but it’s for Win32. Unfortunately the dev board is programmed via a proprietary USB interface so I need to fire up an old Windows box just to program the ATMega16 chip on it.

MikroBasic

I gave the MicroBasic IDE a work out when testing the development board features but found the language a little limiting for my taste, or maybe I’m just old-school. One example of what I didn’t like is that say the 1Wire library it used made use of a timer, which I didn’t know initially until I looked at the source, and that meant that I couldn’t use that timer for anything else, or combine it’s function with the 1Wire interface. Apart from that it’s a solid language and IDE for a beginner developing for this embedded system.

AVR Studio

The AVR chip can be used with the avr-gcc toolchain on Win32 and Linux. You’d know by know I’d prefer Linux but the first C hello world style program came up with compile/linker errors because I don’t code C very often and my Makefile vis a vis cross compiling skills were rusty. So I thought I’d get the basics down with some of the Win32 tools first. I really like the AVR 8bit chips as they are very open source friendly working with GCC and all.

Initially I installed AVR Studio 4 and the WinAVR toolchain. The AVR Studio IDE is straightforward, as is the simulation interface for testing/debugging. It’s plain but it works. I like how you can see the chip internals as the simulation runs (slowly).

VMLab

As I was looking up some information I found a link to VMLab, another free IDE that showed more promise in the simulation department. In fact it was pretty good to start with. Not only could you get debug output of things like chip registers, but also C source variable watching. Then the tasty treat.

In the project file, you can define the circuit you are connecting the ATMega chip to just like a little SPICE circuit to add things like switches, LEDs, LCDs, Serial TTY’s among other things. Woah this was GOOD! The code editiing features were reasonable and plain as well, but I prefer the window docking/layout features of AVR Studio rather than the old style MVP(?) win32 application layout.

Here’s an example of adding a TTY (Serial) to the AVR program I was simulating. Easy, huh?

; Micro nodes: RESET, AREF, PA0-PA7, PB0-PB7, PC0-PC7, PD0-PD7, ACO, TIM1OVF
; Define here the hardware around the micro
; ————————————————————

X1  TTY(38400 8 0 0 1 1) PD0 PD1

The code editor didn’t do any code highlighting in .h files, only .c files which led me back to AVR Studio for a while. I was developing bits of the BeerReg2 program in VMLAB as separate mini-projects and then when they worked in simulation moving them into the main BeerReg2 in AVR Studio when I noticed something strange.

For about an hour my code would compile fine in AVR Studio, but would not work as intended when programmed to the development board. This was quite frustrating as in simulation it worked fine, but only half of the program worked properly on hardware. Then I compiled with VMLab and loaded the hex file on the board and found the same code worked properly in simulation and hardware! There was obviously something different between the two make processes in the two IDEs. Finally I had a reason to look, not for the reason, but another solution…

Eclipse

I have been doing much of my coding on other projects using the Eclipse IDE on my Linux workstation. It handles C/C++, Python, and many other languages very well. I like it a lot. I like the fact you can add functionality by downloading and installing new modules. First I got the PyDev module to handle Python code, then I added the Subclipse module so it integrated my Subversion source control seamlessly. It’s interface is very intuitive.

As I was researching some avr-gcc things along the way I found an article about using WinAVR with Eclipse and so followed these instructions. Then I found they were a bit dated and the Eclipse UI had changed since it was written, so I found someone had written an AVR Plugin for Eclipse. Bingo!

After reading the instructions and installing the plugin on an Eclipse/Win32 setup I found I could not follow some of the instructions for some reason (I can’t recall). I was about to give up when I went back to my Linux desktop and it’s Eclipse installation. I installed the AVR Plugin through the Eclipse update system and installed the AVR toolchain and related packages that Ubuntu carries in its repositories.

BAM! Opening a new C Project gave me the option to build a AVR cross compiled application! Then I copied in my code from another project, the syntax highlighting showed me an obvious mistake I had made within seconds, and Eclipse was set to build automatically which meant that syntax errors were also pointed out to me with glaring obviousness! I had found my AVR IDE, and it’s the IDE I’ve been using for several months already.

However the Eclipse IDE doesn’t have Simulation/Debugging capabilities that VMLab/AVRStudio has. That doesn’t worry me too much because I am much more comfortable with this environment and I just load the .hex files built with Eclipse/avr-gcc to the development board and test on real hardware much faster than simulating in a slow emulated environment. Shortly I think I’ll be looking at some of the AVR packages I installed from the Ubuntu repositories like simulavr may cover any simulation requirements I may need.

Microelectronika EasyAVR/USB Programmer

This means I’m developing for my favourite embedded chips, AVR, on my favourite desktop environment, Ubuntu Linux. The only step not taken is the programmer which uses a proprietary USB interface to program the development board. I’ll fix this issue soon as well, either by wiring up a simple parallel/serial programmer and plug it in to the appropriate pins on the development board (therefore bypassing the USB interface all together) or some other hack (RE anyone?).

I looked at the Microelectronika forums about Linux support for the EasyAVR boards, and found some requests for it with answers saying they were looking into Linux support with more information coming ’soon’. But these were posts from 2005 and 2006 and 2007. Thinking about it, this company has no interest supporting Linux since they want you to buy their MicroBasic or MicroPascal compilers rather than develop in C using free open source software. So I doubt they will really ‘finish’ their port of the programmer to Linux any time soon.

FreeRTOS

More of a footnote really. Again, as I was wading my way through some AVR forums at places like AVRFreaks and WinAVR.Scienceprog.com, I found a PDF about multitasking on the AVR 8 bit, using FreeRTOS, a GPL’d real time scheduler. The demo application included in the source was for an ATMega323, which is now been replaced by the ATMega32. Looking at my development board, I think I can replace the ATMega16 on it with the ATMega32, and also change the crystal to 20MHz from it’s current 8MHz. VERY VERY COOL.

I’ve taken a look of the code for RTOS to get a feel for it, and I am very impressed so far. I compiled the demo application in AVR Studio/WinAVR so I could try it in simulation, and I already have some project ideas scribbled on my notepad to look into. So, expect some RTOS review or project on this site in the near future.

This phracking sux, and has for a long time. Because the URL of this page (and my other Scriptforge pages) have ‘.scr’ in the domain (www.SCRriptforge) Microsoft feels I am dangerous and silently drops my message. This makes it incredibly hard for me to share my URLs with friends.

Now it seems that the bastards are also blocking YouTube links because they have started a competing service.

FUCK YOU MICROSOFT.

In a week I’m turning off my MSN account, since I have moved most of my contacts to other IM services (Google Talk / Skype). I’m sorry if this means I’ll be missing out on talking to one or two people, but MS is retarded, and by extension anyone who keeps using it is also.

Just an announcement really. Apart from a quick sketch and a new project page, there’s no real information yet.

Due to the cold temperature, we are making a temperature controlled cupboard to house the fermenting beer. This will keep the yeast happy. If the yeast is happy it will make good beer, which keeps me happy.

Researchers Prove Existence of New Basic Element for Electronic Circuits — ‘Memristor’ from PhysOrg.com

HP today announced that researchers from HP Labs have proven the existence of what had previously been only theorized as the fourth fundamental circuit element in electrical engineering.

[...]

OK I won’t be commenting on other web pages/news articles much but articles like these seem important. I just finished an Advanced Diploma in Electrical Technology last year so I thought I’d finally gotten a decent grasp of the fundamentals. Now someone goes and invents a new one! ARRRGH!!

In all seriousness this is has the potential to make authors rewrite new editions of electronic text books with a new chapter. Although there has been many technological advances by way of the transistor in regards to digital electronics, not much has really changed in the last 50 years and I was able to use old editions of texts to learn my trade (from my own library, I’ve been interested in electronics since I was knee high to a grasshopper). Things have just gotten smaller and more efficient, t’is all.

As a sidenote, it is still difficult to judge where the future of computing and electronics will take us. Sure there will still be electrical devices in the future, but advances are also being made in photonic/optical devices for computing, which have the ability to speed up computer processing much more than electrical (ie electrons) systems. So this may be a new device, and may also find its way into memory systems in our computers in the next decade or so, photonics is a great and challenging field to keep an eye on.

I had to say that, because the idea of a memristor is not knew. The source of the discovery, HP labs, says that

The memristor first appeared in a 1971 paper published by Professor Leon Chua, a distinguished faculty member in the Electrical Engineering and Computer Sciences Department of the University of California Berkeley.

It has just taken this long to figure out how to make a practical use of it.

This release adds a simple event log for the log viewer, and tools for user management (add, modify, delete), as well as cleaning up some of the HTML.

I have held back adding features for annotating, bookmarking and sign-off until the next version.

Visit the project page or SVN repository.

While adding a login/logout feature to the logview1 project, I found the documentation a little sketchy. Fortunately Python is very easy to figure out, so I wrote a basic mechanism. You can find the code here in the SVN repository.

So when you try the main handler, http://blahblah/basedir/sessions_login.py/query it will redirect to a login screen until you are authenticated. Apart from that it’s a simple hit counter. It checks login name and password against a database table and sets session information.