Best mechanism for generating test patterns on 110 GPIO lines? - Page 1
Forum section: electronics / projects

author: alanambrose
author_rank: Frequent Contributor
timestamp: November 19, 2019, 01:22:41 pm
content: Hi,I need to run some tests on an assembly of mine that takes ~110-off 3.3V GPIO lines (all are inputs to the assembly) - actually 12 off 3-line SPI serial, 12 off 2-way address lines and 25-off each row/column select lines. All lowish speed, say max 10-100 KHz (the exact max speed will depend on how fast other assemblies can be run). It's not completely obviously how slow the SPI will run, but it'll run at up to 40 MHz. The whole thing will be eventually driven by a FPGA, but I would like to test preferably with PC code. I guess I could probably test each channel separately meaning I would need ~55 lines min but it would be helpful to test everything at once.Does anyone have a favourite go-to solution for that kind of test set-up?Alan

author: artag
author_rank: Super Contributor
timestamp: November 19, 2019, 08:01:35 pm
content: PC code isn't the best place to start : there's no standardisation for any SPI busses and so you have to write for some sort of adapter.Normally I would write high-level code with a customised HAL to translate to SPI at a low level, and then rewrite the HAL for real hardware. But there isn't much advantage to you doing that as you don't want to finish up with the same high level code, you want to go to an FPGA (unless there's a still higher level that controls the operating conditions of the FPGA), so I'd recommend you simply use something with a very straightforward SPI interface.I would start with some sort of microcontroller. A small arduino is likely to have too little memory for the number of outputs but a larger one (eg mega, or a more recent ARM-based device) may do. If you're comfortable with the programming environments for Beaglebone or Raspberry Pi then that would probably be simpler still and would allow you to prototype at a scripting level as long as you don't care about speed for this version.I don't know any devices with 12 SPI busses though, so you'll probably have to use software SPI. This would usually be easier on a microcontroller rather than a Pi.

author: rstofer
author_rank: Super Contributor
timestamp: November 20, 2019, 12:03:00 am
content: Thinking about the SPI: Do all 12 instances need to run concurrently or can there be just one SPI channel and 12 CS* lines?I think you should spend a good deal of time considering how many things need to happen at once. SPI can still be fast and some uCs have multiple SPI gadgets but nothing like 12.OK, how about MANY uCs? They all talk over, say, RS485 to a host like a Pi (or PC). Each has an address so the Pi can tell each uC what to do next and delay telling it to start until setup is complete. Then the Pi sends some weird packet (like with a broadcast address) and each uC starts doing as instructed. One advantage: If the uC is supposed to do what it did the last time (same bit pattern), that information doesn't need to be resent from the Pi.Maybe spend some time at the FTDI site and look over what they can do with USB.USB HID is easy to implement and there are 512 bits in a packet. It's easy on the PC end as well. Look athttps://www.pjrc.com/teensy/rawhid.htmlThe new Teensy 4.0 is blazing fast!So, you have one RawHid gadget taking care of all discrete IO, 12 FTDI gadgets taking care of USB->SPI and whatever else. It would be better if you could use fewer SPI gadgets and more CS* lines.The downside is you can only guarantee 1000 packets per second. That might be too slow.

author: alanambrose
author_rank: Frequent Contributor
timestamp: November 20, 2019, 09:34:05 pm
content: >>> Do all 12 instances need to run concurrently or can there be just one SPI channel and 12 CS* lines?Yes, you're right, the latter will do.I looked at the 64-channel DO Keysight DAQ and I guess a couple of those would do it. I think it may just be easier here to roll-my-own test set-up.Alan

author: daqq
author_rank: Super Contributor
timestamp: November 20, 2019, 10:04:27 pm
content: I once needed something similar, generate slow data for 16 lines from a PC, cobbled together quickly. I used an FT232 something, used the D2XX libraries, hooked the whole thing with .NET and used some of the pins as GPIOs, that I connected to a shift register. It wasn't fast, but it got the job done. There are much faster FTDI devices (FIFOs and similar) so you can easily generate fast data streams that you can feed into a string of 74HC595 or similar. Make a quick PCB and you're done.edit: You don't need to run the full speed during the test, or do you?

author: alanambrose
author_rank: Frequent Contributor
timestamp: November 29, 2019, 02:32:25 pm
content: >>> 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.pdfhttps://www.ftdichip.com/Support/SoftwareExamples/MPSSE/FTCSPI.htmhttps://learn.adafruit.com/circuitpython-on-any-computer-with-ft232h/pinoutsAlan

author: alanambrose
author_rank: Frequent Contributor
timestamp: November 29, 2019, 03:22:50 pm
content: Also BusPirate is a candidate:http://dangerousprototypes.com/docs/Bus_Pirate_Edu_kit_partliste.g.SPI>[0x00 0x40]]<<<move the potentiometer wiper to the 64 (Mid-scale 0x040) position/CS ENABLEDWRITE: 0x00WRITE: 0x40/CS DISABLED

author: alanambrose
author_rank: Frequent Contributor
timestamp: December 20, 2019, 03:14:48 pm
content: 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

author: Berni
author_rank: Super Contributor
timestamp: December 20, 2019, 03:43:34 pm
content: 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.

author: DaJMasta
author_rank: Super Contributor
timestamp: December 20, 2019, 04:08:41 pm
content: 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.