Loading ...
Sorry, an error occurred while loading the content.

14517Olduino Shield Adapter - Hardware Mountain

Expand Messages
  • bill rowe
    Nov 14, 2013
    • 0 Attachment
      After a bunch of false starts and rabbit holes the shield adapter is working.  Besides the wrong footprint for the 74238 I had misrouted one trace, I had to replace a 74373 latch with a 74374, and I had to insert an RC delay - the 4093 isn't nearly as slow as the 'typical' value on the data sheet.  The result is quite a messy looking board with dremel'd out traces and jumpers but it's quite solid and predictable now.  

      The basic function of the board is to provide input and output shift registers for Serial Peripheral Interface(SPI) communications, and a parallel output port(POUT) lined up to arduino-spaced header connectors.  Because it's working outboard of the Membership Card's circuits the output addresses always include N2 - the output shift register MOSR is OUT 6, MISR is IN 6, and POUT is OUT 4.  The shift registers are clocked, for the moment, with OUT 2.  The serial output is the SPI standard MOSI the input is MISO, and the clock is SCK.  

      The parallel output port and the shift registers are connected to arduino-standard headers as shown below. I lined up MISO, MOSI, and SCK with the arduino standard and ran the 1802's parallel outputs from what would be the arduino's pin 3 to 10 - this avoided the arduino uart pins and included arduino pin 10 which is commonly used for SPI slave selection.  The EF lines are over where the arduino has analog inputs.  This may seem odd but those pins are probably not used by most shields and so, in some sense, this is a safe choice. Q ended up on the same header with the EF's for no particular reason.  I looked at a couple of shields before laying it out, the ethernet and SD card shields at least should be compatible.  
       
       

      The finished board is shown below on top of the olduino on top of the membership card.  These are the foothills of the Hardware Mountain.  You can see the relocated 74238 chip on the left but the rest of the bodges are hidden under the board.  
        

       
       

      The first thing I always try out with a new SPI setup is a little LCD from a nokia cell phone.  It's an 84X48 monochrome graphic display driven by simple SPI commands and it reminds me of a pixie graphics display.  You can see it below showing the standard starship display.

       
       


      The next picture shows the hardware mountain from the side so you can truly appreciate the heights we're reaching.  At the bottom is the membership card which is doing all the work.  Above that is the olduino board that loaded the code into the 1802 and is now asleep.  Above that is the shield adapter.  Above that is the prototyping shield.  Above that is the LCD riding its own little adapter card which is just converting from 5v signals to 3.3.  I realize this is crazy but I never planned the shield adapter as a standalone board.  It will either merge into the olduino(easy) or make a larger board which has the 1802, olduino, and spi hardware all in one. 

       
       



       Performance-wise, It's getting pretty much as expected.  Using OUT 2 as the clock requires one 1802 instruction for each bit which means 100,000 bits per second peak.  With loading the shift register, call/return overhead, and other housekeeping, we get a sustained speed of 57,600 bps or 7200 characters per second.  That's plenty fast for the little LCD -  Its 4000 bits load in a blink.  It would be marginal for something like ethernet where there's more protocol overhead and bigger chunks of data.  The plan for that is an independent clock to drive the shift registers.  Something like a 1.6 or 2 mhz clock would boost peak speed a lot and, just as important, it would avoid the 1802 having to shepherd each individual bit.  The SPI clock of an arduino is normally 4MHZ so peripherals can handle anything it would throw at them.  

      Below is a pointer to a little video of the starship animation.  The animation code is written in C but it calls assembly language routines to transfer the data.  I imagine it's running around 20 frames a second.