Author Topic: Best mechanism for generating test patterns on 110 GPIO lines?  (Read 1382 times)

0 Members and 2 Guests are viewing this topic.

Offline alanambroseTopic starter

  • Frequent Contributor
  • **
  • Posts: 377
  • Country: gb
Best mechanism for generating test patterns on 110 GPIO lines?
« on: November 19, 2019, 01:22:41 pm »
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
“A foolish consistency is the hobgoblin of little minds"
 

Offline artag

  • Super Contributor
  • ***
  • Posts: 1284
  • Country: gb
Re: Best mechanism for generating test patterns on 110 GPIO lines?
« Reply #1 on: November 19, 2019, 08:01:35 pm »
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.
« Last Edit: November 19, 2019, 08:03:15 pm by artag »
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9964
  • Country: us
Re: Best mechanism for generating test patterns on 110 GPIO lines?
« Reply #2 on: November 20, 2019, 12:03:00 am »
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.


« Last Edit: November 20, 2019, 12:05:38 am by rstofer »
 

Offline alanambroseTopic starter

  • Frequent Contributor
  • **
  • Posts: 377
  • Country: gb
Re: Best mechanism for generating test patterns on 110 GPIO lines?
« Reply #3 on: November 20, 2019, 09:34:05 pm »
>>> 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
“A foolish consistency is the hobgoblin of little minds"
 

Offline daqq

  • Super Contributor
  • ***
  • Posts: 2321
  • Country: sk
    • My site
Re: Best mechanism for generating test patterns on 110 GPIO lines?
« Reply #4 on: November 20, 2019, 10:04:27 pm »
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?
Believe it or not, pointy haired people do exist!
+++Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
 

Offline alanambroseTopic starter

  • Frequent Contributor
  • **
  • Posts: 377
  • Country: gb
Re: Best mechanism for generating test patterns on 110 GPIO lines?
« Reply #5 on: November 29, 2019, 02:32:25 pm »
>>> 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
« Last Edit: November 29, 2019, 02:46:55 pm by alanambrose »
“A foolish consistency is the hobgoblin of little minds"
 

Offline alanambroseTopic starter

  • Frequent Contributor
  • **
  • Posts: 377
  • Country: gb
Re: Best mechanism for generating test patterns on 110 GPIO lines?
« Reply #6 on: November 29, 2019, 03:22:50 pm »
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
“A foolish consistency is the hobgoblin of little minds"
 

Offline alanambroseTopic starter

  • Frequent Contributor
  • **
  • Posts: 377
  • Country: gb
Re: Best mechanism for generating test patterns on 110 GPIO lines?
« Reply #7 on: December 20, 2019, 03:14:48 pm »
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
“A foolish consistency is the hobgoblin of little minds"
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 5050
  • Country: si
Re: Best mechanism for generating test patterns on 110 GPIO lines?
« Reply #8 on: December 20, 2019, 03:43:34 pm »
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.
 

Online DaJMasta

  • Super Contributor
  • ***
  • Posts: 2393
  • Country: us
    • medpants.com
Re: Best mechanism for generating test patterns on 110 GPIO lines?
« Reply #9 on: December 20, 2019, 04:08:41 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf