View Single Post
  #1   Spotlight this post!  
Unread 09-01-2007, 11:16
dcbrown dcbrown is offline
Registered User
AKA: Bud
no team
Team Role: Mentor
 
Join Date: Jan 2005
Rookie Year: 2005
Location: Hollis,NH
Posts: 236
dcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud ofdcbrown has much to be proud of
Re: SPI Port on Robot Controller

Dave,

All the stuff I've been doing is bi-directional so I'm constrained by the input delay on paired i/o lines. So yes, if you are only using SDO and don't care about SDI on the SPI interface then I guess you can quick clock just to get the shifted data out. I'd still put a scope on the line. I never got my stuff to work cleanly and looking at the output pulses guessed that it was becuase they looked more like slow rise sine waves than digital data/clock signals.

Might get away with 2t, which is still ~13%/86% levels?, if using schmitt trigger buffers (why did I say schottky?! before) to clean up the pulses.

Line 1-6 are least filtered because they are the external interrupts lines also. So using them up could mean other issues pop up.

I was looking at using a small dual port ram and address blocking. Each co-processor would have their own dual-port ram chip but only part of the address space would be decoded - say 16 bytes. They would have their data lines tied together so the robot controller can access all the data but wouldn't know it was reading chunks from different chips. I was using the analog lines for the interface because that was one of the things I wanted to off-load to another processor anyway. Still bit banging, but bit banging bytes! At least that's the theory.

Bud