Electronics > Projects, Designs, and Technical Stuff
Best mechanism for generating test patterns on 110 GPIO lines?
<< < (2/2)
alanambrose:
>>> edit: You don't need to run the full speed during the test, or do you?

Probably not at this stage.

Yes, I see some stuff re C#, SPI, FTDI chips and something they called MPSSE e.g.

https://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf

https://www.ftdichip.com/Support/SoftwareExamples/MPSSE/FTCSPI.htm

https://learn.adafruit.com/circuitpython-on-any-computer-with-ft232h/pinouts

Alan
alanambrose:
Also BusPirate is a candidate:

http://dangerousprototypes.com/docs/Bus_Pirate_Edu_kit_partlist

e.g.

SPI>[0x00 0x40]]<<<move the potentiometer wiper to the 64 (Mid-scale 0x040) position
/CS ENABLED
WRITE: 0x00
WRITE: 0x40
/CS DISABLED
alanambrose:
OK I used the FT232H for this in the end. It works, kind of. Here are my notes:

(1) it's a bit of a PITA in use and the api design leaves a lot to be desired.
(2) for instance, I chose to use a mode where I used their SPI API and the byte-wide 'ACBUS' for 8x CS lines. I had to juggle the CS lines myself and fiddle with the non-intuitive FTDI API to get the two SPI protocols the right way up.
(3) The GPIO for the CS is a bit slow and makes the SPI transactions look a bit odd.
(4) The designers obviously didn't consider this simple 'use-case', so for instance, you can't just flip one CS GPIO line but only all 8 at a time.
(5) So a lot of round and round with a DSLOGIC looking at the actual FT232H output and fiddling with the FTDI API to get it right.
(6) The fastest SPI possible this way seems to be 2 MHz.
(7) Oh and there is a bit of a FTDI API version maze. I ended up using the 'MPSSELight-master' codebase which was OK but not great.

However, I wrote the test scripts I needed, debugged my assembly and I'm done.

I'm not sure I would use this method again though. I see that the Analog Discovery 2 and also some logic analysers have bit pattern replay which might be fine. Or it might have been quicker and less frustrating to write my own uP tool taking PC serial and outputting parameterised SPI. I probably could have written that tool in a thorough way in the time I spent with the FTDI stuff.

Alan
Berni:
Well LPT ports are kind of like GPIO for PCs, but you would need ridiculously many of them to get this many lines.

So i think you are probably best off making some custom hardware to do this. Take some sort of MCU or FPGA dev board, run UART into that and have it twiddle the lines for you on command.

I made my own little solution for this where i put a USB to UART and a PIC MCU into a box to provide 8 GPIO lines that could be written and read trough a simple serial protocol. Any sort of protocol would then just be bit banged on it on the PC side. It also had the ability to buffer a small amount of data, so that you could for example bitbang SPI with perfect timings within the transfer.
DaJMasta:
What about an FPGA development board?  Not enough hardware SPIs, but you can probably get some code for low speed soft-spi connections that would run fine given the nature of FPGAs.  Tons of I/O and much of it is often broken out on development boards too.



Otherwise, it's much more expensive, but you can get logic analyzers with wide pattern generators.  The older and more affordable 16520A doesn't really have enough outputs to be viable, but the 16720A has 48 outputs and can be fully synchronized and configured with other cards, so a few of those in a mainframe would give you a very flexible and reconfigurable system to do this sort of work.
Navigation
Message Index
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod