Ubuntu

A slip of the fingers in Slackware recently, and I entered a twilight zone of mis-matched libraries. All I wanted to do was to update a video-editing package, and 2 days later my wife asked me "why is it so hard?". I didn't have a good answer. I've been using Slackware for 7 years, and since most of what I do is editing and compiling code, it seemed Just Right. More recently, I've been drawing logos, editing movies and requiring a bit more integration at the desktop level. It seemed Just Right for that too, until I experienced the library issue.

Perhaps a knee-jerk reaction, but I thought I'd give one of the more glossy distros a try. I'd installed Kubuntu on my wife's PC some time ago, but the 'Skype issue' forced an install of a proprietary operating system. I don't use Skype, and I'm not very keen on the KDE desktop either, so I installed Ubuntu. I got a bit of a shock at the outset, when it failed to start X for the install GUI. I haven't a clue why. I use a 1280x800 laptop screen with a 1280x1024 screen next to it. Perhaps there was a way to get round it more sensibly, but I edited the xorg.conf to change the display driver from 'vesa' to 'vga'. The install GUI was a pain to navigate at 640x480, but the pain soon went away when the install completed.

There's a lot to do, to move from a well-used environment to a new one. It's like moving house. Nothing works at first, and everything you normally use is hidden away in boxes, and they don't quite fit right when you find them. Ubuntu makes life easy with its package management system. At first, I had to exercise extreme restraint to force myself to use only the GUI configuration tools and not to open a terminal and start bodging. It's going okay, it really is. Some click-to-install DVD creation software has meant my 22-month-old daughter has some new movies and cartoons to watch, without me breaking a sweat.

What I'm missing most from my old setup is ROX-Filer. Nautilus works great, at first use, but compared to ROX, there just seems to be a lot missing. And it's SLOOOOOOOWWW. It does have some sort of script extension facility though, so ROX's "Terminal here" facility is available to download for Nautilus via the Ubuntu package management facility. Just now though, I wanted to copy over one of those scripts that I used frequently in ROX (I don't like to use IDEs, instead I start a script for each source file I'm editing that waits for changes using inotify before compiling the file - it makes the text-editor's save button work like a 'compile' button). The first place I looked in the old ROX directory structure had a symbolic link to the original script. In ROX, you can right-click a symbolic link and 'follow' it to the original. There appears to be no such feature in Nautilus. I found nautilus-follow-symlink, but this has yet to be incorporated into the Ubuntu package management system. Compiling this little feature requires a few visits to the package management system to install some extra files, I'm up to nearly 60 files and over 15MB of download so far. It compiles after a few tries, some autoconf issues that it mysteriously gets over, I think. Finally, I restart nautilus and find a link to right click on. Nautilus hangs.

I thought about replacing nautilus with ROX-Filer, but it didn't look straightforward to me, and if I'm going to choose a linux distro based on someone else's guarantee that everything will Just Work, it seems to me that I should interfere with it as little as possible. I'm going to miss ROX. I'm going to check regularly to see if the follow link function turns up in nautilus.

Then a month flew past

And I started a gazillion new projects without finishing any of the others. I must try to think of what it was I did in all that time.

I've just been searching for help for a problem I'm having with IE7. I'm writing a web server to manage a community site that allows access to some local hardware, so I use several different browsers to make sure requests are handled correctly, pages display correctly etc.

It's all going fairly well. I've used a browser almost every time I've touched a computer since I fell in love with NCSA's Mosaic in my first year at uni in 1993. I rarely encounter really awful problems with browsers, they always seem to JustWork(TM). OK, maybe I've got loyal habits, I've followed the Mosaic, Navigator, Firefox path, and only now am I looking at other browsers to make sure I'm not sending goop to people with more adventurous (or commercial) tastes.

Having looked at what a browser sends to a web server, I can't believe all this stuff seems to work so well! I'm writing my web server in Java, just plain old SE, no bells or whistles, so I'm parsing all the requests with my own code. It's a nightmare in there! If you're in the business of writing popular web servers, then you have my respect.

Anyway, back to IE7. I see people having the same problem, but no really helpful replies. My web server uses a cookie to track a user's session. When I browse my site with IE7, I can follow links OK, but on one page, can't use the 'back' button. IE7 gives me one of its very clear, but ultimately very useless, error pages:

(i) Webpage has expired

I include no expiry data in the pages I'm serving (yet), and using the 'back' function in some of the other browsers I'm testing (Firefox, Gecko, Konqueror) works exactly as expected. The page it happens on is generated by a POST request from the previous page - a file upload. That page includes thumbnails with links to original documents. I press the back button on the page with the original document displayed on it, to get the error in IE7.

Perhaps IE is being overly pernickety about the POST request. In the HTTP docs from www.w3.org, the POST request is described as a method to change the content of the server, and should be replied to with a 200 'OK' response, if the new content can't be identified with an URI. The files I'm uploading certainly can be identified by URI again, so I should do what the RFC suggests and return a 201 response, with a new URI. I'll try that tomorrow, and see if that fixes the problem.

Silicon Labs F530 and C2 Flash Programming AN127

This should be the last word on this. The VDDMON change posted earlier is the one change that must be made to the code in AN127. The FPI initialisation sequence is possibly a red herring. I tried the sequence of 0x02, 0x01 from AN127, and it works just fine. Intrigued as to why two different sequences appear to work, I tried 0x02 on its own (doesn't work) and 0x01 (appears to work). The tests were separated by warm resets (RST line low), so there's possibly some chance the initialisation was surviving the reset, but now that this hurdle to progress has gone, I've lost all interest!

At last! C2 Flash Programming the C8051F530TB

I spent a great part of the afternoon ploughing through the C2 commands being sent from Silabs' IDE, trying to find the clues I needed to get my embedded C2 programmer to work. I could see the packets of data becoming more dense after 100ms or so, but it was taking me more than an hour to analyse 10ms of data. I was just about there - though that doesn't mean much. As I noted earlier, there wasn't anything in the C2 traffic that actually looked like a device erase. Once I found a device erase command, I'd have to work back through the C2 commands to find out which one or combination actually accomplished the erase.

ec2drv now supports F530

Ricky was in touch about the ec2drv software, he'd looked through the debugging logs I'd sent him and spotted the messages that made writes and erases work. He mentioned the VDDMON register, as had one of the posters at the Silicon Labs forum I posted to, but included the register address (0xff) in his remark. That explains the WAffWD and WAffRD messages in the previous posts! After a quick read of the datasheet, it seems it's necessary to prepare the VDD monitor, allow it to settle (there's a flag to check), and then set it to a high level before flash programming or erasing. Once I'd added that to the code I'd written, it worked first time! Ec2drv seems to fully support the F530 now, so I'll be glad to get back to Linux for developing on the F530. All I needed was some way of writing my code to the Silicon Labs boards, and the only way (up until today) was by using their IDE on Windows.

If you're hung up on your implementation of Silicon Labs' AN127, and you're using F530 or F520 parts, all you need to do is to change the FPI initialisation to 0x02, 0x04, 0x01 (AN127 says 0x02, 0x01). And add the VDDMON setup code to your FPI initialisation. Happy flashing!

Tired. Deja bu and the Malaysian bathroom.

Tired today. My 16-month old daughter was struggling with her milk last night. Then she rolled off the edge of the sofa and banged her head on the floor. Floors are almost always tiled here, so it's a hard landing. She seemed a bit inconsolable, then the note of the cries plunged like something from the Exorcist, and I was wearing her last 3 meals all over my neck and back.

One advantage of living in the tropics is the bathrooms are 'hose-down'. We had a varnished pine floor in our house in the UK, with painted walls. We always worried about splashing water out of the bath. Here, there are no bathtubs, just what is locally called a 'water heater' on the wall. It's optional: when you buy a house, chances are there's a shower head attached directly to the water feed for the bathroom. The water heaters are an added luxury, but not really necessary. The bathroom temperature must be at least 30C, and I suspect the 'cold' water is at least 20C. Since it comes from a tank in the attic, it may even be 30C. The 'bathrooms' are just tiled rooms, wall and floor, and invariably have a short hose on the wall near the toilet. Perhaps I'll write a full article about that hose sometime.

The short hose is handy when you're a vomit-covered parent and child, you just go into the bathroom and spray both of you off. There's a drain in the floor, in one corner. The drain in the downstairs bathroom hasn't been draining at all well recently, and when the washing machine (which is just outside the bathroom) and the shower are in use together, the drain briefly overflows. Last night, just as I was feeling lucky I had a hose-down bathroom, the drain stopped making noise, and bits of undigested baby food started popping up through the holes in the cover. A chill ran down my back, just writing that sentence. My wife took our very subdued daughter away to complete her cleanup and change her into fresh pyjamas. I sploshed around in the dilute vomit and wondered what to do next.

We'd bought a plunger when the drain first showed signs of blocking, and it did seem to marginally improve things. I used it last night, and as the hours went by, the water on the floor became clearer and clearer, and then actually dropped below the level of the cover. By that time, I had got over my revulsion at the soup I was standing in, so I conducted a 'manual investigation' of the drain. It's a big pipe, so a hand goes in easily. Just below the drain cover, I could feel bare concrete - the down pipe mustn't have come up far enough when they laid the floor, so I'm guessing they just stuffed a bag in the top and laid concrete up to that, before sticking the cover over the bare concrete. about 6 or 7cm down, I could feel the sides of a plastic pipe descending. At about 15cm, I could feel a smaller pipe entering from the direction of the handbasin - I recall the builders used the same pipe for the washing machine waste.

At about 30cm down (almost elbow depth), another small pipe could be felt, this time on the side of the pipe facing the back door. This ought to be the exit, but the pipe comes into the larger downpipe by more than a centimetre. Feeling around this pipe, it's obvious that there's no joint there. There's a jagged hole in the larger pipe with bits of soft concrete protruding through the gaps around the smaller pipe, and in places gaps that I could push my finger into, with something soft inside. I couldn't decide whether this pipe entered or left the larger pipe, so I felt further down. Just as my elbow went under the surface (face uncomfortably close to the bobbing carrot and milk curds), I could feel a pile of rubble. I fished out a few 8cm diameter lumps of the concrete they used as a substrate for tiling, and felt again.

The larger pipe's walls were smooth down to about 40cm below floor level. At the bottom of the pipe is soft, like very wet mud. At the edges of the soft bottom, I could feel the end of the large pipe. WTF? There's no end to this pipe, other than the dirt the house is built on. Capping the lower small pipe with the palm of my hand, I could feel a very soft suction - that pipe is the exit for the drain water. I'm guessing some drain water must just sink in the mud at the bottom of the pipe. I tried pushing a hose into the exit pipe and running some water into it, but all that did was add black silt to the dilute vomit I was standing in. I cleaned up as best I could and went to bed.

This morning, the level of water in the drain had dropped far enough for me to see what I was feeling last night. The down pipe is actually two short lengths of larger pipe of slightly different diameter, one pushed into the other. I suspect the upper section was added by the tiler who tiled all the floors in our house. Why didn't he add a longer piece? The two smaller pipes enter the larger pipes through holes that look like they were cut with a craft knife; jagged, with great gaps all around the smaller pipes.

My wife says one of her brothers has some drain rods and maybe a power washer at his factory. In the UK, I'd be straight on the telephone to the Lone Drainer, but here, I think I'd rather do it myself. I've paid for some very disappointing work here. In preparation, I lifted the drain inspection hatch by the back door. I cannot adequately convey my feelings. The chamber beneath has smooth concrete walls, perhaps a metre deep. The chamber itself is about 30cm by 50cm. The walls appeared to be moving as I lifted the hatch, but when my eyes became accustomed to the gloom beneath my feet, I could see that I'd woken up several dozen cockroaches, from peanut size up to thumb sized. I was shuddering so much, I think I pulled a muscle in my neck.

I fetched the hose from the parking area outside, and washed off the walls of the inspection chamber. It's briefly satisfying to see all the cockroaches wash down into the sewer, but they start coming back within a second or two of turning the hose off. There are 3 large pipes emptying into the chamber. One is for the toilet in the downstairs bathroom, One must be for the bathroom upstairs, and the third has a slow trickle of water coming out of it. The slowly trickling pipe has silt in the bottom of the pipe where the other two do not. I'm guessing that pipe is the exit for the bathroom drain.

I'm really not looking forward to this job.

C8051F530 erase by IDE: part 2

The next C2 packet is at 37ms. I've got a sneaking suspicion the IDE does this erase 2 or 3 different ways. Using the scope to capture this packet takes 2 or 3 tries. When it's in the sample window, it's dead centre every time. It never appears off-centre, it just is there or it isn't. The packet is WAa0WD80. This C2 register is read at 32ms, and returns the value 0x80. I'm completely in the dark. Again.

There's another short packet at 39ms: WAffWDe0, a write of e0 to C2 register ff, no clue still.

There's a large packet at 42ms:

WAb4WD06RA00RA01WAb4RD0dWAb4WD00RA00WAb4WD00RA00
WAb4WD01RA00RA01WAb4RD0dRA01WAb4RDff

This sequence is in AN127 - it's a read flash block command (0x06). This one reads 1 byte from 0x0000. By this stage I've flashed this device over and over, so of course, the byte is 0xff.

The last few packets I caught were at 43ms: WAffWDc0 (a write of c0 to C2 register ff, similar to 39ms). Another short packet at 47ms: WAa0RD80, similar to packets at 32ms and 37ms. A packet at 49ms is WAa0WD90, perhaps a response to the previous packet?

I have another packet captured at 50ms that is identical to that captured at 42ms. My sampling window for these captures is only 0.5ms long, so I have no idea whether both packets exist in the same erase traffic.

The last packet I captured is at 53ms:

WAb4WD09RA10RA11WAb4RD0dWAb4WDefRA10WAb4WD01RA11RA11
WAb4RD4a

I've broken the lines this way to compare with the (known) packet at 42ms. This is a 'command 0x09' to the FPI. It seems to take a 2 byte argument (the top line). It then reads FPDAT, and gets 0x4a. The read flash block command would read FPDAT for the FPI command status at this point. AN127 has all commands that read the FPI status and don't get a 0x0d response, abort.

That's the last packet I captured. The one useful attack may be that read command at 42ms. If I can fill memory with something other than ff, and capture that packet again, I'll know whether the erase has happened before that packet (it reads ff) or it happens after (it reads the fill byte).

I used a 0x55 fill byte. It took me 5 tries, but the packet I have reads:

WAb4WD06RA00RA01WAb4RD0dWAb4WD00RA00WAb4WD00RA00
WAb4WD01RA00RA01WAb4RD0dRA01WAb4RD55

Oh noes! It has read 0x55 from 0x0000, so this is before the reset! Well, that's a bit disappointing. But then, there wasn't anything that really looked like any of the reset commands from AN127.

To bed I think, this problem is for another day.

C8051F530 erase device

Collected quite a few C2 packets today. About time I had a look through them and figured out what to do next. A quick recap: I've written some assembly routines on one Silabs processor to send C2 commands to another, using their application note AN127 as a guide. The code will read the target device, but not write to it, nor erase it. I've had no replies to emails to Silicon Labs about this issue, so I thought I'd check to see how their IDE erased the device. Uh oh, a thought just struck me... there's a lot of traffic between the IDE and the target during an erase, perhaps there's a simpler utility somewhere that would reduce the amount of traffic. I might have been too hasty... checking... uh oh, there is a "Flash Utility"... does it simplify things... hang on...

Flash utility: connect

First check with the Flash Utility is connect. Scope shows at least 50ms of traffic. A first packet, then a gap of 20ms, then more packets every 3ms or so. That gap is suspicious - the same thing occurs with device erase from the IDE, and according to AN127:

Before performing any FPI commands, the FPI
must be initialized with the following sequence:
1. Reset the target device.
2. Wait at least 2 μs.
3. Write the following key codes to FPCTL: 0x02,
0x01.
4. Wait at least 20 ms.

The oscilloscope trace is courtesy of my Java scope utility. The scope itself will only show about half the data that you can see in the image, but the utility displays the whole sample buffer. Quite nifty. The scope utility is running on the Linux desktop I'm using now. The Silicon Labs IDE is Windows only, so that's running on a laptop next to my screen. It's raised up on a crate so the screen is similar height to that on the desktop. I use the brilliant Synergy software from sourceforge.net so that I can use my desktop mouse and keyboard to control both machines. The Java utility controls the scope too, so I can set up the scope from my desktop screen, then mouse over (from my desktop screen to the laptop screen!) and use the IDE, same keyboard and mouse - marvellous!

Flash utility erase

So I'm wondering if the first packet isn't the flash programming key codes. Anyway, the connect from the utility doesn't seem to be any simpler than the connect from the IDE. Let me check the device erase... looks very similar to the IDE erase, at least for the first 50ms. There's the same several-second pause, then a dialog. I'm not convinced it's worth looking further. Just one more try - see how long the traffic goes on for. Looks like heavy traffic for about 450ms - I suspect this must be a verify. I'm not sure why the long pause. Looking at traffic up 4 seconds, the scope shows nothing - but I'm looking at 1s at a time, so my scope may be missing a very short packet.

Flash utility set memory

The memory fill utility looks curious. According to AN127, the target device's Flash Programming Interface (FPI) must first be reset (a C2CK low for >20us), then wait 2us, then writes key codes 0x02, 0c01 to FPCTL, then wait at least 20ms. The 20ms wait is plainly visible in the trace above, but does not occur at the start of the memory fill. Curioser and curioser. There seems to be about 400ms of memory fill traffic, but the obvious hole a 20ms wait would leave just isn't there.

The IDE's device erase traffic

I felt lucky today, so I captured a bit more of the device erase traffic. It became apparent to me after several captures that the traffic's timing was so unreliable, I couldn't be sure I was capturing all the packets, or even that I have the sequence right. There are some interesting ones though. The first thing that happens is that the IDE resets the target, writes 0x02, 0x04, 0x01 to the target, and then waits 20ms. This is just like the section in AN127 that describes initialising the FPI, but with different codes.

The second packet comes after the 20ms wait: WA00RD11 - haven't a clue. The third packet has a bit more to it. It's different to what I thought was the third packet before - perhaps I was counting from after the wait? Hmmm, must be more methodical! It's straightforward: WA00RD11WA01RD00 is fetching the device id (0x11) and revision (0x00). A big packet follows:

WAb4WD01RA00RA01WAb4RD0dRA01WAb4RD03
WAb4WD02RA00RA01WAb4RD0dRA01WAb4RD97

I don't understand what this packet is doing, as I posted earlier. A packet follows this one (I'm not giving packet numbers any more, I'm not convinced I've got this right!) WAffRDc0 - again, I don't know. That packet appears at either 27 or 28ms. Another short packet appears after this one, around 32ms, WAa0RD80 - another don't know, though they look like reads of C2 registers. Who knows what those registers are?

Two big packets follow, at 33ms:

WAb4WD09RA10RA11WAb4RD0dWAb4WDa7RA10WAb4WD01RA11RA11WAb4RD00

and at 35ms:

WAb4WD09RA10RA11WAb4RD0dWAb4WDefRA10WAb4WD01RA11RA11WAb4RD4a

The pattern of the two packets is familiar. In AN127, commands to the FPI via FPDAT (register b4) follow a similar routine. The WAb4WDxx is an FPI command. Poll for InBusy does a RA until the 1 (7-0) bit is reset, hence just one RA10. Before reading, a RA is used to poll OutReady, which checks the 0 bit is set, hence just one RA11. The FPI Command Status is checked next, that's the WAb4RD0d. 0d is good-to-go. Whatever command 09 is, it seems to take a 2-byte (possible address?) argument. The WAb4WDa7RA10 is the write-byte-check-InBusy for the byte a7, The WAb4WD01RA11 is the same for the byte 01. The last part of the command (perhaps the return value?) is RA11 - poll OutReady, and a single byte is read from FPDAT: 00.

If 09 is a command, then perhaps it's a read of the reserved flash. The address used by the first command is a701, the second uses ef01, and has the value 4a returned. All speculation!

This is very slow going. I can hear my wife in the living room asking my daughter "Where is your naughty daddy?". Oh loko at the time! I'd better finish this later!

Following links: Project Euler

I was just trying to update the wiki on Google's code hosting site, where I put the java GDS-2062 utility. I wanted to add an image, to make it look nice, they're worth a thousand words, you know. And this was only 5k in size, so that's a thousand 4-letter words! Anyway, I ended up looking at a page that had no relevance to my search, it just happened to have the search terms scattered about on it. And there was a blog entry for the Project Euler website. The author of the page (Doug Daniels) had posted some Java code, and before I could stop myself, I was trapped. "That looks like it should be easier than that" I was thinking, and then an hour or so of my afternoon disappeared.

Project Euler lists maths problems. The one the author had posted on his blog was to find the sum of the natural numbers below 1000 that are multiples of 3 or 5. Doug Daniels was on the right track - he posted an equation for the sum of a series, and I used it. The answer to the problem is the sum of all 3-multiple numbers plus the sum of all 5-multiple numbers minus the sum of all 15-multiple numbers. Project Euler told me my answer was wrong. Doug had posted the equation shown here, which appears to have at least one error in it. That minus sign should be a plus, and perhaps the n to the right of the sigma should be a k.

I was pleased to see this equation, I remember its derivation in school as a moment of insight. Anyway, I wrote a reply to Doug's blog, explaining the derivation of the formula and a way of writing down the answer as a one-liner in Java. When I submitted my reply, the blog page came back with no indication I'd ever written anything. I would have been happier to have got a page saying "I've /dev/nulled your smug reply, you big-headed tosser". But there was nothing at all...

So you're going to get it, now. That sum of series. You need it to add up all the multiples of 3 and of 5, and of 15 under 1000. There are 333 multiples of 3 under 1000, from 3 to 999, so you can use the sum equation to calculate 3 times the sum of 1-333. To answer the problem, you could sum the multiples of 3, add the multiples of 5, and then subtract one sum of the multiples of 15, because they were in both series.

You need an equation that works though, so how to sum up numbers from 1 to whatever (n as a mathematician would say)? Write the numbers down in a row, 1 on the left, n on the right. Write a zero to the left of the 1. Under the zero, write the same series down, but starting with n on the left, under the top row's zero, and counting down until you write down 0 under the top row's n. If you add up each column (2 numbers in each column), starting from (0 + n) on the left, and ending with (n + 0) on the right, you'll see that every column sums to n. And there are n + 1 columns (because we added a zero column). Adding the zero doesn't affect the sum, obviously, it just helps the maths work out nicely. Look at what you've written down. There are two of the original series, one counting up, one counting down, and the sums of the columns (all the same). If you add all those sums together, you'll get (n + 1) times n. That's the sum of 2 of the original series. Since the two series you wrote down are the same, they must each contribute half towards that big sum. So the sum of the original series must be (n + 1) times n divided by 2. Or if you don't like words in your equations, it's (n + 1)(n / 2).

I've typed this in once before today, so I'm going to give up early this time. Doug's Java code used for loops to sum test each number under 1000 and add it to a total if it qualified as a multiple of 3 or 5. The one liner (split over 3 lines!) is:

public static int pe35sum(int n)
{
return (((n - 1) / 3) * (((n - 1) / 3) + 1) * 3
+ ((n - 1) / 5) * (((n - 1) / 5) + 1) * 5
- ((n - 1) / 15) * (((n - 1) / 15) + 1) * 15)
/ 2;
}

The divide by 2 has been moved to the end. In some places, integer truncation helps this method work. In the case of the / 2, the 0.5 is necessary, as often as it isn't.

I hope this helps!

Java GDS2062 1.0.9 etc

Went shopping at Giant near Senawang today. We took the 'scenic route', but got a little lost. I wasn't bothered, I hadn't been there before, but shopping malls are not exactly nirvana for me. The scenery on the way was marvellous, we can get lost again and it'll be a pleasure. Almost every other place I've been in Malaysia is palm oil plantation all the way, but there were plenty of rubber plantations and some sugar cane, banana and bamboo today. Some of the villages along the way looked lovely.

Anyway, got a couple of updates on the Java scope utility today. It now has some support for setting the trigger, and displays the current trigger status (not really status, still can't get RUN/STOP) very much like the scope itself does. I use extended JLabels for the utility. The earlier ones are all setup by a monolithic refresh procedure that gets all the data from the scope. The trigger has its own refresh method, which makes the code a little bit easier to browse through.

Went fishing for the next burst in the C2 erase sequence, and got it after two tries. Well, I got something after two tries. As I get further into the sequence, the jitter on the bursts may eventually be sufficient that I'll skip a burst and get the next one. I'm still hoping that my answer lies in the early part of the sequence. Today's burst is WAffRDc0. Again, I'm utterly clueless. So the IDE reads 0xc0 from register 0xff - so what?

Ricky from ec2drv emailed more helpful info for getting the USB debug adapter going. I'll work on that tomorrow.

Using Linux with Silicon Labs kit

How long before I do some proper work? A while ago, I tried the ec2drv project's code from sourceforge. I think I made a half-arsed attempt back then, and quickly gave up. Desperate to have Linux back on my laptop today, I tried it again. Whatever has changed in the interim, it comes very close to working. It works for lots of other people, but I have a very recent microcontroller from Silabs (the C8051F530), and the project has yet to add support for my micro. It does recognise it correctly, however, but fails to write it. I've got some code like that! They (ec2drv) also provide an early version of their ddd (GNU debugger) support. That looks quite good, but useless to me until some Linux utility will actually write to this micro. I left a note on the project forum, they were very quick to reply and very helpful last time. I was adamant last time I wasn't going to continue to use the Silicon Labs programming adapter, but I'm stuck with it unless I pay for a better oscilloscope.

I'm not at all sure how they're going to add support for the micro I use. I downloaded SnoopyPro from sourceforge to have a look at the USB traffic between the IDE and the debug adapter. Wow. There's a lot! And little of it made any sense to me. I gave up almost as soon as I started. If someone from ec2drv can give me a few pointers, I'll have another look, but I'm not looking forward to it!

Back to the oscilloscope

The question I had to ask myself is "Do I feel lucky?". But being as I own a GW Instek GDS-2062 oscilloscope, the least debugged oscilloscope in the world and would probably blow... enough of that. I had 30 minutes at the end of the day before I had to deliver on the parental front, so I tried 'fishing' for that elusive third burst of traffic between the Silicon Labs IDE and the C8051F530TB (Test Board, I think). Got it in 4 tries! I wonder how many times I can erase this microcontroller before it's a brick? I think the datasheet said it was in the tens of thousands, so I probably shouldn't worry. There are quite a few commands in this burst.

WAb4 is selecting FPDAT, the Flash Programming Data register. WD01 writes 01 to FPDAT - what's that? I can't find anything in AN127 about it - just about SiLabs' only reference to Flash Programming via C2. AN127 lists 4 command codes that can be writted to FPDAT, but 0x01 isn't one of them. RA00 - a read of the address register gets a status code. Bit 1 is 'InBusy', referring to a write to FPDAT. Bit 0 is 'OutReady'. Since the IDE just wrote 01 to FPDAT, this is telling us the write is finished. RD01 - perhaps this is the result of the WD01? WAb4 selects FPDAT again. RD0d... AN127 uses a read from FPDAT, compared to 0x0d, to check 'FPI Command Status', so I guess this is what this is. RA01 is fetching the status code again, and this time OutReady is set.

The middle line: WAb4 selects FPDAT. RD1b reads 0x1b from FPDAT. Then a read of 4 bytes follows: b4, 87, 00, 5c. RD01 is a last byte of 0x01. The last line: WAb4 selects FPDAT again. RD6d reads 0x6d from FPDAT. RD01 a read of 0x01. WAb4 selects FPDAT again, and reads 0x97. The C2 reader I wrote finishes cleanly at this point, so that means either that the set of samples were good, or they were bad in such a way that they meant something to the C2 reader. But that is unlikely.

Not exactly interesting reading. Perhaps all this will become obvious later. If you're reading this and thinking "Duh! I know what that is!", let me know, please?

Told you the ec2drv guy was good

Replied already, fixed some things, and given me some suggestions of what to try next. Got to go - got work to do!

Agilent. Oscilloscope pr0n

I wish I could afford one of these. I used something like it on a project at a UK university a couple of years ago. Did exactly what you expected of it. Even did some things you wouldn't have expected, but just found yourself wishing an oscilloscope would do. When you looked in the manual, somebody had already thought of it and built it in. Perfectly. I'm having second thoughts about self employment, and third. They're hiring in Penang, loads of people, by the looks of it. I'd post a link, but the Jobs link on their homepage is as easy for you to find as it was for me. I'd better get back to work instead of dreaming about how easy life would be with an Agilent scope.

If only...

Instek! I want my money back!

Futile, of course. I bought this GDS-2062 some time ago, but wasn't ready to really use it in anger until recently. And I have been angry. The Java-based scope utility is working well, but I've reached the end of the road with this oscilloscope, I think. The utility tells me that when the Silicon Labs IDE does an 'Erase code space', the C2 commands are WA02WD02WD04WD01 (after reset) - a write to the FPCTL (Flash Programming Control register). The next command follows around 20ms later, and is WA00RD11WA01RD01. That's reading the device ID and revision from the target. I may have got lucky in capturing the second burst, I didn't have any trouble until I started trying to capture the third burst. What I did was to use the scope to look at the first 200ms of traffic from the IDE. There's a lot missing, but you can tell there are bursts of commands going on for some time.

I assumed the bursts would be reliably spaced, so I used the scope to look through the traffic 5ms at a time, by repeatedly advancing the time delay and erasing the device again. The third burst contains a lot more commands than either of the first two. Its start is not reliable though. To read the C2 commands, the scope has to be set to 10us (microseconds) per division, giving 200us worth of samples in the window The third burst was not in the sample window the first time I looked for it, so I set the scope for 250us per division to try to see what had happened to it. On two successive erase operations, the third burst occurred at before 25ms and after 26ms into the erase operation. Given that I need to capture that burst in a 200us window, hope is starting to recede...

The GDS-2062 has a delayed trigger facility, where you can use the external trigger to delay the normal trigger by a fixed time, or number of events. Fantastic! Either facility would do! I could just delay the trigger by 24ms after the reset, and then the next rising edge on C2K would be the start of that burst. Delaying by time would obviously be of less and less use the further I got into the traffic, but I suspect (and hope!) all I want to know is at the start of the traffic. So, run a wire between the C2K line and the EXT TRIG connector (I don't have 3 scope leads)... select the delayed trigger. By time... it only goes up to 1.3ms! Useless! Hey, well, given the moving timing problem, the event-based delay might be better anyway. Just have to count the C2K strobes. Don't hold your breath. The delayed trigger doesn't seem to honour the 'Single shot' setting from the normal trigger. Yes, it triggers after the selected number of events, perfectly. Then it fires again, after that many more events occur. And again, and again... I think you get the picture. It doesn't work.

I'm going to drink some coffee now. I feel better after getting that off my chest. I might go back to my micro-based C2 program and see if those codes written to FPCTL really are the key. Alternatively, I might go back to my micro-based C2 snooping program and see if there's anything I can do to speed it up. I'm not really hopeful in that regard. The strobes arrive at 500ns intervals and last less than 100 nanoseconds. The micro has a 25MHz clock, and can execute some instructions in 1 clock cycle. The instruction to loop around checking a port bit executes in 3 or 5 cycles, so can't capture strobes reliably (3 cycles is 120ns). Using an interrupt is out - the ISR calling mechanism itself would use all the clock cycles available between clock strobes!

The only other alternative is to make some hardware to do the C2 snooping. Or buy a better oscilloscope. I think by now I've easily lost in time what those good, but so much more expensive scopes would have cost me. Coffee calls.

Scope utility on google code

That ought to have been easier than it was. It's not that it's difficult, there are hints everywhere. Given the hints, the first things I thought of happened to be wrong almost every time. Oh well, the scope utility is available for download from Google code hosting. The source is also available at http://code.google.com/p/gds2062/.

Past my bedtime again. Perhaps just a few morsels:

C2 snooping

Was having trouble correctly reading the C2 traffic between the IDE and the microcontroller. Extracting the sample points using the java utility and plotting with GNUPlot, it's obvious that the C2K (clock) strobe leads the C2D (data). Looking at the C2 Interface specification from Silicon Labs, I see that... that's what the manual said all along. A small change to the C2-reading code, and the utility seems to get the snoop right on all the datasets (not many) I've tried so far. I did try straining my brain first - I was expecting C2D to be setup before the strobe leading edge, perhaps triggered by the strobe's falling edge. But it isn't. Should have RTFS.

Problem with GW Instek GDS-2062 command language

I sent an email off to Instek in the U.S. (I think) today. There's one guy who works for them, that answered once. That's when I was told there would be a firmware update in February. I'm still waiting for it. I think it's going to be a good one. Instek have a lot of websites, with a lot of email addresses and contact forms. I must have sent half a dozen messages or so when I first got this scope to ask for help. Not a dicky bird. Except for the aforementioned bloke. So I've sent him a couple more. This latest one is about the USB/serial port command language for the setting the time/div. You use :TIMEBASE:SCALE and provide a floating point number like 2.5e-3 to get 2.5ms per division on the oscilloscope screen. Only it doesn't always select the right settings - probably a typo in the firmware code, I suspect. Here's the list copied verbatim from my email:

Command (Result)
:TIMEBASE:SCALE 1e-3 (1ms) correct
:TIMEBASE:SCALE 2.5e-3 (1ms) wrong!
:TIMEBASE:SCALE 5e-3 (2.5ms) wrong!
:TIMEBASE:SCALE 10e-3 (5ms) wrong!
:TIMEBASE:SCALE 25e-3 (25ms) correct
:TIMEBASE:SCALE 50e-3 (50ms) correct
:TIMEBASE:SCALE 100e-3 (50ms) wrong!
:TIMEBASE:SCALE 250e-3 (250ms) correct

If you're doing something with a GDS-2062 via the USB/serial port, you might run up against this feature!

That's it. Bed calls.

Something is working

I wouldn't be impressed if somebody fixed my car this way, but lo and behold, a little progress at last. I got completely lost up my own problem looking at the output from usbmon. I gave up on javax.usb in the end - it wasn't the right tool for my job. Some of the driver examples look impressive, so beyond the difficulty in installing it, I'm looking forward to using javax.usb again in the future. I don't need a driver though, I just want to check that the drivers I have are working correctly. By the time I'd written a java utility to parse the contents of /proc/bus/usb/devices (what devices are connected to my Linux system) and /sys/kernel/debug/usbmon/*t, I'd more or less got the hang of reading the text contents by eye. Well enough to see that my GW Instek GDS-2062 wasn't making complete replies to commands to its serial port.

I didn't know what to do after that, so I looked again at the driver issue. When I connect the oscilloscope to the Linux system, it's 'recognised' as a USB modem. Perhaps this is a fault of the oscilloscope's vendor and product ids being set incorrectly? So I used rmmod to remove the cdc_acm module and modprobe to load the usbserial module, specifying the scope's vendor and product ids on the command line. I did it slightly differently this time, specifying that the ids were in hexadecimal format:

modprobe usbserial vendor=0x0558 product=0x2009

Coupled with a change to the way I'm reading the (USB) serial port from my Java scope utility, it all seems to mostly work. At least well enough for me to get back to my original problem, which was the C2 communications between Silicon Laboratories' IDE and their prototype boards. I'm trying to get the C2 programming facility hosted by one of their microcontrollers (so one micro can program another). The change I made to the Java code was a reversion to some older code that waited around too long (in my opinion) for the remote system to finish sending data. Either the change of USB driver, or the extra delays in the Java program have made the previous problem (truncated replies and scope lock-ups) go away. I'm making hay while the sun shines. If the problem rears its head again, I'll try to take better notes as I go along, so I can deduce what the solution really is.

I've got some dread lurgy on my scalp and in my ears at the moment. Yes, I do wash. It's making it difficult to concentrate, so I'm giving up for today after posting my first successes with the Java utility. Can I attach an archive to a post? It doesn't look like it, perhaps I'll post it elsewhere on the web. If you're really desperate, reply this blog, and I'll send it to you.

Java scope utility

On my desk I have a Linux desktop that I do most of my work on. Next to it I have a notebook running Windows. I don't want to use Windows, but at the moment I don't have an alternative for flashing the Silicon Laboratories microcontroller prototype boards I have. There is the ec2drv project at sourceforge, but I don't want to use the Silicon Labs debug adapter for my project. Not because there's something wrong with it, I think the adapter and the prototype boards are good products at good prices, but it's just not appropriate for my design. So I'm stuck with Silicon Labs' IDE for now. All my programming and compiling is done on linux, using SDCC.

After following the C2 application note from Silicon Labs, my boards gave no sign that flashing was going to work. Looking at the oscilloscope traces, the code on the board sending the C2 commands seemed to be right. Checking against the Silabs IDE, well, that's not so easy. A lot of traffic goes between the IDE and the target board, for even simple jobs such as resetting the system. My oscilloscope, full of natty features, a great price, doesn't work very well. A pity, it looks like it could, with a bit of firmware programming effort. So I wrote a Java utility to help me out. It's quite useful already - I don't have to get up! The scope is almost a metre away from where I sit, so I could lean over and with a bit of reaching, hit the Run/Stop button. But it's right next to the 'Auto Set' button, which should do something useful, but it appears to me to just completely randomise all settings. The scope works well enough to tell me that the 'reset' button in the IDE does quite a bit more than just pull the C2K line low.

The trace is imported from the scope, and is a fairly good likeness, except that you can see more of the sample buffer. The big red box in the middle is a select box I've drawn with the pointer. Right-click on it, and I've added a 'Read C2' option that converts the two waveforms to C2 commands. The program's output for this waveform is:

RESET
C2Reader: WA02WD02WD04

The reset is obvious, but the IDE software then writes address 0x02 (the flash programming control), then writes data 0x02, 0x04. I'm basing what follows on an assumption: that these codes are the ones referred to in AN127 "Flash programming via the C2 interface" as the key codes that enable C2 flash programming. They're different codes from those in AN127. But why do I have to do all this to find that out? I'll search silabs.com again to see if there's a misleadingly named application note wich tells me what I really, really want to know. I'm resisting the urge to shout. Good, aren't I?

It takes a bit of fiddling about to get the right time scale and offset for the scope to deliver useful samples for reading C2 commands. They're delivered very fast from the debug adapter. Too fast for a snoop program to run on the microcontroller (tried that). Using the Java utility though, I can set the time scale / offset, sample memory length and run/stop mode from my chair. How useful is that! I'd better go and do some exercise to make up for it.

javax.usb

One day I'll work out whether a lot of my problems aren't coming from having something non-standard about my desktop PC that means a lot of downloaded software doesn't do quite what it says on the label. Once I got everything installed from this package, I couldn't get past a very annoying bug:

javax.usb.UsbException: Properties file javax.usb.properties not found

The javax.usb.properties file was in my java install directory, located under jre/lib/ext. The very terse instructions that are available for javax.usb tell you the properties file must be in the CLASSPATH. As I got more desperate, I coped javax.usb.properties to every java-related directory I could think of. There must have been 20 copies of the file by the time I gave up. Still the same problem. The problem manifests itself when the UsbHostManager class does its initial setup, in the setupProperties method:

InputStream i = ClassLoader.getSystemResourceAsStream(JAVAX_USB_PROPERTIES_FILE);

The javax.usb classes are all loaded from a jar file located in jre/lib/ext, and putting the javax.usb.properties file in the same jar file solved the problem for me. You can do it with "jar -uvf jsr80.jar -C /path/to/properties/file javax.usb.properties". The -C takes care of the path to the properties file. Without the -C option, javax.usb.properties is added to the jar file but includes the path information on your system.

Back to work. Well, back to trying to work out why my tools don't work!

USB monitoring on Linux

I am dying. The Java utility for viewing waveforms from my GW Instek GDS-2062 oscilloscope is coming along nicely. One of the nice things I can do now is to change the settings on the scope by clicking on the utility on my PC monitor. There's a proprietary flash-writing program on my laptop, connected via USB serial to some Silicon Labs' prototyping boards. I want to write my own re-flashing code, to run on the microcontroller, rather than on a PC. It's not working. The available examples don't work. Code written to the instructions in the manual doesn't work. I have a proprietary program that does work though, so I want to see how it does it.

The oscilloscope's firmware could be better. The manufacturer has alluded to an update, but a release eludes them. I could piece together pictures captured with their freewave utility, but that stopped working a couple of weeks ago. That method is painful because the scope's support for zooming and panning along the sample memory is broken. Instek does provide a programming guide for the oscilloscope's serial port command language. I used that to write the Java utility, coupled with the RXTX serial communications software for Java. It works sometimes, and sometimes it doesn't. Sometimes when it doesn't it appears that the scope makes a truncated reply. At least, that's what appears to happen from the desktop end. But does it really? Sometimes the oscilloscope locks up when this bug appears, and needs to be switched off and back on again. Sometimes it doesn't and appears to work normally.

I want to know exactly where the communication goes wrong. Since the PC and oscilloscope are connected by a USB lead, the best thing to do is to look at the USB traffic. I found a site that explains it: http://www.mail-archive.com/synce-devel@lists.sourceforge.net/msg00254.html
There's a recommendation to look at the documentation distributed with the Linux kernel for the usb monitoring code. You have to build a debug kernel to do what follows, so none of this will work on 'normal' kernels. That's got to be a good thing from the security point of view. If you're debugging hardware and drivers, rebuilding a kernel and rebooting probably isn't going to hurt you. That much. The output of the usbmon code is available as a plain text file. Nice! But it isn't exactly 'readable'. For that a couple of utilities are mentioned in the kernel documentation, usbdump and USBmon. usbdump doesn't seem to exist. I can see mail on mailing lists where people seem to be suggesting they're about to write it, but I can't find the actual software anywhere. USBmon was easier to find. Wouldn't compile. It looked like it might have compiled once, but the names of classes and files were ... odd.

I've been here before! Nothing works! Well, I'll try writing my own code to make the USB traffic a little more readable, and see if I can't pin down my serial comms woes a little better. Rather than try parsing the /proc/bus/usb/devices file myself, I downloaded the javax.usb software from http://javax-usb.org The install wasn't entirely straightforward, I still ended up editing a Makefile.

That might be my lot for today. It's looking quite cool outside this evening, must be under 30C. Time for me and the daughter to take a stroll. We're on the flight path for KLIA, and there's a lot of traffic in the late evening. She loves to point at the planes (so low you can see the windows sometimes!) and run after them, pointing and shouting "Ohhhhhhhh". She's 16 months old. I'd like to do the same thing, I'm 16 too (in base 34). More later.

Kubuntu 0 Windows 1 (Skype stops play)

After the DNS problem was laid to rest, kubuntu really did work like it promised to. Installing new programs was a breeze! The package maintainers have done a great job of ensuring newly added programs are integrated into the rest of the desktop. Some stuff that I miss from time to time in Slackware, such as a file window popping up when I plug in my USB drive, and being able to browse the shared folders on other machines on the network straight out of the box, was very exciting. I showed my wife. She said "where's skype?". I hadn't yet installed it. I looked at our so-cheap-you-couldn't-turn-it-down webcam and had a bad feeling. It's unbranded. One person had enquired in a web forum, just once, about it and got a very snotty answer from the package maintainer. Without naming names, I suspect the maintainer was not the originator of the software. It was a reasonable request from the webcam owner, and I reckon if he'd asked the bloke who writes the software for webcams like his, he'd have got a very different answer.

Anyway. No Linux support for that webcam. "Write some!" I hear you all advise. Well, I started. And then I stopped. The code looked straightforward enough to modify. After I'd made a couple of changes, I could see that Linux was 'recognising' the webcam, and it looked a small matter of ... oh wait. I'd have to plug the webcam into a PC running Windows and snoop the USB messages. And if that worked, then I could use some open source software to video chat with anybody who... uses... open... source... video... chat... software. Starting to get the picture? Skype for Linux doesn't do video! And there's little promise of it from their website. My wife was very generous. She discussed it with me quite rationally for ooh, minutes. It must have been clear to her how clear it was to me exactly how long she was going to tolerate the excursion into Linux. Ah. There we are: "To begin, click your username". The end of the adventure. Now where are all those shiny CDs of proprietary drivers?

DNS woes

This is nothing to do with kubuntu. I was having the problem with Adept package manager waiting for lists again. Patience ran out, so I thought I'd enter the IP addresses for security.ubuntu.com and my.archive.ubuntu.com directly into /etc/hosts. Thinking slackware didn't have the problem, I pinged those servers from a PC running slackware. I got 1.0.0.0 back as an address. Hmmm. Using telnet to connect direct to the router, a ping from there gives me the correct address. So what's going on? Editing the IP addresses of the servers direct into /etc/hosts means DNS won't be used at all. It's not a fix, just another workaround.

Can we rule out IPv6 now? It's not compiled into the Slackware kernel I'm using, and not loaded as a module. It seems intermittent too. I haven't changed anything on my Slackware PC, and now a ping to those servers works. I give up. The workarounds will work. One day, if I'm really, really bored, I might look at this problem again.

Kubuntu cheering up nicely

I would have greatly preferred kubuntu to just work straight out of the box. It didn't. At the moment, it's sitting there, looking pretty and installing new software (ekiga), courtesy of the 'Adept' package manager. To be fair to kubuntu, a very great number of people complaining online about the DNS resolution to 1.0.0.0 issue appear to have the same ADSL router as me. A D-link DSL-G604T. After reading all the comments, I'm still not convinced who to blame. Some blame it on incorrectly used IPv6 on the PC, or incorrectly handled IPv6 at the router. My Slackware machines work a treat with my router, but I habitually download the latest kernel from www.kernel.org and build it myself without IPv6. A great number of the workarounds for this problem require edits to the kubuntu system files. I don't think that's right: If it was really kubuntu's fault, I'm sure the maintainers would do that to the distribution. The workaround I'm using now is to turn off DNS relay on the router, and to manually set my ISP's DNS nameservers. That's not right either. I'm relying now on my ISP not changing the IP address of their DNS equipment.

Everything seems to be working just fine for now. It's a lingering disappointment though. I think perhaps I had this problem once with my Slackware installations here, but Windows never presented this problem. I suspect a great many Slackware users build their own kernels, it feels like 'the right thing to do' with Slackware. My expectation for kubuntu is that somebody has already taken care of selecting the best mix of software, and that I don't have to maintain it. Since kubuntu is on my wife's PC, any suggestion that I'm 'fixing' it will swiftly lead to its replacement with Windows. More later, I expect.

Later Edit: That change to the router didn't help. It must have just coincided with something else I was doing on the PC. The adept package manager is still 'waiting for headers 0%', unless I open a console and ping the security.ubuntu.com and my.archive.ubuntu.com servers. Or maybe that's a coincidence too. Aaarg!

Kubuntu woes

I downloaded the firmware for my router. Unpacked it. It's the same as the firmware already installed. Bugger - why can't they (d-link) provide the version of the firmware on the download page? Aaaarg! Well, that won't be a solution. But then, I don't really know what the problem is. This forum suggests it's an IPv6 issue. After following the destructions to turn the IPv6 module off, rebooting a couple of times (there was an extra alias...) it appeared IPv6 was no longer loaded. But it had no positive effect on the problem! In desperation, I followed the workaround: added my ISP's nameservers to /etc/resolv.conf, which worked. It's sitting there now, doing a apt-get dist-upgrade. It says it'll be 6 hours. That's no bad thing, I should be getting some work done.

Kubuntu

We have a PC here that's been recently rejuvenated with a new motherboard, power supply, 1GB memory, a Pentium D, and most recently a SATA hard disk. The case is looking decidedly scruffy, but still perfectly functional. The on-off switch recently fell out, it had been sticking a bit, but it has since succumbed to fatigue and gone the way of most old plastic. Poking your finger into the hole in the front of the case doesn't feel very high tech, but it works, and there's no danger. Anyway. I'm not convinced it ever had a pukka copy of Windows on it. My wife bought it donkey's years ago. It had Windows 98 on it when I first saw it. Recently it's been running a copy of XP Professional that a shop gave me. Yes! Gave me. In Malaysia, computer shops "don't sell software". That's what the shop told me. I suspect if I hadn't just bought a lot of hardware too, they might have charged me a few ringgit.

The PC has been slow / failing to shut down recently. I suspect one of the hard disks is failing, but not sure how that causes the symptom. The new SATA disk was bought for a fresh installation of ... something. I'm fed up with pirated Windows software - keeping it up to date seems like a good idea, and the Windows Genuine Advantage program worked for us: we decided if we wanted to use Windows, we'd buy it. So we looked at the price, and decided we didn't want it that much. I use slackware on my desktop and laptop, but impress no-one with my choice of xdm (What? I just want to type in my username and password - what do I need pictures and animated menus for?), and icewm with a black desktop. It works, and it's fast. OK, so sometimes I spend a lot of time editing text files to get things working. For me, it's not an issue - most of my jobs have been like that! My wife wants something that JustWorks(TM), so I had a look for a Linux that JustWorks(TM).

Searching the net brought me to Kubuntu so I downloaded the install CD ISO, and started this morning. It's mid afternoon now and I'm not happy. This morning, I was dancing for joy. So pretty! And quick. The install CD boots to a fully working Kubuntu system without actually installing. Install is a shiny big icon on the lovely desktop that gave me a peaceful feeling. The installation is swift too, and there was very little for me to do, beyond selecting a time zone. There was a "scanning the mirror" message at one point that really didn't seem to be doing much. That prompted a web search, and lots of other people had been annoyed by it too. I waited it out, and it finally went away and appeared to complete successfully. Oh, one annoyance was a badly laid out partition editing dialog. Some of the controls were obscured by other controls. I should have taken a picture, obviously.

It doesn't work!

Then the pain started. I just wanted to install firefox. I like it. My wife likes it. Could I? No. The software updating / management feature of kubuntu (one of the reasons I chose it) didn't work. It was nice, said I had some sort of firefox installed at first, but not a complete installation, and I certaily couldn't find any way of starting anything that looked like firefox. I could delete the bits that were there though, that felt like progress, in a funny sort of a way. Kubuntu seems to do a lot for the user. When I stop wanting to do what I want to do and start wanting to do what Kubuntu thinks is the RightThingToDo(TM), then I'll have a much better time I think. I'm blaming Kubuntu now, but as time wore on, I realised I might not be being fair.

I opened a konsole. It looked just like an xterm to me, which struck me as a very good thing. I tried apt-get. It fails, in a similar way to the Adept (!) application that does the same thing, but it told me why. It couldn't fetch whatever these things fetch from one of the places these things fetch whatever they fetch, and it implied the place it was trying to fetch ... from had an IP address of 1.0.0.0. Brilliant! That doesn't look like Kubuntu's problem at all! A quick google, and I could see people were trying acts of desperation like using their ISP's DNS instead of their router's DNS. Madness! DNS works perfectly well on the router - everything else (surfing, pinging) works a treat.

I don't know what the real problem is. I've seen forums where the suggestion is that it's a bad interaction between IPv6 on their PC and the software on their router. I'm off to update the firmware on my router, and if that works, I'll let you know. If it doesn't, well, I'll have to thinmk of something, won't I?

Getting there...

A relatively early night tonight - only 1am as I write this. Still plenty of wrinkles to work out, and only limited data from the scope presented at the moment, but the closing and reopening of the streams from the scope seems to have made a huge difference. Still can't reliably connect to the scope on Windows, but on Linux, I get a 90% success rate at the moment! The scope still locks up, requiring a power cycle, but it's rare enough now to almost (!) forget it. So first views of the Java-presented data from the Instek GDS-2062 (just one click to connect, one click to update).

These are the small (500 points) sample sets. There's about twice as much data visible, compared to the screen on the scope. There appears to be a 'glitch' visible as a spike at the left side of the blue trace. It's repeated in the yellow trace, but more visible when the time/div is decreased. This may be an error in the scope. I'll look into that.

At the moment, the only data displayed are the sample points, the marker (a '1' and a '2') for the offset voltage, and the Volts/div for the two channels. It's easy to add the rest of the data, expect an update soon.

And here is the actual oscilloscope. See? Only half the samples visible.

Instek oscilloscope, RXTX, USB serial woes

Lost a day to trying to debug the serial receive logic in the Linux kernel. Hadn't tried that before, but have to say that inserting

printk(KERN_DEBUG "Handy debug message here\n");

throughout the serial and tty code was an easier than expected experience. I'd read people saying that before, but didn't really believe them. You really can just edit the kernel source, insert your debugging code (caveat haxor!) rebuild, reboot, and see what goes on in a live kernel by looking in /var/log/debug. After doing a lot of debug message inserting, rebooting my PC and that pesky oscilloscope many, many times and reading a lot of debug messages, I reckon I don't know what the problem is. I'm fairly certain that the problem is not with the PC, but with the oscilloscope.

Freewave and Portmon

Freewave, the software that can be used with the scope, mysteriously started working again. The meaningless dialog box (that meant the software tried to do something that it shouldn't) has gone away, so I tried fetching a large sample set from the scope again. This time, I downloaded Portmon from Microsoft. I wish I'd done this at the start. Oh yeah, I remember, this all started when Freewave mysteriously stopped. Anyway, Portmon tells me that the Freewave software doesn't just send a series of commands to the scope, it seems to reset the serial port after each command, and follow it up with two 'purge's. To be sure to be sure, obviously. In fact, there are three purges after each command. I'm not sure what effect these will have on the scope - after all, only rx, tx and gnd are connected at the port. The RXTX package stays fairly faithful to the Java Stream definitions, so I'll try some close()-open()s and a flush or two. If it all goes a bit stable, I'll post the code and a picture or two,

ttyACM0

Something that caught me out badly a few times was ttyACM0, the device file for the scope's USB connection, being created with 660 permissions, owned by root.root. I edited my udev.rules file, found under /etc/udev, to fix this issue. I'd be more explicit about it, but I'm not convinced I did it perfectly! I must read up about udev one day.

Better get this code tidied up, post a final message, and get back to some proper work!

RXTX serial port pain

The failure of the USB serial ports to work is puzzling. I've used them lots of times before with other serial devices, and they've been fine. What's the issue? There's nothing wrong with the lead. The last remaining non-USB serial port in my house is on my desktop. A null modem lead from the USB serial port connected to this port, and a minicom on either port proves that messages are delivered correctly.

Uh? It works. OK, I'll try that again. I could cry. I have a minirc.usb0 in /etc, so I can start 'minicom usb0' for another serial device (my phone, I think). Starting minicom this way, and changing the bps to 38400 from 9600, I can communicate with the scope. Starting minicom with no rc file (it uses the default minirc.dfl), the port settings are /dev/modem 38400,N,8,1 with no flow control. The only thing I appear to need to change is the port. Changing the port to /dev/ttyUSB0, so that all settings appear to match, I can't communicate with the scope. With the null modem lead between the two ports, I see the data is garbled.

Again, more carefully... Null modem between USB serial and built in serial. Minicom on one terminal, minicom usb0 on the other. Change the bps to match, and it works. Minicom (/dev/modem) on one terminal, change the port to ttyUSB0, minicom won't start in another xterm: /dev/modem is locked. Not another bug! I'll try updating to latest (2.2) minicom, mine is 2.1. The minicom project is at http://alioth.debian.org/projects/minicom/

Hmmm...same problem. Looking at the code (my eye sockets are starting to bleed), it doesn't seem to re-initialise the port after the user selects a new serial device. The lock remains on the port minicom originally started with. The code does look awfully neat and tidy though, so I'm not keen to edit it. Saving the new settings, exiting minicom and invoking it as 'minicom usb0' (for example) seems to work a treat. Something to remember, while I forget the rest.

Scope software

Back to that software. With a null modem lead between the GDS-2062 and the USB serial port, and trying to acquire a 12,500 point waveform, it seems the read of the InputStream stops at 4,095 bytes. Interesting number! There should be 25,014 bytes in this message. There's no further reply from the scope. Trying to toggle between USB and RS232 on the scope settings results in the scope locking up, necessitating a power cycle. I don't understand why the scope is bothered - there's no flow control on the port (only rx, tx and gnd are connected, according to the user guide).

I use a java.io.BufferedInputStream to get bytes from the serial port. A quick glance at the web tells me the default buffer size in BufferedInputStream is 2048 bytes. I use BufferedInputStream to wrap the InputStream obtained from RXTX's SerialPort object. The InputStream Object is a RXTXPort$SerialInputStream, which has no buffer, but wraps the native functionality. My code loops around after issuing a command to the scope, sleeping and polling the InputStream's available() method until the whole message has been returned. The RXTXPort's available method is a wrapper for a nativeavailable function, which in turn calls ioctl(fd, FIORDCHK, 0). Ooh, that's deep.

Checking again, I notice that using minicom to retrieve the long sample memory also fails. It's not minicom's fault. Trying 'cat /dev/ttyS0' on one terminal, and 'echo "acq1:mem?" > /dev/ttyS0' on another, also fails. It seems like a few thousand characters in minicom. I tried 'cat /dev/ttyS0 | hexdump -C' and this tells me I get over 11,000 characters. That's more than the java code reports, but still short of the expected 25,000. Interestingly, I get 4,096 characters again if I use 'hexdump -C < /dev/ttyS0'. Is it just down to the serial port's buffer not being emptied fast enough? How big is the serial port's buffer?

RXTX Bug

A very, very small bug. I've never actually felt fired up enough to fix some open source code. Not good enough really, I use open source stuff by preference. I've sent money to some projects I've felt particularly grateful to, but not enough money and not enough projects to stop me feeling slightly guilty! What's the problem? I want RXTX to recognise my USB serial (or is it a modem?) device on ttyACM0. The advice in the documentation is to put an entry in gnu.io.rxtx.properties to tell RXTX which unusual ports you want. I did that, and got nowhere. I recompiled the code (Hooray for Open Source!) with the debug flag on, and got this:

The file: gnu.io.rxtx.properties doesn't exists.
java.io.FileNotFoundException: /usr/local/java/jre/lib/ext:/usr/java/packages/lib/ext/gnu.io.rxtx.properties (No such file or directory)

I'm so happy I could jump for joy - an easy bug! Looks like the code is appending the filename to a colon-separated list of paths, instead of to each path in the list in turn. Ooh, now that I look at it... maybe too many people have edited this code... it's a bit confused. The gnu.io.rxtx.properties file contains some handy properties, but the code replaces the entire System properties with the one or two in the file. That can't be right. There's even a comment at the head of the ChangeLog for 2.1-7pre22 that says not to overwrite System properties.

I just want to get the piece of code I'm interested in working. Doing anything else strikes me as rude, so I'll press on. The fix is to just extract the necessary data from the properties files - note that there could be more than one, thanks to the previous change.

It's getting worse!

OK, so I made the initial change to make sure those properties were being read properly. Now there's a function in the native library 'testRead' that says ttyACM0 fails. In some way. So I want to add some debug comments to that C code. But RXTX 2.1-7r2 doesn't build properly! When you extract the tarball, it won't make:

make: *** No rule to make target `i686-pc-linux-gnu/librxtxSerial.la', needed by `all'. Stop.

I don't know why!
But it's okay, I was just doing the usual ./configure, make, make install process. The problem goes away if, with a freshly extracted source, you:

aclocal
./autogen.sh
./configure
make
make install

make install fails at this point with the error:

libtool: install: `i686-pc-linux-gnu/librxtxRS485.la' is not a directory

Again, who knows why. I do know that the error is caused by the absence of a value being assigned to RXTX_PATH in Makefile. Editing Makefile, and editing the line so it assigns RXTX_PATH to the path to where the JRE's ext libraries are kept will allow make install to finish. For me, it's:

RXTX_PATH = /usr/local/java/jre/lib/i386/

Phew! I can finally compile and install all my changes. There's another problem in the Makefile that causes (on my system) the newly created RXTXComm.jar file to end up in the '/' directory. Locate and change the JHOME assignment to something useful for your system. For me it's:

JHOME = /usr/local/java/jre/lib/ext/

Such a slow process. Now it's my bedtime. testRead is rejecting /dev/ttyACM0 at the same place it rejects all the other non-connected devices:

do {
fd=OPEN ( name, O_RDWR | O_NOCTTY | O_NONBLOCK );
} while ( fd < errno="=" ret =" JNI_FALSE;">

The same code accepts /dev/ttyUSB0 - the only serial port connected to my laptop. But I can't establish a connection to the scope over the USB serial lead. My head hurts. One last try, USB serial from Windows. Nada. Serial works fine from the desktop, so it's a USB serial issue. Too tired to think.
Night!

That oscilloscope software

Will now plot the two waveforms from the scope in a window. It'll discover the scope by searching ports. But it's having trouble acquiring a 'long' memory from the scope. There are 2 options on this scope, a short (500 samples) memory and a long (12,500 or 25000) memory. The communication between the PC and the scope is by short message and (potentially long) reply. There's an RS232 port and a USB host socket on the scope. The reply that contains the sample memory is one long string, with the sample data presented as pairs of bytes. For the short memory, the message is just over 1,000 bytes long. The long message is around 25,000 or 50,000 bytes long! At least, it should be. My program only gets the first part of the message.

I tested the scope's reply against HyperTerminal on win and minicom from Linux, and there does seem to be an issue with a truncated reply. I'm not convinced it's the fault of the scope, but most of the times it happens, the scope locks up, requiring a power cycle to make it usable again. I must check again, but either the null modem cable between serial ports, or the USB A-B cable and HyperTerminal does allow a full 12,500 sample reply to be acquired. The USB connection is a bit odd. The VendorId is 0558, allocated to Truevision Inc in the Linux USB ID list. The Instek setup.inf has the same vendor id and a product id of 2009, and simply registers the scope as a USB serial device. In desperation, I had a look inside the scope. It seems surprisingly well built! The USB host socket connects to a Philips ISP1362 USB On-The-Go controller, so I'm guessing whatever OS is running on the nearby BlackFin processor is repsonsible for those Vendor and Product IDs.

I was having no luck with the long sample memory reply on my Linux desktop at all. Truncated every time, at around 1,000 characters - 24,000 short! I was using

modprobe usbserial vendor=VVVV product=PPPP

to get the scope to be recognised as /dev/ttyUSB0. I tried on my laptop - it has a slightly different Linux setup on it - and the scope was recognised as /dev/ttyACM0 - a USB modem (supported by the cdc-acm module). I've had a couple of limited successes with this method, so I'm bringing both laptop and desktop up to the same software revisions. RXTX is giving me a problem though: it has a problem opening the handy gnu.io.rxtx.properties file, due to a (real!) bug. I'll sort that out, try sending a patch off to the developers, and see how I get on from there.

It's not looking very encouraging at the moment, I'm hoping for a piece of software anybody could just download and start using, whether on Windows or Linux (no means to check anything else), and it has been a bloodbath so far. Well, a nosebleed, at least. More later!

GW INSTEK GDS-2062

I bought this oscilloscope only recently. The list of features were excellent, and it cost about half what an equivalent scope would have cost from another manufacturer. I wish I had paid more. Don't get me wrong, it has lots and lots of cool features. When I calibrate the two channels, and attach the probes to the same ground and DC voltage, the scope reports values that differ by 10% between the 2 channels. The firmware appears to be not completely finished. It took me some frustrating days to work out that the 'menu off' button that restores the scope display doesn't work when the scope is 'STOP'ped. It has a sample memory longer than the section presented on the display. It has a cool 'window' bar to tell you how much of the sampled memory you're currently looking at. You would expect the horizontal /div and position controls to allow you to see the rest of the sample memory. They don't. It has completely locked up on me a few times, necessitating a power off and back on.

Emails to the company, and enquiries placed via their web form go unanswered. A representative from their US operation did once reply to say there would be updated firmware available in February. There isn't, in March. But hey, my own deadlines can be quite flexible. I am at least convinced that one day, they might release some updated firmware that might even be an improvement.

I did briefly enjoy using their Freeview software for a while. To overcome the problem with not being able to look at the full sample memory, I repeatedly triggered the scope against the same high-speed (~10MHz) digital event, each time advancing the trigger by a few microseconds. Each time I did that, I used Freevew to capture an image of the scope screen and then used the GIMP (marvellous, everybody should download it) to stitch the images together into one big image. Then I could read the content of the mysterious message. This is extremely laborious, but it worked. What I saved in the price of the scope, I lost in time. Recently though, the Freeview software just stopped working. WTF? It's a MS-Win based program, so when it stopped working, it told me with a little dialog. I don't know what the dialog was telling me - it was one of those win dialogs that have no understandable content, but you know, deep down inside, that this software is never going to work ever again, unless you reinstall your system and make several other things worse in the process.

So I've been writing a Java utility to display the waveforms. I'll post it somewhere when it's done. It will at least give me a choice of systems to connect my scope to. I end up transferring all the data from the Win XP software on my laptop back to my Linux desktop to work on it, I'd rather just use Linux on the laptop. In case you're wondering how it's going... well! Well, a little bit slowly. I'm using a null modem RS232 lead at the moment, and the gnu.io serial port classes from rxtx.org

Better get back to it, fixing the tools is easier than getting my work done, but it won't pay the rent!

Such a long time...

A lot of electronics has been arriving in the post recently.

I like Farnell in the UK. So what if they're expensive, you can just click on stuff, and it turns up reliably at the door in a day or so. It's not quite the same in Malaysia. Not sure why, but Farnell here, like a lot of other businesses, doesn't accept credit cards online. I don't have a bank account in Malaysia, so I have to give the money to someone else, who has to drive into the nearest town to a Maybank (no other bank will do), deposit the money into Farnell's account. Then when I get the paying in slip, I take a photo of it with my digital camera. Then I upload the picture onto the PC. Then I resize it, sort out the shabby contrast. Then I email it to Farnell in Malaysia. When they see the email, then they process my order. It's a bit too much effort for the prices. They're still as good as gold at speedy deliveries, but the payment method...

Silicon Labs

I was looking for a small microcontroller. The package was the major consideration, I wanted something that had a footprint under 8mm x 8mm. Lots (more than 13) of I/O pins, plenty of which could be configured as interrupts. That was about it. Oh, and non-volatile program memory that could be updated in-system via a 2-wire interface. I spotted the Silicon Labs selection in the Farnell catalogue, but they didn't have the complete range, so the combination of small package and enough I/O was missing. www.silabs.com had plenty of suitable combinations though, and had online ordering from Mouser

Mouser.com

This is more like it! Clicking and buying. And the prices seem much better than Farnell too. But perhaps it's because there are no delivery charges included. Express delivery from the US is not cheap, but not outrageous either. One caveat is clearly presented on the website: the buyer takes repsonsibility for import charges. I had no idea what they could be, but had heard of 200% duty on foreign cars imported into Malaysia, so feared the worst. There didn't seem to be any definitive schedule on any of the gov.my sites. A few days later, the man on the scooter from GD Express showed up at the gate. The company phoned the day before to tell me what duty had to be paid - it was 10% - no big deal! I'll use mouser again.

C8051F530 TB

I have some prototyping boards with the C8051F530 processors on. They're very tidy. A USB dongle connects the host PC to the microcontroller's C2 (2-wire) debugging interface, and the UART is accessed via a USB adapter and SiLabs' CP2102 USB/serial device. A free IDE is available, and everything seemed to work straight out of the box. Except... could I get a simple program to write messages via the UART? I could not. If you've got this kit, watch out for the TX/RX - Chip revision gotcha. I had a Revision A chip (TX = P0.3, RX = P0.4), the board is connected correctly, but the labels on the UART header are for the Revision B chip (TX = P0.4, RX = P0.5). Hard to debug something, when you're looking at the wrong pins...

UART0

My worktop has been USB city recently, so my notebook (with Windows, for the SiLabs IDE) was all out of holes. I connected the USB-UART port to my Linux desktop and downloaded the binary (no source) USB UART driver from silabs.com. Rubbish. It didn't work. A version problem, I suspect. I noticed that there is a CP2101 driver in the kernel source, so I built that and loaded the module. Worked straight away! Used minicom and waited for the debug messages that never came. Maybe it's me, or my Linux setup, but the CP2101 USB UART kept disconnecting, and reappearing as a slightly different tty. No use at all for debugging, except in a Darwinian half-an-eye-better-than-no-eye sort of way. When it seemed to be working, I was sure the UART debug code wasn't, and when it wasn't, I had no way of knowing anything.

Crossbars, masks, watchdogs and clock dividers

I was beginning to doubt my ability to get this microcontroller working for me. It's an 8051 internally, but with an awful lot of extra stuff. I expect I'll find all this extra stuff useful eventually, but it was like a combination lock that prevented the new user (me) from getting over the "Hello, wold" hurdle. I lost days, sleep, skin tone, arguments etc over this. Why can't it be easy? There were example programs with the IDE: too simple (blinky.asm) for this micro, too out-of-date if they were UART code. I tried emailing the EU support (yes, I know, but you try emailing anybody's ASEAN support for anything). They had been quick and helpful when I was choosing which micro to buy. They didn't reply. I did feel a bit hopeless, with my "Hello, world" problem. It had worked on every other 8051-alike I'd tried. And I had RTFMed to discover the crossbar, port IO masks, clcok source register, and some other bits that were new.

Obviously, I should have read the whole manual first. The answers were all in there somewhere, but there was one note at the foot of one of the pages which really sorted out the problems for me. Just in case, in the unlikely event you're writing "Hello, world" on the F530, and you're dying the slow death of the ignorant programmer, here's my code. You'd buy me a drink for this, if I gave you this in person. Remember me kindly at Paypal, and I'll definitely drink to your success.

.module hellowld
; Hello world on UART, 9600n81
.include "../c8051f530.asm"
SYSCLK = 24500000
BAUDRATE = 9600

.area HOME (CODE)
sjmp _main

; -----------------------------------------
; function RS232_putchar
; char in accumulator
; -----------------------------------------
_RS232_putchar:

mov SBUF,a
00101$:
jbc TI,00108$
sjmp 00101$
00108$:
ret
; -----------------------------------------
; function RS232_putstr
; location of string in dptr
; uses accumulator
; -----------------------------------------
_RS232_putstr:
00101$:
clr a
movc a, @a+dptr
jz 00104$
inc dptr
lcall _RS232_putchar
sjmp 00101$
00104$:
ret
; -----------------------------------------
; function main
; -----------------------------------------
_main:
; Disable the WDT.
anl _PCA0CN, #~0x40 ; Stop the PCA first - per note foot of p206
anl _PCA0MD, #~0x40 ; clear Watchdog Enable bit
orl _OSCICN, #0x07 ; internal oscillator / 1
; Timer 1 mode 2, 8 bit auto reload
mov TMOD,#0x20
; reset timer control sfr
mov TCON,#0x00
mov _CKCON, #0x00 ; clock / 12 prescale
mov TH1, #0x96 ; 9600 baud
mov _P0MDOUT, #0x08 ; P0.3 push-pull output
orl _XBR0, #0x01; crossbar UART output enable
mov _XBR1, #0x40; and enable the crossbar
setb TR1; enable timer1 run control
clr TI; prepare Timer Interrupt flag
mov dptr, #__Hello_World
acall _RS232_putstr
loop_forever:
sjmp loop_forever
; ------------------------------------------
; constants etc
; ------------------------------------------
__Hello_World:
.ascii "Hello, world!"
.db 0x0d, 0x0a
.db 0x00

Having a bad few days on the web. We'd tried our carpet-monkey on loads of cartoon movies: Cars, Monsters Inc., The Little Mermaid. She couldn't care less, all she wants to do is climb up the side of the stool I'm trying to work on and scream at me. It's doing nothing for my productivity. Jess brought home one of Malaysia's finest pirated VCDs, Barney's Sense-sational Day. My heart dropped. Oh no! My baby can't watch that mush! Fortunately, it wouldn't play on either of the two workstations on my desk. Unfortunately, after a few insertions, it played on Jess' old PC. It failed again after 10 minutes, but Emily was transfixed from beginning to IO error, and every time we started it again.

Fantastic! All we need to do is to get the geezer with the eye patch at the Black Pearl Multimedia Store to swap it for a good copy... Jess has that look on her face. I think it means something like "caveat emptor". Well, I wouldn't have agreed to her buying pirated videos if she'd told me beforehand anyway. If a crime's to be committed, it seems a finer thing to do it yourself than to pay someone else to do it for you. Also, we've got Streamyx's unlimited broadband package. Ho ho me lads! The booty's ours for the taking! A quick search later, and it's obvious lots of people must have children of a similar age with similar tastes. They can't be watching that stuff themselves, surely?

So I selected a few choice titles. And then I waited. And waited. Why is nothing downloading? Why is no-one uploading from me? There are some relatively popular titles sitting on my hard disk, waiting for 'sharers', my upload rate is often as high as my download rate, but now... nothing.

Days have passed. Today, a single download session started. From a Malaysian IP address. Hmmm. I suspect I'm no longer sharing files with the Internet. It's a common suspicion - try googling "streamyx p2p". It's a public holiday today, but I must try phoning TM tomorrow. Unlimited should mean exactly that. Is there a trading standards authority here?

I'm new here, aren't I?