Interactive Shell Achieved

Success! On the /etc/inittab line normally starting an ash shell instance with the serial port as stdin/out, I have substituted my own binary (gritty, a hack, not complete, caveat emptor and so on) which identifies which /dev/input/event* is a keyboard and starts reading from it. Gritty then starts a pseudoterminal, and runs ash, feeding it the keypresses it detects, and putting returned outputting returned data (on the serial port as it were)
main screen turn on

The latter part could possibly be automated by some extra dup2() calls, but if that is a good idea would also depend on wether I want to do some translation first, e.g. as of now I have no handling of escape codes, so any terminal output with colour, or worse yet, curses apps makes everything go bananas. Another thing that remains to be done is the correct interpretation of modifier/special keys.


An Arduino Yún and an ATM12864D Display

In the beginning of the year I received an Arduino Yún from good friends as a birthday gift. Fitted with both an Atmel Atmega32u4 as well as a small Linux module running some spin of OpenWRT. I'm not sure what it's final use will be, or if it will move from project to project as an intermediary solution until I get boards fabbed for the real deal. After all that is part of what the selling point of the Arduino platform is. I'm crunching down basic C on the AVR though, ditching the Arduino software/firmware platform, I can not stand it. I want to be able to flip bits on the metal. And somebody will say "oh, C, he uses a high-level language…" and another will chime in with "oh, digital electronics…" and so on. Everybody has their level of comfort. In the microcontroller world mine is C, and occasionally ASM.

Years ago I bought a graphical LCD display, way before oleds and whatnot were starting to become common in the hobbyist crowd. 128x64 pixels, monochrome white foreground on blue background. KS0107+KS0108 drivers. I never got it to work very good, I—with relative little experience at the time—were bound to bodge the connection of at least some of the 20 pins it needed power and signals on. Or get the timing wrong. Or both. Then there was the fact that not many of my few projects actually needed or could take advantage of a graphical display. A button and/or a RS232 connection to a computer usually were enough.

Now with the Arduino+Linux module, and for that matter, more experience, what if I tried to tackle the display again? I set out with the goal of reading the serial output from the Linux module and pushing it onto the LCD, effectively making the AVR+LCD a serial console for the Linux module.
After a very brief search it seemed that the Arduino was not made with writing a whole byte to a range of pins in paralell (like PORTD=0x2a) in mind, and at that time I decided that enough is enough, and purged the Arduino stack and switched to C. When writing this post I did some searching again, and of course it seems to be the case that one can use e.g. PORTD=0x2a in the Arduino stack. Oh well, switching to C is something I wanted to do in the first place, so it does not really matter.

Then came the second and third setback, the Arduino headers I wanted to use do not map to consecutive bits of the various AVR ports, mitigating the benefit of being able to write a byte to a port in one go. And for that matter, some of the pins I wanted to use were tied up in special nets connecting the AVR to the Linux module. This is the reason I dead-bugged the 74LS164 shift register in the previous post.

It's so pretty! And neat! Hm, actually, for a random wiring job I think it's not that bad…
The datasheet of the display (ATM12864D) is pretty helpful, apart from one single point that had me quite confused. The pinout lists a D/I signal, and the longer description had me believe that it was an internal signal (e.g. between the KS0107-KS0108 chips or whatever) that for some reason was routed to the external interface as well. The command table on the other hand, lists an RS signal, absent from the pinout, and used to differentiate between display pixel data, and instructions (hmm… D/I…). I've seen no comment about this elsewhere on the net, so in the case anyone is as confused as I was, and happens to stumble upon this post I'll state it explicitly: For this particular display, the RS signal listed in the command table is the D/I signal listed in the pinout.

Pair programming, now it's the cat's turn at the keyboard.
I also have the chance of getting my projects ESD tested. For free.
After a while of still not getting any consistent behaviour from the display notice that I have soldered the data bus cable the wrong way. After a while of putting off having to resolder the cable, by mirroring every byte written, in software, the thought strikes me. Hey! I can clock out the data to the 164 LSB first instead of MSB first!

It seems that the stereotypes are true…
Now with the ability to get arbitrary grahics data to the display I notice that a column is dead, constant off, unless I hold a finger on the unpopulated C12/13 pads on the back of the display, in which case it turns constant on.
Very irritating, but if I tailor the font routine and offsets etc. I can make so it is at the part of the text matrix that is the space between letters and always off.

After a while of fiddling around with trying to find out the correct baud rate for communicating with the Linux module (it's 250k by the way) I figured that maybe the display updating routine was too slow to run each time a byte is received, and moved reception to an interrupt routine, left updating the display to the main loop. Success!

Boot messages!


Dead Bug Soldering

Only stock up on SMT parts he thought… It's the future he thought…
In litterature, movies, …culture at large, when they want to emphasize how mean and sadistic the bully is, it is not that uncommon to mention how he likes to pull the legs off of spiders and insects. But what about those who try to add legs to the poor critters?



Most of the project pages have been moved, partially rewritten, and published. Given that I can publish not only blog posts, but also maintain pages, is very convenient and I don't miss much from my old CMS to be honest. There is one thing though, and it is a bit of a thorn in my side. Images.

On my old setup I could have images of any aspect ratio side by side without it looking horrible, because the image displayed on the page would be resized to a predefined size, and cropped to a square with a link to the uncropped, unresized image. No such thing here—as far as I can tell—unless one wants to do it manually, which would be of little benefit anyway, since the editor does not really want to place images beside each other, only images on their own, or, images beside text. But then again, I have only used the wysiwyg editor so far, and not tried to do any raw HTML editing. Not that I like writing raw HTML.

I don't.

I dislike it enough that I wrote a CMS to get out of it.



I am moving, and since I am unsure of wether or not I will be able to host my own server in my new dwelling place, I will take this as an opportunity to check out using blogger as the host of my general web content, given that I already use github for my public code hosting.

My other uses such as irc connection persistency or home to not-home file transfer and back, I can either live without, or can be solved through other means than a public-facing server for the time being. It has after all been established that a carrier pigeon with a high density memory card is faster than trying to move large files through the regular tubes.

I have never blogged before—it will be interesting to see if, in a year (or whatever), this stays the sole post on this blog, or if it will steal or duplicate some of the content I usually broadcast on facebook, given that the layout or more generally, the fact that it is a blogging platform after all and not a general CMS, lends it to a more journal-style of writing. Maybe there will be some thoughts and not only projects this iteration. Time will tell.

I should really be focusing on getting all my stuff into boxes—or smaller boxes into bigger boxes as it is in some of the cases (ha!)—but of course I sit here trying to minimize the disruptive effect on a website even I don't visit very often…oh well…