I am trying to use the rpi pico as a I2C slave capable of receiving and sending multiples bytes using interrupts.
Using the rpi pico as a I2C slave/memory with micropython is possible. (https://forums.raspberrypi.com/viewtopic.php?t=302978).
I am now trying to implement reading from the pico using interrupt.
According to the pico documentation, when the master tries to read data from the pico, the RD_REQ is set to 1. Then the pico hold the scl to 1 until and IRQ handler write data in the IC_DATA_CMD register and disable the interrupt. (https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf#page=481)
In the documentation the interrupts sources are defined as I2C0_IRQ or I2C1_IRQ (https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf#page=60)
So far, I only found how to create interrupt handle linked to specific pin. I do not understand how to link the callback function to the interrupt source or the RD_REQ bit.
Related
I'm using PySerial to communicate to some devices over RS485 multi-drop. I am bit-banging the DE signal to enable transmission before sending a packet and releasing it at the end.
The problem is that the time for release varies, especially under processor load, and the responses from the devices get clobbered (and aren't received).
I know PySerial has RS485 support, but from everything I've read about my embedded SBC (NXP iMX6 Dual), the RTS signal is not available on the GPIO connector. I just have arbitrary GPIO to use.
Is there a way to map an arbitrary GPIO signal to the RTS functionality so that the Linux tty drivers will assert/deassert my desired GPIO pin?
The following statement gives me some hope (https://www.kernel.org/doc/html/v4.17/driver-api/gpio/drivers-on-gpio.html)
"""
... there are special GPIO drivers in subsystems like ... the TTY serial subsystem to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines.
"""
There seems to be some kind of support for in the tty driver for /dev/ttyimxN devices.
https://github.com/torvalds/linux/blob/v4.14/drivers/tty/serial/serial_mctrl_gpio.h
https://github.com/torvalds/linux/blob/v4.14/drivers/tty/serial/imx.c
unsigned int have_rtsgpio:1;
But how can I set this up with PySerial?
How can I specify the GPIO port to use (if at all)?
Thanks for any help !!
EDIT
I've found info in the kernel sources that match the kernel on my board. This describes how to specify the gpio for modem control emulation (software control, instead of hardware control).
https://github.com/ADVANTECH-Corp/linux-imx/blob/adv_4.14.98_2.0.0_ga/Documentation/devicetree/bindings/serial/serial.txt
So it seems possible by changing the device tree sources and making a new device tree blob for my system.
This should all be independent of pyserial.
I'm not sure if this can be set/overridden at runtime with an ioctl, which would be handy (instead of having to muck around with kernel sources and building device tree blobs, etc).
I am wondering if there is a user-definable, built-in ISR function in the HAL library that triggers as soon as a byte is received in the SPIx Rx buffer on STM32L4xx MCU? For instance, as a startup test, I would like to send one byte (0xBC) from a Master STM32L452 nucleo board via SPI2 to a Slave STM32L452 nucleo board. Once the Slave board receives the byte, it flashes LED2, and transmits a different byte (0xCD) back to the Master. Once the Master receives the byte, it flashes LED2 as confirmation. I have initialized both boards as Master/Slave, enabled DMA and global interrupts, 8 bits per transfer using MXcube. I can achieve what I want using the HAL_SPI_Transmit_DMA() and HAL_SPI_Receive_DMA() functions and delays written into the while(1) portion of my main routine (as below). However, I would like to achieve the same using an ISR function that automatically executes once a byte is received into the SPI Rx Buffer.
Master Code:
uint8_t spiDataReceive = 0;
uint8_t spiDataTransmit = 0xBC;
while(1) {
if(!HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13)) {
//Transmit byte 0xBC to Slave and Receive Response
HAL_SPI_Transmit_DMA(&hspi2, &spiDataTransmit, 1);
HAL_Delay(20);
HAL_SPI_Receive_DMA(&hspi2, &spiDataReceive, 1);
if(spiDataReceive == 0xCD) {
flashLED2();
spiDataReceive = 0x00;
}
}
}
Slave Code:
uint8_t spiDataReceive = 0;
uint8_t spiDataTransmit = 0xCD;
while(1) {
HAL_SPI_Receive_DMA(&hspi2, &spiDataReceive, 1);
HAL_Delay(10);
if(spiDataReceive == 0xBC) {
HAL_SPI_Transmit_DMA(&hspi2, &spiDataTransmit, 1);
flashLED2();
spiDataReceive = 0x00;
}
}
No library is needed. You need to set RNEIE bit in the SPI CR register and enable in the NVIC the interrupt. 2 lines of code. No libraries needed.
The only needed resource is the Reference Manual from the STM website.
Yes, the HAL provides user callbacks. In order to use those, you have to activate the corresponding interrupt in NVIC and have the HAL handler called by the interrupt vector table (please have a look at stm32l4xx_it.c, too).
But before you do so, you should consider the following questions:
If you feel confused or frustrated by the complexity of ST HAL libraries, read the Reference Manual and follow the advice of P__J__ (see other answer).
If you feel confused or frustrated by the complexity of the hardware interface, follow the present answer.
Both HAL_SPI_Transmit_DMA() and HAL_SPI_Transmit_IT() support a variable number of transfer bytes.
If all you are going to need is that one-byte transfer, HAL functions may be an overkill.
Their advantage is that you can run some C library functions without dealing with HW register access in C (if that is quite new to you, coming from the arduino ecosystem). And of course, to transfer more than a single byte through the same interface when you extend your application.
You should decide whether you want to get an interrupt from the DMA you have tied to the UART, or if you want to avoid the DMA and get the interrupt from the UART itself. From my point of view, you should really not trigger an ISR by the same interrupt event which is used to start a DMA transfer to fetch the data!
In the same way as you find a description of the HW registers in the
Reference Manual and
Data Sheet of the controller, you find documentation on the HAL (layering concept, usage requirements etc.) in the
User manual of STM32L4/L4+ HAL and low-layer drivers
(see sections 70 and 102, resp., and chapter 3).
Of course, this interface aims mostly for abstraction and portability whereas directly addressing the HW interface usually allows much better efficiency in terms of latency/CPU load, and ROM/RAM usage. The "Low-Level" library drivers aim for a certain compromise, but if you are new to this whole topic and unsure what to start with, you should either start from the HW register interface, or from the portable HAL library API.
If the specification documents (HW or Lib description) are too abstract for you and you prefer some hands-on information source, you may want to first have a look at STM32Cube firmware examples for STM32CubeL4.
These also include SPI data exchange use cases (SPI_FullDuplex_ComIT for example) that are available for NUCLEO-L4532RE (and others) and described in application note AN4726 (page 16).
In addition to the interrupt selection/handling, you should check two more aspects of your program:
If you get an interrupt from the hardware, there is no reason for the HAL_Delay() calls.
Keep in mind that on SPI, you can only "return" data from slave to master while the master is transferring data (which may be zero data).
Otherwise, the "transmit" call on the slave side will only put data into the TX register, and the SPI peripheral will wait infinitely for the SCK trigger from the master...
I have configured a UART to receive in DMA mode where the size of the buffer is around 64 bytes. So, basically, the HAL_UART_RxCpltCallback() DMA receive complete interrupt will only fire when 64 chars are received.
Is there a way in STM32 through which I can configure a timeout for DMA Rx where when the buffer is only partially filled (i.e. less than 64 chars are received) and we don't receive anymore chars for a specified timeout, the DMA will then raise the same HAL_UART_RxCpltCallback() based interrupt to let the consumer consume whatever partial data is currently received on the UART?
You can use the UART Idle detection interrupt in parallel to the DMA interrupt.
I have used this multiple times with ST32F0xx processors and it is working perfectly.
There Idle detection should be available on F4 and F7 processors too.
There are some tutorials in the internet which target your problem and also provide the solution with the Idle detection.
E.g. check out this one this one.
It's easy but you have to use USART receiver timeout interrupt instead.
in order to get a count of transferred bytes, you can use DMA_CNDTRx or DMA_SxNDTR register (name different for STM family, where x - channel number ).
This register decrements after each DMA transfer. Once the transfer is completed, this register can either stay at zero or be reloaded automatically by the value previously programmed if the channel is configured in autoreload mode.
Unfortunately, STM HAL doesn't provide API, you should implement it yourself.
I'm using an Atmel SAM3S MCU, and their ASF stuff can do I2C (they call it TWI) communications. That's fine, except it's taking too much time from my main loop.
So, I'd like to be able to spark off a DMA transfer to read the data from the I2C device. However, all the docs say you can't turn on TX and RX simultaneously on a half-duplex device like TWI. The docs do show that it has a Peripheral DMA Controller (PDC) register section in the TWI registers, but I can't find any PDC examples, except for the USART, which is full duplex.
The only thing I can think of to try is to set TX section, and the next-RX section, and hope that it automatically enables RX after the TX is done.
Has anyone out there used DMA for an I2C read on the SAM3S? If so, could you point me to some docs or examples?
I'm not familiar with the particular part, however I would suggest that for many common usage patterns your best bet would probably be to only use DMA to handle multi-byte sequences of data. Most I2C peripherals allow data to be read out by performing a start with a "write" address byte, and, if that is acknowledged, sending out an address or other information about what data is desired. This is followed by a restart and a "read" address byte. If that is acknowledged, one may then perform all but one of the byte reads with the "ack" flag set. When that is finished, ask for the final byte to be read with the "ack" flag clear.
I'm not sure whether it would be worthwhile to use the DMA controller to clock out the bytes of the requested address, but probably not worthwhile to try to use it to clock out the first byte of the read command.
I am trying to send/retreieve data from/to FPGA using Matlab. I connected FPGA using Virtual com port. Now how to send data from Matlab to FPGA or read data of FPGA ?
FTDI 2232H is on the FPGA as well. I connected external LED's and switches on the I/O ports of the FPGA.
I am new in this field, so want some guideline to start communication b/w MAtlab and FPGA:
I tried following code:
s1= serial('COM9')
fopen(s1)
. Is it the right way to communicate ? Kindly guide. thanks
FPGA's are configured using a Hardware Description Language (HDL) such as Verilog or VHDL. These languages let you specify how the switch configuration within the FPGA, which in turn lets you construct your custom digital logic and processing system.
The HDL Coder Toolbox in Matlab lets you design and prototype your custom logic using higher-level functions, which are then translated into HDL and can be be used to directly program your chip. This tutorial describes the process in detail.
If you already have a design implemented on your FPGA and want to communicate with that implementation, you would use Matlab's serial port communication functions. The exact protocol will depend on the interface you have implemented.
Some intermediate debugging steps I find helpful:
Verify that you can send serial port data from your computer. In Windows XP, you can do this easily with HyperTerminal, and hooking up a scope to the output pins of your serial cable. Set up a trigger to capture the event. For Windows 7 and newer, you'll need to download a HyperTerminal client.
Repeat this same process with Matlab. Using a scope, verify that you see the serial port signal when sent from Matlab, and that the output matches the results from step 1. Again, set up a scope trigger to capture the event.
Now connect the serial cable directly to the FPGA board. Modify your HDL to include a latch on the serial input that displays the output on the LED's. Verify that your board initializes to the correct LED state, and that the LED state changes when you send the serial message.
Lastly, verify that you are interpreting the message correctly on the FPGA side. This includes making sure that the bit-ordering is correct, etc. Again, the LED outputs can be very helpful for this part.
The key here is to take small, incremental steps, physically verifying that things are working each step of the way.