FYI,
what is my project, which building blocks (features) do I need...?
I need a network based SPI adapter. It is used for pre- and post-silicon verification (test chips, as "Device Under Test" (DUT)).
Python scripts running on a host PC, it should fire SPI transactions, perform test cases, drain and evaluate data (from external chip connected as DUT), send results to host.
What is "DualSPIder"?
Actually, I want to compensate "round trip delays" on SPI:
The SPI cable can be long, e.g. the DUT sits in an oven, heated up to 85C and more, but I do not want to place entire MCU board also into the oven ("just" to keep SPI cable short).
It would fail and MCU would be grilled on high temperatures, MCU would be dead before my DUT.
SPI is "synchronous": the sampling clock is provided (and used as reference for Rx) by the MCU:
Any longer cable results in bit errors because the Rx signal (MISO) comes now too late (MISO is delayed but not SCLK: MCU internal).
Therefore, 'if possible':
Have one unidirectional SPI Tx (as master). feed back the SCLK signal from far end (DUT) and use a second SPI Rx (also unidirectional) to sample responses (as slave).
So, one Tx SPI (master), one Rx SPI (slave), and the SCLK signal is delayed ("reflected") in the same way as MISO due to the cable length.
What do I need (building blocks)?
Two SPI interfaces - master + slave:
One SPI Tx (master), if possible also a second SPI as Rx (slave) = "DualSPIder"
(not sure: Teensy 4.1 was not able to do).
Network (ETH):
used for:
- MCU internal web browser (user can fire commands from a web page interface, no driver/SW installation)
- Python network access: a Python script on host can fire commands (via TCP/IP) and get results (also Matlab as host script engine)
- UDP unidirectional data: when data is drained - send it to the host
- TFTP: I need test scripts loaded and executed on MCU: transfer files to external storage (here it will be USB memory device, SD card not available)
FreeRTOS:
I will have several tasks (threads), e.g. GPIO INT(s), TFTP, ETH (web browser plus host scripts), UART command line.
RTOS is a "must" to have, to organize tasks and give them a priority (e.g. GPIO INT is highest, because "real time" actions to do).
External Memory:
Test scripts ("Pico-C", see following), have to be transferred and stored on SD card not available here, so USB memory stick.
So, USB MSC device, USB memory stick on user USB host port, with FatFS, is needed.
Script Engine:
I want to go with "Pico-C", a C-code interpreter, interactive, interpreted, in order to extend the system (without to recompile and flash entire FW).
My users should be able to program 'what a GPIO INT handler should do' (e.g. drain data via SPI, decode data, send results to host...).
I know, there is MicroPython, Lura ... but I want to go with a "C-code language". Why?
My users write test code in UVM (Universal Verification Modelling), SystemVerilog (which is like C++). I want to reuse test scripts, configuration scripts ... which look like C/C++ code.
So, "PIco-C" seems to be the best option, because same language as used by my users, easy to extend "Pico-C" by UVM/System Verilog "code" (functions needed) - I did already.
This "Pico-C" needs a permanent script storage (here it will be USB memory stick, with TFTP support to transfer files to/from it). And pretty large space needed (test cases, config files...).
Also the need for available code space (flash memory/ITCM) to consider just for the "Pico-C" code (and data).
GPIO Interrupts:
External GPIO interrupts have to be fast as possible ("real-time"). If one happens, all the actions to do - and it should be programmable "what to do" ("Pico-C"),
must happen in "real-time" (as fast as possible).
Also, the ETH network transfer, e.g. via UDP send the results of a processed GPIO INT handler, has to be fast (high network throughput).
Therefore, the 1Gpbs ETH port should be used (plus FreeeRTOS task to send).
A speed limitation here would conflict with the DUT performance: if every 1ms (1KHz) a huge packet of data (assume 2KB) has to be drained from DUT - it should be sent to host PC without a loss of network packets
(using UART, even it would be a faster USB VCP UART - is out of scope here).
UART and network in parallel:
The main access will be via network (a host Python script, via TCP/IP plus UDP for data).
But the board (FW) has to provide a backdoor, via UART (as USB-C VCP UART). It is used for debug test cases, to intervene from a user, to do all manually, to try something manually...
Flash for SYSCFG:
I want to have system config parameters in non-volatile storage (flash), e.g. for SPI clock speed, IP address of MCU.
Read SPI flash SYSCFG on startup, update/write via command line...
What will not be used?
I will not make use of (and potentially not getting familiar with):
- PDM MICs on board (maybe for a leisure time project)
- the DCIM camera interface and SW stack (maybe for a leisure time project - working on an "airplane tracker" via MIC and Camera...)
- WiFi: too slow, not "allowed" in labs, too complicated to connect to a company network
- BT: no need for it
- AI, ML...: I would like to use TensorFlow, AI, ML... but no idea yet for what (what to automate/improve with it when it comes to testing DUT as external chips, based on their spec. and HW features to verify)
So, my next steps on MaaXBoard-RT:
- bring-up ETH: network, web server inside MCU, TCP/IP command access (from host Python), UDP for data to host
- bring-up USB Memory Host (for an USB stick), add TFTP to transfer from/to it
- "DualSPIder": SPI Tx plus SPI Rx - I have to see: based on Teensy 4.1: SPI Rx is not fast enough on MCU (I need 40 Mbps) - potentially the same issue
- "Pico-C": the needed code space, data space, USB memory as script storage
- GPIO INT(s) (in combination with FreeRTOS, as tasks/threads handlers)
- User GPIO: as input/output, on/from DUT
I try to keep you posted and to provide project files (via GitHub).
Maybe pieces/.experiences of/with my project might help you as well.
