Test uploading a video

Simple test of LCD library inserted  into C I/O stack on a Newhaven LCD

Now try an HD video

This is a very small, positive Newhaven display.  In this case driven by a dsPIC33FJ256GP710

The display area on this little 2x20 is only about 1cm high.

World Wide Web announced

H/T Jan Wildeboer:

21 years ago: Tim Berners-Lee announced the World Wide Web.

"This project is experimental and of course comes without any warranty
whatsoever. However, it could start a revolution in information access."

Yep, it did.

https://groups.google.com/forum/?fromgroups#!topic/comp.sys.next.announce/avWAjISncfw[1-25]

From Phoenix to Mercury

Sigh.  The "next Multiply" activities are very discouraging.

First, we have anotherblogspot.com.  I have to applaud herbearjc for taking the bull by the horns and making something happen, but I don't think it will last.

He took an existing FOSS application (good plan), put it on a commercial host (for starters, another good plan), and is hacking away at it trying to make it look like Multiply.

Unfortunately, the starting point is a LONG way from Multiply.  I doubt very much he will be able to get close enough to make it appealing.  There is something about Multiply that makes it so much nicer than Facebook or Blogspot, or Wordpress, or livejournal, and it is hard to put your finger on just what that is.

But there is another problem.  The site is already quite slow, and as it develops and gets more users, it will get slower.  If it keeps expanding, the bandwidth costs are going to become unmanageable.  That's the thing about the off the shelf hosting providers; they are quite affordable for low bandwidth sites, but as you add users and increase the bandwidth demand, the costs explode.

Plus, as basically one individual doing this as a personal project, at some point he is going to get fed up with it.  I give it two years, tops.

Paul and Kimberly are going at it from entirely the other direction.  They realize they need a business plan so they are working that angle. Now, Kimberly clearly has a LOT on the ball.  Paul hasn't really provided me enough data to be able to judge, but there is at least some evidence he hasn't got a clue.

Their problem is that they are convinced they need to build their own datacenter. Not only is this an expensive undertaking, but it entails long term costs that are far more manageable when shared with others through some commercial host or the cloud.  The probability of them ever getting off the ground seems slim, although they are at least looking at some of the hard problems.

Their main concern seems to be privacy, which is really kind of worrisome.  They have this illusion that if they control the hardware it will be more secure than if a team of experts is adding to their own security.  This is a fairly common fantasy among folks with relatively little experience.

If they ever get it off the ground they are going to have to charge big time to support their private infrastructure. I don't see it becoming a reality.

herbearjc may have a more economic model, if he can 1) find some income source and 2) recognize the need to change models over time.  He can buy bandwidth and cycles, and at some point move to the cloud or to a large scale provider, perhaps first the cloud and then to an Akami or somebody like that.

But he somehow needs to build a sustainable business structure, and I see no evidence of that happening.

End of Multiply

Well, like so many others, I am disappointed.  Multiply has tended to be more "personal" than other SN sites.  Over time I've taken less advantage of that. As much as I enjoy the late night chats, even the debates, they eat too much time that I don't have.

I am on a number of other sites, mostly with some purpose.

Of course, like everyone, I'm on FB, and there I am connected to many of my Multiply friends.  I hate all the game stuff, and although I have managed to block all the stupid game requests when I access FB from my PC, those blocks seem to be ignored on my phone.  All that noise on the small screen makes the mobile application pretty much useless.

I do blog on LiveJournal from time to time.  Mostly that is intended to be Fedora stuff, and lately it has been only cross posts from Multiply of those posts I want to share with my Fedora friends.
http://jjpmcd.livejournal.com/

I'm also on Linkedin, that's mostly Emcomm folks and former co-workers; there's like a bazillion "groups" on Linkedin, but I rarely post on any of them.  Seems like most of them are places for headhunters and similar folks to advertise, although there are some groups that seem to be pretty interesting, but to be useful they take too much time.

Oh, and don't forget G+.  This is basically FB without the games, and it could be really good except that not a lot of folks are on it.

And of course twitter and identi.ca.  These are, of course, a totally different model, but still useful.  Admittedly, I don't check either as often as I should.

None of these, tho, comes close to Multiply in the really great combination of features.  Is there another similar thing anywhere?

Michigan's Governor

Today I was in Lansing for a Tabletop Exercise.  Governor Snyder attended.  I have to say, I was favorably impressed with how engaged he was, and his spin on several issues that arose during the exercise.

On the drive home I got thinking about emergency management, politicians, and governing.

For a politician, emergency management is a good thing to stay away from.  I'm sure the governor has lots on his plate, and has to be careful where he spends his time.  The community of responders is relatively stable, so if there's a screw up somewhere, there is bound to be someone around to blame it on that was appointed by your predecessor.

On the other hand, if things are done right, nobody ever knows.  So if you are a politician, there is simply no gain to be had from spending time on emergency management.

On the other hand, if you are the governor of a state, and take your responsibilities seriously, there can't be a lot of priorities higher than keeping the citizens of your state safe.

It appears to me that Snyder may well be the guy he claimed to be during his campaign.  Given the degree of confidence I have in elected officials lately, that is very disorienting.

MPLAB-X Review

I first tinkered with MPLAB-X during beta.  Although it was promising, it seemed flaky enough that I didn't want to move to it yet, plus, I wasn't doing a lot of PIC stuff anyway.

More recently I've been doing a bit more with the PIC.  I had installed the release version but had quite a few problems so I put it on the back burner.  I thought maybe it was time to go back and see whether it was going to be a good thing.  All of this is based on MPLAB-X version 1.00 on Fedora 16.

For whatever reason, perhaps updated libraries, perhaps the last time I played with it I had got the configuration right, whatever, but it worked quite well for me.  Mostly I used the C30 toolchain, although I did tinker with the C18 toolchain.

One of the first things you notice is that the buttons are all different.  Nicer looking to be sure, but since they don't look like the old version, confusing.

One of the very nice features is that there is a build, program and run button.  That is a departure from MPLAB 8 where they are all separate steps.  Also, instead of having production and debug configurations and targets, you can simply click "Debug this project" and the project gets rebuilt for debugging, programmed and started.  As in earlier versions, the debug buttons don't show up until you start the debugger.

Another big change is that the window is tiled.  You could set MPLAB 8 up that way if you wished, but when debugging you need so many windows that it is pretty unwieldy.  On MPLAB-X, though, everything is tabbed, so the tiled model is actually pretty nice.  Once you get the idea of where things are, you aren't always hunting for hidden windows like in earlier versions.

The left hand area has a number of surprising choices.  The most obvious, perhaps, is the dashboard.  This seems to take a page from Piklab, but there are a couple of nice features, like bars showing memory used and a section showing the status of the programmer.

You can have multiple projects open at once, and the "Projects" tab shows all the open projects, and allows you to navigate for files in those projects.  the "Files" tab is similar, but also allows navigating the various project subdirectories for object files, executables, etc.  Yes, MPLAB-X makes a number of subdirectories so your main project directory doesn't get cluttered with all the odd MPLAB created files.

The services tab allows you to add team servers like java.net to your project,  also issue trackers such as bugzilla.  I tried adding a local instance of bugzilla with no joy.  Not sure if it's broken or something lacking from my bugzilla instance.  the only other issue tracker available is JIRA.  Whether Trac or similar trackers could be added reasonably I have no idea.

But to a degree that fits.  There is also a "Team" menu that allows connecting with CVS, Mercurial or Subversion.  Where is git?  Who knows.  Seems odd to have all these old RCSs and not the most popular.  But it appears that perhaps the Pony Express doesn't make it out to Arizona with news more than once a decade.  Still a step up from the time when the only choice was SourceSafe.

On the bottom is a tabbed area very similar to the "Output" window in earlier versions, but with a lot more capability.  Besides showing you the compiler output and the status of the programmer/debugger, it also has a very cool "variables" tab when debugging.  If you halt in a function, this tab shows the values of all the automatic variables in the function, as well as any watches you have defined.  This really cuts the need for the various debugging windows, and automatically shows you the exact things you probably want to see.

There is also a tab showing all the breakpoints you have defined, along with checkboxes allowing you to disable them without having to track down the source line.  But wait, there's more.  When debugging, hovering over a variable will show you its current value (if it is in scope, of course), and if it is a structure, will even show you the bits and pieces -- especially handy for special function registers.

For your static variables, it also shows the address of each element.  Very, very handy.

MPLAB-X starts very slowly, being a huge Java app I suppose that isn't much of a surprise, but once started, it seems to be quite speedy.  It seems especially quick for compiling and programming, odd, since it apparently uses the same compilers as MPLAB 8.  The build, program and run button, one of the most common things to do during development, seems especially quick.

But there are some things that seem to take an inordinate amount of time.  When a program is running, placing into reset seems to take forever.  A simple task like that shouldn't take visible time, but it is at least 3 seconds on a very fast computer.  Releasing from reset also seems slow, but nothing like holding the target in reset.

Probably the biggest win, though, is the editor.  It seems to make a lot more sense than the old one, especially with tabs.    It automatically puts in closing parentheses and braces, but unlike most other editors, if you habitually type that closing paren, yours simply writes over the provided one, unlike other editors where you may find yourself constantly erasing extra parens.

If you click on a variable or function, it highlights all other occurrences of that variable or function on screen, and places little tic marks to the right of anywhere else that function appears within the file, so you can even track down off screen occurrences easily.

The right-click menu lets you go straight to the declaration (or header or implementation in C++),  find other occurrences, etc.  It will even generate a call graph.

With all these features, though, I am still left with the feeling that there are important features from earlier versions of MPLAB missing.  The more I use MPLAB-X, though, the less I feel that, and the more it does seem like a significant step up.

Now if I can just figure out how to make a git plugin ...

Weird PIC stuff

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.

http://www.qsl.net/wb8rcr/LCD-data-1.html

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.

Justice Ginsburg Advises Egypt to Look to South African, not U.S., Constitution as a Model

Breathtaking

http://www.fedsocblog.com/blog/justice_ginsburg_advises_egypt_to_look_to_south_african_not_u.s._const/

Even if the SA constitution didn't include some really abhorrent stuff, for a sitting Justice to make such comments borders on treason.