So, a week or so ago I got it in my head that I wanted to compare the performance of various LCD display modules. Yeah, I know, weird. I wrote a little app for the PIC-EL using a PIC16F648A to see how long a few operations took to become un-busy. Looked promising, but there was considerable variation within a single LCD, and since the only actual I/O on the PIC-EL is the LCD itself, taking a lot of readings to get a decent read on the variation was frustrating.
So, I need to get the data out of the PIC, probably to the PC. My knee jerk was to go to the Explorer-16 board which has a serial port. I even had a spare PICtail prototyping board I could mount a socket for the LCD on. I didn't get very far down that path before I realized that the only PIMs I had for the Explorer 16 were 3.3 volt parts, and all my LCDs were 5 volt LCDs. Conditioning all those LCD lines, most of which are bidirectional, looked like no fun at all.
So, the next plan was to use the 28 pin 16 bit starter board. I will take a dsPIC30F, a 5 volt part, it has no serial, but it does have USB. I had a few different 28 pin 30F's on hand; chose the dsPIC30F4012 simply because it had the most memory which meant I could be fairly reckless in my code.
The 28 pin board also has a PIC18F2450 on board programmed to look like a USB to Serial converter. Years ago I made it work on Windows by using a Microchip provided .inf file, but I have never been able to make it work on Linux, and have long since lost track of that .inf file.
I few weeks ago I had chased down that USB rabbit hole again, learning far more about USB on Linux than I ever wanted to know, but not enough to make the board work. So, I would have to be a little more persistent.
Well, it turned out that Linux had figured out the board all by itself; I was making it far harder than it needed to be. Instead of showing up as ttyUSBx like a normal USB to serial converter, the 28 pin board was showing as ttyACM0. GTKterm didn't show that in its port list, but by poking it in, I was able to capture output from the 4012.
So, I wrote the little PIC program to send SQL INSERT statements to the PC so I could just poke them into MySQL and then slice and dice how I wanted with R. The results were confusing at best.
My code was something of a hack at best, I needed to re-compile every time I changed LCDs. PICs aren't the most user friendly thing in the world, and that seemed easier than trying to figure out how to code some user query when the only input device I had on the board was a single pushbutton and a pot.
Also, the LCD code I had written was far from optimum. I wanted to make it as lean and straightforward as possible to be sure there were no surprises, especially since some of the measurements looked suspicious. So, I went to work on a separate app, using essentially the same LCD code, but this time aimed at exercising all the LCD functions and making sure that there were no little hacks and workarounds in the code that might be causing me some confusion. That went surprisingly well.
Well, I found yet another LCD, and a friend had a few more to add to the mix, and it hit me that while there were few I/O devices on the board itself, I was now connected to GTKterm, which can write as well as read. So the next step was to code a simple menu of LCDs. Again kind of a hack, but I could now select the LCD from a list instead of recompiling every time I changed. Sure, I still had to compile to add a new model, but I still had tons of free memory.
Another little detail. I've been programming the PIC from a Windows VM. I've been using an ICD2LE redirected to the Windows VM. It is fairly convenient to compile and build within MPLAB. I get around some of the Windows frustration by using a drive on a Linux VM for the projects, shared via Samba with the Windows VM and via sshfs with the Linux host. Not the simplest thing in the world, but it works.
Microchip had dropped support for the ICD2 in the production release of their Linux IDE, which seemed to have a zillion problems anyway. Santa brought me an ICD3, but I had never actually gotten it working. Since the USB emulation on the 28 pin board had gone so well, maybe a little persistence could make the ICD3 work. Well, once again, there really wasn't much to it. It simply worked. But, as i used the new, fancy, MPLAB-X it became apparent that there are plenty of regressions compared to the old MPLAB-8 on Windows. It is darned convenient not have to deal with Windows, but whether I can get used to the lack of a lot of features remains to be seen.
So, now it is time to test that additional LCD, get with my buddy and test a few more, and perhaps merge the "good" LCD code into the measuring app and rerun all the tests, probably with some additional conditions.
But then I made a BIG mistake. There was one of those annoying little gear things at the bottom of the screen, so I decided it was time to get rid of it with a yum update. After rebooting, my /dev/ttyACM0 was gone. After a couple of time plugging and unplugging, I realized that the starter board was causing TWO /dev/ttyUSBx's to appear. Of course, neither of them had my data.
So, a little searching of yum.log showed a few possible culprits. One was the kernel, he could be the bad actor. There were also two USB-related packages updated; usb_modeswitch and usbredir. Neither looked particularly promising. One has to do with the virtual machine and the other with network cards, but they do both mess with USB.
The easiest thing to test is the kernel; I could simply reboot and choose the previous version, so that is what I did. Voila! My /dev/ttyACM0 was back. Unfortunately, it still doesn't get any data. And yum downgrade doesn't seem to be able to unravel the dependencies in the other packages.
So now I'm sitting here grumbling, scratching my head, wondering what my next move is.
waiting for your next move...
ReplyDelete