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?