1337 beef

Awesome old skool tech

2010-10-22T12:38:00.000-07:00

I've been quiet for too long... and I need to publish some more tuts on the NetDuino and other things I have been up to, but in the mean while check this out:

I picked up this fully functional valve based scope for R200 ( < $30 ). It was dirty as all hell, but I spent the last few evenings cleaning it up and now its shiny :) What a piece of old skool awesome! I think this is over 40 years old...

Don't make 'em like they used to!

-(e)

The NetDuino and some 74HC574's

2010-09-22T00:41:00.000-07:00

If you live in South Africa, you may remember these (ComCrypt 4000 MNET decoder):

Well a collegue found one, ripped it apart and found this little display board inside:

The board was soldered vertically onto the main board but with some judicious use of a de-soldering pump and some flux I got it free. My collegue gave it to me to have a look at.

This is how I reverse engineered it and connected it to the NetDuino:

First off, look at the chips on the board: we have two 74HC574 chips. A brief Google returns these as “Octal D-type flip-flop, positive edge trigger, 3-state”... at which point I went “WTF?” and had a good read on Wikipedia: http://en.wikipedia.org/wiki/Flip-flop_(electronics), then found the data sheet: http://www.datasheetcatalog.org/datasheet/philips/74HC_HCT574_CNV_2.pdf

Which didn’t help too much so I read that all again :)

The data sheet yielded the pinout above, and so I began tracing the connector pins to the chips and reading what the pins did. Here is a picture of the underside of the board

So.. All of the OE pins are tied to ground. This is good, it seems OE is “Output Enable”. Counting from left to right the pins are traced as:

NC (not connected)
Red LED GND
NC
GND
Clock pin (right hand flip-flop)
5V (Vin)
Clock pin (left hand flip-flop)
Green LED GND
GND
INPUT 7
INPUT 6
INPUT 5
INPUT 4
INPUT 3
INPUT 2
INPUT 1
INPUT 0
GND
5V

The input lines are connected to both flip-flops on pins D0-D7. The way the flip-flop works is that you set these lines high or low and then pulse the clock to transfer the state of the inputs to the flip-flop outputs i.e. the pins connected to the 7-segment LEDs. Basically between clock pulses the flip-flops will hold their output values thus keeping the relevant bits of the 7-segment display lit.

From here it was a case of wiring this up to the NetDuino. I connected D0-D7 to the corresponding D0-D7 pins on the NetDuino. Clock pins went to D8 and D9, the LEDs (red and green) went to D10 and D11 and 5V and GND went to the respective 5V and GND lines on the NetDuino. (Notice above that the two 5V pins are bridged, as are the GND pins. The GND pin for one of the chips is not tied to ground and if you omit this you will get weird values on one of the 7-segment displays. I believe this is called a “floating ground” and is the source of much evil...)

A note on “Active Low” (as I understand it):

If we look at the wiring on the Green LED, we can see that the positive pin is permanently connected to a shared 5V power line (shared with the flip-flops etc.) but the negative pin is connected to a GPIO pin on the NetDuino. So how do we switch the LED on? Well we need to write false to the respective output port:


// Set up the pin
OutputPort _greenLed = new OutputPort( Pins.GPIO_PIN_D11, true );
// Set the pin low
_greenLed.Write( false );

Writing false to the pin sets the GPIO port LOW i.e. brings the pin to GROUND, thereby completing the circuit and causing electricity to flow through the LED, lighting it up.

The data lines (D0-D7) are also active low, and it seems that the registration of the clock pulse occurs on the low edge of the clock. If you imagine the following (as a badly drawn square wave) then when the clock pin goes from HIGH to LOW (falling edge) the flip-flop reads the states of the input pins and transitions that state to the output pins:

Okay, so I made that up, I THINK that is how it works :) If anyone can explain this better then... great!

These decoders are dirt cheap (you can pick one up for around R50-R100 (<$15) ) and they have tons of excellent bits to harvest so go and GET EM! (The newer decoders also have bits and pieces but you have to make sure it is not a new tiny one. They are all SMD and pretty useless for our purposes). Have a look in your garage for old electronics, there is tons of stuff to harvest lying around... :) Here is the code:


using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace Decoder
{
  public class Program
  {
   private readonly OutputPort _clockPin1;
   private readonly OutputPort _clockPin2;

   private readonly OutputPort _redLed;
   private readonly OutputPort _greenLed;

   private readonly OutputPort[] _digitPins;

   private readonly byte[] _digitBits = new byte[]
                                          {
                                            1 + 2 + 8 + 16 + 32 + 64,
                                            1 + 64,
                                            2 + 1 + 4 + 16 + 32,
                                            2 + 1 + 4 + 64 + 32,
                                            8 + 4 + 1 + 64,
                                            2 + 8 + 4 + 64 + 32,
                                            2 + 8 + 16 + 32 + 64 + 4,
                                            2 + 1 + 64,
                                            1 + 2 + 4 + 8 + 16 + 32 + 64,
                                            1 + 2 + 8 + 4 + 64,
                                            128
                                          };

   public Program()
   {
     _digitPins = new OutputPort[]
                    {
                      new OutputPort( Pins.GPIO_PIN_D0, true ),
                      new OutputPort( Pins.GPIO_PIN_D1, true ),
                      new OutputPort( Pins.GPIO_PIN_D2, true ),
                      new OutputPort( Pins.GPIO_PIN_D3, true ),
                      new OutputPort( Pins.GPIO_PIN_D4, true ),
                      new OutputPort( Pins.GPIO_PIN_D5, true ),
                      new OutputPort( Pins.GPIO_PIN_D6, true ),
                      new OutputPort( Pins.GPIO_PIN_D7, true ),
                    };
     _greenLed = new OutputPort( Pins.GPIO_PIN_D11, true );
     _redLed = new OutputPort( Pins.GPIO_PIN_D10, true );
     _clockPin1 = new OutputPort(Pins.GPIO_PIN_D8, true);
     _clockPin2 = new OutputPort(Pins.GPIO_PIN_D9, true);
   }

   private void PulseClock( OutputPort pin )
   {
     pin.Write( false );
     pin.Write( true );
     pin.Write( false );
   }

   private void SetDigitBits( int digit )
   {
     if( digit < 0 || digit > 10 )
       digit = 10;

     digit = _digitBits[ digit ];
     for( int i = 0; i < 8; i++ )
     {
       bool on = ( ( digit >> i ) & 1 ) == 1 ? false : true;
       _digitPins[ i ].Write( !on );
     }
   }

   private void DisplayValue( int value )
   {
     int high = value / 10;
     int low = value - ( high * 10 );
     SetDigitBits( low );
     PulseClock( _clockPin2 );
     SetDigitBits( high );
     PulseClock( _clockPin1 );
   }

   private void Setup()
   {
     PulseClock( _clockPin1 );
     PulseClock( _clockPin2 );
   }

   private void Loop()
   {
     bool greenOn = true;
     int value = 0;

     while( true )
     {
       _redLed.Write( greenOn );
       _greenLed.Write( !greenOn );
       greenOn = !greenOn;

       for( int i = 0; i < 10; i++ )
       {
         DisplayValue( value++ );
         Thread.Sleep( 100 );
       }

       if( value > 99 ) value = 0;
     }
   }

   public static void Main()
   {
     Program p = new Program();
     p.Setup();
     p.Loop();
   }
  }
}

Zipit Z2 JTAG

2010-08-21T07:57:00.000-07:00

So I finally managed to brick my Z2...

Trying to get the sleep / reset cycle working in u-boot (look for a subsequent post) I managed to generate some dodgy assembler and the next thing you know...

Luckily I had a nice JTAG adapter lyining around, an Olimex ARM-USB-OCD. The soldering wasn't too tricky, but here is a detailed picture to help out the weary:

The interesting part was getting OpenOCD to play along nicely. To get OpenOCD working you need some configuration scripts that identify your CPU, JTAG adapter etc.

Here is the Z2 specific script (save this as e.g. z2.cfg):

# config for ZipitZ2

jtag newtap pxa270 cpu -irlen 7 -ircapture 0x1 -irmask 0x7f -expected-id 0x49265013 -expected-id 0x79265013

target create pxa270.cpu xscale -endian little -chain-position pxa270.cpu -variant pxa27x

# maps to PXA internal RAM.
pxa270.cpu configure -work-area-phys 0x5c000000 -work-area-size 0x10000 -work-area-backup 0

#flash
flash bank pxa270.flash cfi 0x00000000 0x1000000 2 2 pxa270.cpu

And the ARM-USB-OCD configuration (save this as e.g. arm-usb-ocd.cfg):

#
# Olimex ARM-USB-OCD
#
# http://www.olimex.com/dev/arm-usb-ocd.html
#

interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0003

jtag_nsrst_delay 0
jtag_ntrst_delay 200
reset_config trst_and_srst separate

What is interesting to note in the script above are the jtag_nsrst_delay and jtag_ntrst_delay values. The ARM-USB-OCD has separate lines for SRST and TSRT and the above values were required to get reset halt to work reliably in OpenOCD.

Reflashing u-boot brought the Z2 back to life and I now have a JTAG debug option. I should have done this years ago!

HTH
-(e)

edit: stupidly I forgot to thank the original JTAG legend GPSFan for his help and pictures and G1PowerMac for his site.

[Dingux] OpenTyrian Save and High Score entry

2010-07-27T04:48:00.000-07:00

I've started adding code for a limited kind of virtual keyboard.
This should allow save games names and high score entry in OpenTyrian.

So far it seems to be working for save games but I need to clean it up a bit and get it to work as a generic text entry mechanism.

Stay tuned, hopefully this will be finished before I depart overseas for a week.
-(e)

Dingux OpenTyrian release

2010-07-25T02:42:00.000-07:00

Here is an optimised build of OpenTyrian that plays full speed with sound. This archive ONLY contains the executable: opentyrian.dge, please overwrite your old tyrian executable or get the datafiles if you do not have them from:

OpenTyrian @ GoogleCode

Other changes:

Key mapping now works (segfault in code fixed)
Key mapping now swaps keys if an in-use key is chosen
SDL mouse cursor removed
Soft mouse cursor removed from upgrade etc. screens
Display is centred

These fixes also apply to the GP2X version and the patches have been applied to HEAD in the mercurial dev tree so feel free to build your own :)

Get it from the GP2X.com archive.

-(e)

sweetlilmre's tips to make your dev life suck less, part #1

2010-01-10T23:08:00.000-08:00

Disclaimer: The title might suggest that I invented or this originated this stuff in some way. I certain DID NOT :) Just some good reading I have done lately. And thanks to JonH for some of the links and discussion.

Dependency Injection:

JonH (a mate of mine from work) and I have been having some very interesting chats on Dependency Injection, Inversion of Control and other bits and pieces.

What this had made me realize is that there are some very simple development concepts (dressed up in frightening terms like Dependency Injection!) that really make your life easier if you practice them. Some of this stuff you pick up as a dev as you go along but formalizing the concept as soon as possible is only going to help you.

So start off by reading this:

http://stackoverflow.com/questions/130794/what-is-dependency-injection

Then ask yourself if you understand what Design by Contract means and how using interfaces applies and to and works with DI to make your life easier. Then have a look at this:

http://googletesting.blogspot.com/2008/07/how-to-think-about-new-operator-with.html

Which gives a nice round off to the DI discussion. This also seems like a great blog to follow generally.

This is all building up to unit testing and mocking, but we'll get to that later :)

-(e)

Under the radar

2009-11-22T06:20:00.000-08:00

I bought myself one of these little toys: USB LED Message Board
Disgusted with the app that came with it (can you spell CPU hog?) I reverse engineered the app and have posted source code to talk to it here.

This is written in C#, if you are one of those "I'm too hardcore to code in C#" people, you should be hardcore enough to translate it into C/C++... :)

In other news I have been working furiously with the Vice dev team (what a great bunch!) to get the SDL dingo port ready as an official port from the next (2.2) release. Hopefully we'll make it.
(Big shout-out to Nojoopa for all his help)

As far as the zipit goes, not to much to tell. Once the building is complete on the house and I can move back into my study, I'll get hacking on it again.

-(e)

Slackness

2009-09-21T11:46:00.000-07:00

Well yes, very slack am I. But I've been really busy in the background!!

Anyway lame excuses aside, I have a fullspeed port of Vice working on the Dingoo and am working with the Vice devs to integrate support into the main Vice tree, which is nice.

I see that much has been happening on the Zipit front! Hopefully Aliosa27 will get hold of me and I can merge his/her (?) work into the SVN tree. Come on people, get onto the #zipit channel on freenode so that we can co-ordinate all of this! :)

Again apologies for all the slackness, RL has me by the curlies.
-(e)

2009-09-08T15:32:00.000-07:00

Just managed to get an alpha port of Vice (the C64 emulator) onto the Dingoo A320.
I am awaiting news approval on gp32x.com but you can get it to try it out: here.

I have managed to fix a few more issues with it since the alpha release and hope to have a beta shortly. MarbleMadness at 50fps with sound (sometimes :)) ROCKS!
-(e)

kexec

2009-07-03T04:56:00.000-07:00

Well wadda know! Suddenly kexec is working.
I have a feeling this has something to do the the IRQ cleanup I sorted out in the main machine file a while back. So great news for kernel testing! It will certainly make my life easier in the future.

This also opens up the way for a small flash based user land that can kexec into a SD based kernel and full userland.

Linux... gotta love it! :)
-(e)

WIFI patch seems to fix issues

2009-05-26T16:14:00.000-07:00

Well, wouldn't you know it, this patch http://lists.infradead.org/pipermail/libertas-dev/2009-May/002412.html seems to fix the Z2 WIFI driver timeout / failure issues.

Thanks to GPSFan for spotting this.

Now I can stay connected to my AP for hours. Great Success!
In other news, the battery driver is in, along with LED triggers and some other nice bits.
I should have a new kernel and userland up in a short while.

Oh, and if you haven't already, check out the wiki on OpenZipit I've added some info.
-(e)

New OE build!

2009-04-13T12:11:00.000-07:00

Please disregard the previous posts about building OE.
I now have a project set up on SF.

Quick start:

In a term in your home folder:

svn co https://openzipit.svn.sourceforge.net/svnroot/openzipit/oe

Then:

cd oe

Then:

make

Then:

wait :)

Read the README, it has a lot of important info about building sucessful images!

More soon
-(e)

Zipit2 linux 2.6.29-rc3 support

2009-01-30T02:42:00.000-08:00

Here is a package to support the 2.6.29rc3 kernel.
This package needs to be extracted into your openembedded/packages/linux folder.

The package contains patches for sound, keyboard, backlights (both of them!) and pretty much everything to date. Obviously this is highly experimental, but give it a go if you are feeling adventurous! :)

Getting there!
-(e)

Zipit2 Keyboard Backlight!

2009-01-29T22:33:00.000-08:00

Last night I managed to patch the pwm_bl driver to actually support multiple backlights and now we have keyboard PWM backlight support in! w00000t!

I will put up a patch later :)

Please see the updates I have made to my post about supporting the original kernel if you are going to use it, some important stuff was missing (my bad).

-(e)

Original Z2 kernel support in OpenEmbedded

2009-01-28T02:41:00.000-08:00

In my last post I provided a setup system for Zipit2 OpenEmbedded development.
As I mentioned in that post, only my test kernel 2.6.27.10 was supported. I realised that until full kernel support is available, people would probably like to build the old kernel to play with.

So here is a package that will provide 2.6.21.1 kernel support.
The setup package creates a configuration that will leverage OE's package version support to build the latest kernel, so in order to use this kernel you will need to navigate to your packages/linux folder and rename the linux-zipit2-2.6.27.10.bb file to something else e.g. linux-zipit2-2.6.27.10.bb_.

Once you have done that, extract the contents of the archive to the packages/linux folder and:
bitbake linux-zipit2

It is possible to specify a prefered kernel version in your local.conf file to override this behaviour but I do not have the exact syntax available. If anyone would like to comment and leave instructions on how to achieve this override, that would be great.

Have fun! Shortly I will be adding a package for cutting edge 2.6.29 support in the quest to achieve mainline acceptance.

edit:

Like a total fool I forgot to mention that you will need to add the checksums for the kernel into checksums.ini in your openembedded/conf/checksums.ini file, here is the text you need to add:

[http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.1.tar.bz2]
md5=a28b78793cd368592f7873bf36cb38b0
sha256=2e92625e887bff35522eed3eecc2b80eb9a588d3c0eac64f35b4d29a557bac15

edit2:

Another missing component. Sigh. In an effort to cleanup the original SVN files I nuked the packages/sysvinit/sysvinit/zipit2/rcS file. Unfortunately this is where the old (crappy) keyboard drivers are loaded. To sort this out you need to patch this file, look for:

#
# For compatibility, run the files in /etc/rc.boot too.
#
[ -d /etc/rc.boot ] && run-parts /etc/rc.boot

and add this text after it:

# for now, the module loader is not working.
/sbin/modprobe pxa27x_keyboard
/sbin/modprobe zipit2_kbd_helper

Which should sort it all out.

-(e)

Openembedded and the Z2

2009-01-26T11:28:00.000-08:00

So after a long delay I finally have something concrete to add to the blog.

If you want to get started with the Zipit2 you'll probably have stumbled across the linux.zipitwireless.com site. Here there are links to all sorts of bits, one of which is an OpenEmbedded 'starter kit'. The problem is: the code you pull out of SVN to get started is very old and still relies on the monotone OpenEmbedded repository, which does not exist any more.

OpenEmbedded is complicated enough that broken setup scripts do not help in any way. So I have put together this package which should get you from zero to base-image in a fairly painless manner.

Currently the package will:

Install a local copy of BitBake
Pull the latest GIT repository of OpenEmbedded
Patch the repo for Z2 support
Build up a profile.sh script for you to run when you want a sane dev environment
Build up a local.conf file for the bitbake system and the Z2 machine
Add the linux-2.6.27.10 kernel build and all associated scripts

This is still very much a work in progress, and while I have tested the build (it works and generates a valid kernel and userland) many changes are going to be made in the near future.

Exciting stuff coming is a port to as new a kernel as possible, with the intent to get kernel patches pushed upstream and the Z2 integrated as proper machine. All of this thanks to the tireless persistence of GPSFan and some grunt work by me :)

Until the next update...
-(e)

Zipit Z2

2009-01-13T12:32:00.000-08:00

Recently I acquired a Zipit Z 2 when my sister-in-law brought one over for me from the States (thanks Ange! :)).

The Z2 is marketed as a portable IM client for kids. It's an Intel PXA based device with a wireless chip running a Linux kernel. On top of this is some front end software that is used to handle various IM accounts (MSN, Yahoo, AIM). As a usage example: my niece IM's her friends on the way to school, picking up various AP's along the way.

Thanks to a useful site I was able to connect up a serial terminal to the Z2 and begin exploring it (see notes: 1). The Z2 is an interesting little machine, the more so in that Zipit has made available their kernel patches and actually encourage community involvement, something I find rather refreshing.

After building the stock OE kernel, I became rather obsessed with trying to get the latest (as of writing) 2.6.27.10 kernel running on it. I built a kernel and forward applied some of the original patches. This got me to a basic running kernel, but one that would not boot to MMC (my plan was to have userland on MMC). At this point I got rather stuck and so headed off to #zipit on freenode for some advice.

Fortunately for me, I met up with a brilliant kernel dev by the name of GPSFan who took a look at my patches and .config, and helped me get it to a stage where MMC booting was possible. At this point LCD and keyboard were not functioning, but it seems I had managed to generate a level of interest. In a short while, GPSFan managed to get the framebuffer (see notes: 2, 3) going. Further experimentation on my part revealed that the stock kernel keyboard driver was functioning to a certain extent, but that key mapping was incorrect. Once again GPSFan managed to get the keyboard working!

We are now at the point where we have a functioning machine but without wifi access. GPSFan is looking into it and hopefully, thanks to the recent advancement of the Libertas SPI driver and his efforts, we will have wifi access shortly. This will open up many possibilities!

I intend to provide patches for OE and various other bits of info on this site as development proceeds.

Notes:

The serial port on the Z2 is at TTL levels, this means you will need a level converter in order to connect it to your PC's serial port. I have sucessfully used a Samsung E810 serial cable to achieve this. Info on this cable can be found at this site. Look at this site for the soldering positions on the Z2 board. The serial port is mapped to ttyS2, at 115200 8N1, no flow control.
The framebuffer handling includes a PWM backlight exposed through sysfs. If you mount sysfs (mount -t sysfs sysfs /sys) you can echo values to the backlight to set it: e.g. "echo 512 > /sys/class/backlight/pwm-backlight/brightness" which is pretty damn cool.
The framebuffer, if used as a console, will initially be incorrectly oriented. To correct this you can either: "echo 3 > /sys/class/graphics/fbcon/rotate" after mounting sys or, use "fbcon=rotate:3" as a kernel parameter. My current kernel parameters are: root=/dev/mmcblk0p1 rootdelay=2 console=ttyS2,115200 fbcon=rotate:3