Electronics > Projects, Designs, and Technical Stuff
Best mechanism for generating test patterns on 110 GPIO lines?
(1/2) > >>
alanambrose:
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
artag:
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.
rstofer:
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 at

https://www.pjrc.com/teensy/rawhid.html

The 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.


alanambrose:
>>> 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
daqq:
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?
Navigation
Message Index
Next page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod