Propeller network layout for RasPi accessory

Four Propellers... 64 user-GPIO pins... 1MB distributed SQI SRAM... Dynamic clock modulation...

... makes for a lot of head-scratching and frowning.

I've been roughing out a design for a PCB that has all of the above features.  Nothing particularly complex in it's intrinsic form but may lead to some quite interesting possibilities for those interested in high-speed signalling or even RF modulation (HAM radio).

Here's a simplified sketch of the Propeller network...

Here we have "M" (master) which talks directly to the RasPi and coordinates the three slave Propellers.  M controls the startup sequence for S0, S1 and S2 and also acts as a system watchdog, able to reset each slave if required.

All 4 Propellers have 16 GPIO pins exposed via male 0.1" headers, up to 256KB of SQI SRAM, and I2C access to the 256KB EEPROM.

Not many pins left now, 2 remaining unused on each slave, and the Master has none left.  Although I'm thinking of dropping the Master's GPIO exports down to 8 instead of 16 and gaining 8 more specific purpose pins for implementing some more cool features.

In any case I'm trying to make this a powerful board that concentrates on a good range of fast resources and the ability to generate high speed signalling on many pins simultaneously.  But each Propeller has a direct asynchronous connection to each other Propeller, so it will be possible to constuct some very complex systems with both high speed processing and high-resolution, low latency IPC channels.

RasPi Propeller Shield - work commences!

Like any other electro-mechanical-engineeringly inclined hobbyist, I've spent my fair share of time drooling over the promotional videos for products like Solidworks or Zuken CR8000, but I'm still always excited by what can be accomplished with cheap and mainstream tools like DipTrace and Sketchup.

Today I started to put together the first stages of the design I am planning to use for my Raspberry Pi shield.

There's no electrical schematic yet, but I've chosen some of the important components and with about 4 hours of dithering about with dimensions and feature snapping and such, a fair amount of the groundwork was done...

SketchUp was first used to create a 3D model of the RasPi with accurate dimensions (I hope!).  Then this was used as a template from which a basic PCB outline for the shield was generated, again with dimensions that should correspond to the RasPi anatomy.

Then it was over to DipTrace to start preliminary work on the Schematic and Layout designs.  The second picture here shows the Layout with the four Propeller QFP chips (P8X32A-Q44) laid out in a vaguely sensible location on the shield.  In the middle is the DS1077 programmable oscillator which (if all plans go well) will provide a solid clock signal for all four Propeller chips to operate from.  I've not yet decided on how I' going to organise EEPROMs on this board yet.  I'll probably provide two 64KB eeproms shared between the four Propellers.  As for extra RAM, I'll am thinking about using some fast SPI SRAM chips (one per Propeller) to supplement the on-silicon RAM in each chip.

There's a huge amount of work to be done before I get any prototypes made but that's all part of the fun.

But this is all fairly trivial to do even with modest tools within reach of the serious hobbyist.  But that's not to say I won't still be pining for a copy of Solidworks to drop through my letterbox one day :)

Rule 2: follow all the rules.

For once I followed the First Rule of Electronics Troubleshooting (FRET):

1. Check your voltages.

(from Leonardo da Vinci - "Reprehendo Tuum Voltages", quote from unpublished notes, volume 19 chapter 11)

While trying to integrate the DS1077 programmable oscillator into my RasPi/Propeller prototype accessory, I noticed that I was getting a very glitchy IO signal on an LED I was using for debugging.  I was using the LED to signal when an event had happened in the I2C comms process.  This showed up when I attached my logic analyser to the IO pin connected to the LED.  There was an intermittent fault on that line that could not be a result of the PASM code running on the Propeller.

Hmm.  What to do?  What do we know about the circuit?  We know that the RasPi behaves itself very well when the prototype board isn't attached, and when it is attached, the RasPi continues to function correctly.  This means the problem is internal to the prototype board and seems not to cause the RasPi any problems.

That doesn't exonerate the RasPi of blame though.  Nosiree.  A poke with a multimeter tells me that the "5V" rail on the RasPi is sitting at a very stable but somewhat sickly 4.72 volts.

Next I checked the Propeller's supply voltage - which is the output of the LD33V LDO voltage regulator.  This was found to be a nonchalant and debonnaire 3.3 volts - perfect.

Onwards to the DS1077 which runs directly from the "5V" rail on the RasPi.  I have to confess ignorance here.  I foolishly neglected to verify the quality of the "5V" rail on the RasPi board.  Turns out that the "5V" rail is simply hard-wired to the power input which in my case comes directly from a Kindle charger wall-wart.

The DS1077 datasheet states that the acceptable range of VCC is between 4.75 and 5.25.  I think that's the culprit right there.  I'm running that DS1077 chip from a weak VCC source which is barely grazing the acceptable range.

Interesting.  So hopefully if I can provide a stiffer 5V supply for the RasPi (by using a wall wart with a greater current range), I can do away with these glitches in other parts of the system.  This also indicates that I can't easily run 5V devices off the 5V rail of the RasPi necessarily.

For the final design I'll need to use some additional circuitry to filter noise on the 5V rail into the prototype board!  Ferrites and caps will help in that regard.

We live and learm :).

Musings on dynamic clocking of microcontrollers

Before I embark on a voluminous treatise on the nuances of on-the-fly clock signal modulation I had better think about the potential pitfalls that might arise.

Assuming that a DS1077 Programmable Oscillator is hooked up to a Propeller P8X32A microcontroller so as to have the Propeller take it's external clock directly from the DS1077, is it possible to write code in such a way that the system becomes bricked?

Yes, in certain circumstances.  The DS1077 has two enable pins which, if configured correctly, can shut off the outgoing clock pulses from both OUT0 and OUT1 pins.  If this happens while the microcontroller is still using the DS1077 as it's clock source, the program will halt completely.  In the case of the Propeller, all 8 cogs and the Hub will all cease activity altogether and will therefore be unable to communicate with the rest of the system.  The only way to get out of this is to put some simple safeguards in there...

Safeguard 1:  Have the Propeller perform it's initialisation code using it's own internal silicon clock.  This will ensure that the DS1077 chip will always be contactable after a reset or a power-cycle.

Safeguard 2: Force the DS1077 to be running all the time.  This can be done by choosing sensible configuration settings and then tying the two enable pins (CTRL0 and CTRL1) directly to GND.

Safeguard 3: When using I2C to reconfigure the DS1077, always make your microcontroller change over to it's internal oscillator BEFORE starting the I2C sequence.  Then allow a sensible amount of time (a couple of microseconds is probably enough) to elapse before switching back to using the external clock source again.  This guarantees that your communications with the DS1077 are always glitch-free and reliable.

Something to remember: changing the clock speed of your circuit programmatically requires your microcontroller firmware to be a bit more sophisticated with it's handling of things like fixed duration waits or delays.  Waiting 1,000,000 clock cycles at 16KHz will take more than one minute to elapse, whereas waiting 1,000,000 clock cycles at 133MHz will take 7.5 milliseconds!  Consequently it is vitally important to remember what clock speed you're running at at any given moment.  Again, a fail-safe method of being absolutely sure that you have a known clock rate is to fall back on using your microcontroller's internal oscillator.

Success - RasPi programs a Propeller!

I've managed to get my RasPi module to program a Propeller and it's EEPROM using my "pushprop" program compiled and running on the RasPi under Raspbian.

This was an interesting part of the project, as there were some obstacles due to the nature of the RasPi's architecture.  pushprop can actually program the Propeller over either the 0.1" pin header connection to the accessory board I'm building - or - it can program it over the normal USB/FTDI (e.g. "PropPlug") connection.

Since the RasPi hasn't got a dedicated DTR pin on it's GPIO header block, I had to commandeer GPIO_0 and wire it directly to the RESn pin on the Propeller (there's also a pullup resistor on that line to allow the Propeller to operate even when the RasPi isn't connected).

Now I can program the Propeller chip without using any cables, the next step is to hook up the DS1077.

Prototype Propeller Accessory for RasPi

The prototype for my Propeller accessory is pretty much finished now.  The final one will be a proper PCB with hopefully FOUR Propeller chips on it!  I'm using one for this prototype to ensure that the basics are working such as I2C and bidirectional serial comms between the Pi and the Prop.

The Prop Plug is only temporary and allows me to get an extra debug channel into the top board while debugging code running on the Pi.

This board has 24 GPI pins available to the user.  The final build might have as many as 64!

Next I'll be adding the code that lets me talk to the Prop over the Pi's GPIO pins using Serial.  I'll need to find way to drive an extra pin to bring the Prop out of reset at the right time during comms.

Then, after that I'll be hooking up the DS1077 chip (with 3v3 / 5v level shifters) and making the Propeller dynamically change it's clock speed!

RasPi R2 Pinout

http://iqjar.com/jar/connecting-to-the-gpio-pins-of-the-raspberry-pi/

A handy link for future reference :)

DS1077 + Arduino

I've finally had a chance to get around to playing with the DS1077 configurable oscillator!

The circuit to get it working is very simple, just hook up the Ardiono as the I2C master, I used a 10K pullup resistor on both the SCL and SDA lines.  I tied CTR0 and CTR1 on the DS1077 to GND to enable the chip all the time.  For the following video, I put the scope probe onto the OUT1 pin...

You'll see some substantial "ringing" on that scope trace in the video.  Ignore that :) it's because I'm sending fast rising and falling edges through a cheap breadboard, cheap hook-up wires, and a very cheap croc-clip oscilloscope probe.  This chip produces rather good quality square waves signals when under ideal circumstances.  This video simple demonstrates the nice smooth way that the frequency can be varied by sending I2C commands to the chip.

Here's a quick schematic for that hastily breadboarded demo circuit...

I like the pinout of this chip, as it clearly demonstrates deference to signal integrity design considerations for the PCB designer.  Notice how the VCC and GND pins are side by side.  That makes it very convenient to place a decoupling cap right on those lines as close to the chip as possible.

And of course here's the obligatory Arduino source code to drive the chip.  This is the code used for the video.  All it does is run through the entire frequency range supported by this chip.  Hopefully this will be of some help to fellow blogger Eldon (http://wa0uwh.blogspot.com/)who showed some interest in this chip from my previous post on the topic.

#include 

const int ds_address = 0xB0 >> 1; //DS1077 default address

#define MUX_HI_PDN1_BIT (B01000000)
#define MUX_HI_PDN0_BIT (B00100000)
#define MUX_HI_SEL0_BIT (B00010000)
#define MUX_HI_EN0_BIT  (B00001000)
#define MUX_HI_0M1_BIT  (B00000100)
#define MUX_HI_0M0_BIT  (B00000010)
#define MUX_HI_1M1_BIT  (B00000001)

#define MUX_LO_1M0_BIT             (B10000000)
#define MUX_LO_DIV1_BIT            (B01000000)

#define BIT_ON (0xff)
#define BIT_OFF (0x00)


void setup()
{
  Wire.begin();
}

void loop()
{
  long i;
  for(i = 0 ; i <= 1025 ; i+=1)
  {
    i2c_write(ds_address, 0x02, 
      ( 0
        | (MUX_HI_PDN1_BIT & BIT_OFF)
        | (MUX_HI_PDN0_BIT & BIT_OFF)
        | (MUX_HI_SEL0_BIT & BIT_ON)
        | (MUX_HI_EN0_BIT  & BIT_ON)
        | (MUX_HI_0M1_BIT  & BIT_ON)
        | (MUX_HI_0M0_BIT  & BIT_ON)
        | (MUX_HI_1M1_BIT  & BIT_ON)
      )
      ,
      ( 0
        | (MUX_LO_1M0_BIT  & BIT_ON)
        | (MUX_LO_DIV1_BIT & BIT_OFF)
      )
    ); //mux
    delayMicroseconds(100);    
    
    i2c_write(ds_address, 0x01, (i >> 2), (i << 6) & 0xC0); //div
    delayMicroseconds(100);
    i2c_write(ds_address, 0x3F);
    
    delayMicroseconds(10000 - i);
  }  
}

void i2c_write(int device, byte address) {
     Wire.beginTransmission(device); //start transmission to device 
     Wire.write(address);        // send register address
     Wire.endTransmission(); //end transmission
}

void i2c_write(int device, byte address, byte val1) {
     Wire.beginTransmission(device); //start transmission to device 
     Wire.write(address);        // send register address
     Wire.write(val1);        // send value to write
     Wire.endTransmission(); //end transmission
}

void i2c_write(int device, byte address, byte val1, byte val2) {
     Wire.beginTransmission(device); //start transmission to device 
     Wire.write(address);        // send register address
     Wire.write(val1);        // send value to write
     Wire.write(val2);        // send value to write
     Wire.endTransmission(); //end transmission
}

This chip lets you output a 50% duty cycle square wave at any frequency given by 133,000,000 divided by any number between 1 and 1025 inclusive.  This divider is selected by sending a short I2C sequence to the chip from whatever microcontroller you prefer.  I'm using an Arduino here because there was some code easily available for it.  For my final purposes I'll be using a P8X32A Propeller to drive this chip.

This is a fun chip to mess with and has some substantial benefits for the advanced Parallax Propeller user, since this will let you experiment with letting the Propeller chip overclock itself on the fly!  Granular clock management and tuning is something I'm interested in experimenting in with the Prop and this chip will be a great way to do it!

I think this chip will also be of use to Ham radio enthusiasts because of it's frequency modulation abilities.  Although I suspect that it's stepped frequency brackets are a bit of a limitation for some of the really advanced shenanigans of the Ham community, this would be useful for some kind of carrier modulation or FDM projects.

Anyway, sorry for the long-winded post - hope you find this useful or at least interesting.

Wardy.

RasPi Model

LINK: RasPi B.skp

Threw this SketchUp file together as part of my latest hardware project.  There are some additional construction lines left in for convenience for those wishing to align components to the connectors and mounting holes on the RasPi board.

I made every effort to ensure that the model is dimensionally as accurately proportioned as possible.  If in doubt check against your own RasPi to confirm.

Enjoy.

Bodge of the week

Today's mail bestowed upon me a precious Maxim part (you may well gasp), a DS1077 to be particular.  A programmable oscillator for use on an I2C bus.  I'm hoping to use this chip in a new PCB design I'm working on and so I wanted to get some results before Monday.  Hmm, that means there's no time to order a breakout board (lack of foresight while I was purchasing said IC).  Dang,what is one to do?

Then I remembered :)

Bodge^(TM)*

In a hurry to complete a project?

Too impatient to wait for the postman?

Too much of a tight-wad to buy a proper solution?

...

Then why not try a Bodge?

Yes, Bodge is a quick and cheap alternative to doing things properly!  Eager to risk frying a relatively difficult to obtain Maxim part by hamfistedly prodding away at it for half an hour with pliers, tin snips and a cheap soldering iron?  Then Bodge is for you!!

No more pacing up and down the workshop waiting for a properly designed and manufactured breakout board to arrive, which would no doubt have cost almost as much as the chip itself!!!  No, just dive in and solder on a bunch of random wires to it and just assume everything will go according to plan!!!!

A Bodge representative is in your area now!!!!!

Hey, take a look at this demonstration!!!!!!

*Terms and conditions apply.  Bodge should not be used in automotive, industrial, life-support, aerospace, military or marine applications.  Bodge should not be used by the elderly, the infirm or the pregnant.  Bodge is probably not really a trademark as far as I know.  It would be awesome if it was though.  Availability: dwindling.  My hovercraft is full of eels.