I’m trying to implement an SPI slave interface with DMA on the BW16 module.
I am using the standard SDK.
I can see the RTL8720DN does not have SPI0, and the external SPI1 pins are SPI master only.
Can I use the USI SPI port on this module?
PA25 (MOSI), PA26 (MISO), PA30 (CLS) are available on the BW16, but not PA28 (CS).
I am thinking of doing it like this:
external interrupt on another GPIO pin, which will become a software chip select
when the pin is driven low, enable the USI SPI port and do the transaction
when the pin goes high, disable USI SPI port
Can the USI SPI port handle this kind of software chip select? (some STM32 micros have a register setting for software CS.)
Also, where can I find a list of what peripheral functions are mapped to each pin? It is not covered in the data sheet or anywhere else that I can find. Just some comments in some examples.
Finally, the BW16 data sheet has a very blurry schematic in it. Is there a proper clear version available?
I need to see the label on PA28, to see if there will be a conflict on the CS pin.
Hi. Thanks for the answers. Its not quite what I am after though:
I need the schematic of the B&T module. That is the schematic of the PCB that the B&T module is attached to
I was hoping for an official Realtek pin map table. That pin map doesn’t cover the USI SPI port, and it doesn’t go into detail about which SPI port that is. I know now its SPI1, but there should be some document that shows all possible peripherals for all pins, like other microcontrollers have
On the blurry schematic of this Ai-Thinker BW16-Kit Specification, pin PA28 is labeled RREF_PA_28. When configured as an USB pin along with HSDM_PA_25 and HSDP_PA_26, it is an input aimed at connecting an external reference resistor for USB analog (see UM0401 RTL872xD Datasheet - click “Datasheet” in the “Ameba RTL8722DM Board” section - login required).
Unfortunately PA28 is not available outside the BW16 module (see Table 2.2 Pin function definition in the BW16 specification above), contrary to what was stated in the B&T BW16 Specification V1.0, where BW16 pin 6 was wrongly assigned to PA28. However this mistake was corrected in the B&T BW16 Specification V1.1, where BW16 pin 6 is now correctly assigned to PA27. As I use this pin routinely in my own projects, I can confirm that it is really PA27, and not PA28.
Do you know if the USI SPI port can support a software chip select?
If I enable this peripheral in slave mode, and the hardware chip select pin PA28 is tied low (as it is on B&T module), will the peripheral accept the master clock and do the transaction? Or is it looking for a falling edge after being enabled?
Maybe USI_SSI_SetSSTogglePhase(port, USI_SPI_SS_NOT_TOGGLE) can help?
You want to read carefully UM0400 - Ameba-D User Manual, Chapter 19 - Serial Peripheral Interface. Section 19.2.3.2 Serial-Slave Mode states that “the slave remains in an idle state until selected by the bus master” and “the transfer begins when the SPI slave is selected by a serial-master device”, i.e., when the SPI master activates SPI_CS. Therefore without any access to PA28, I am afraid there is no chance you can do anything with port SPI0. The fact is that as there is no frame structure in SPI (not even any byte delimitation), SPI_CS is the only information the slave receiver has available to start shifting bits inwards, organize them in bytes, and finally count the received bytes at the end of the transaction. But maybe you can try to play with the SSI Enable register (SSIENR) before giving up, and discover some undocumented behaviour ! Let me know…
I actually also first intended to use the BW16 as an SPI slave (the master being an ESP32 and/or Raspberry Pi), and gave up for the reason above. I now use it as an SPI master with the other device as a slave, and just added a Handshake line from slave to master to regulate the traffic. Works very well at 8Mbits/s, I did not attempt to go faster because this was sufficient for my needs.
[Edit] Suppose that you will succeed to let the SPI0 work with a software Chip Select, as intended in your first post. This means that the delay between the assertion of this CS and your slave receiver being ready will be essentially unpredictable, and probably very long compared to the SPI clock speed. How will you let the SPI master know that the receiver is ready, and have the master wait until then to start issuing the clock? Clock generation is usually a hardware function in SPI masters, and the clock starts automatically 1.5 clock period after CS being asserted by the master. Therefore you will need an extra line to be used as a software CS, and yet another line from slave to master to signal that the slave is ready. Starts to make a lot of lines for a simple SPI link…
