I am working with ADE7953 metering IC and I use the uart serial communication in raspberry pi to communicate with the IC and i have wiring pi installed in it.Can anyone help me regarding how to configure the IC.
You need to check the datasheets and look for the MODE register configuration. Also take care for the active energy line cycle accumulation mode registers to set before you take IRMS or VRMS any of the ENERGY register
The ADE7953 contains a detection system that automatically
detects which of the three communication interfaces is being
used.
The CS pin (Pin 28) is used to determine whether the
communication method is SPI. The pin must be low
during the SPI communication for this interface method.
The CS pin is active low and will automatically lock onto
SPI communication as a result.
The SCLK pin (Pin 25) is used to determine whether the
communication method is I2
C or UART. If this pin is held
high, the communication interface is set to I
2
C; if it is held
low, the communication interface is set to UART.
Now, for UART should be configured in hardware as pin28 should be high, pin25 should be low, pin 27 Rx and pin 26 Tx
Related
I am trying to flash code over CANBUS on Nucleo-F446. I am referring this application notes
https://www.st.com/resource/en/application_note/cd00264321-can-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf
So according to it in Boot mode the default baud rate of CAN is 125KBPS and we need to use PB5 and PB13 pin which are CAN2 pins.
For testing I tried to send CAN message with DLC=0 and STDID = 0x79 for which STM32 should return a ACK with same ID i.e. 0x79.
But I am not getting any response.
You must add a external clock to your Nucleo Board
The system clock is derived from the embedded internal high-speed RC for USARTx and
I2Cx bootloaders. This internal clock is also used for CAN and DFU (USB FS Device) but
only for the selection phase. An external clock multiple of 1 MHz (between 4 and 26 MHz) is
required for CAN and DFU bootloader execution after the selection phase.
STM Bootloader Description
I have a third party device that is UART programmable.
I need to create a USB - UART bridge with a functional password (programming only after entering the correct password)
generated the code using the latest version of STM32CubeMX for Atollic TrueSTUDIO for STM32 9.3.0 ...
I transfer data between USB and UART through a buffer (one for usb-uart, and another one for uart-usb)
when I try to transfer several characters everything is OK, but when I try to transfer a large data packet, problems start due to the fact that the USB speed is much higher than the UART ...
there are two questions:
1.How do I tell USB that I need to stop transferring data and wait until the UART (buffer) is busy
2.How on the side of the microcontroller to get the baud rate set on the PC (set when the terminal is connected to the virtual COM port)
USB provides flow control. That's what you need to implement. A general introduction can be found here:
https://medium.com/#manuel.bl/usb-for-microcontrollers-part-4-handling-large-amounts-of-data-f577565c4c7d
Basically, the setup for the USB-to-UART direction should be:
Indicate that the code is ready to receive a USB packet
Receive a USB packet
Indicate that you are no longer ready to receive a USB packet
Transmit the data via UART
Start over
Step 0: Initial setup
Call USBD_CDC_SetRxBuffer to set the buffer for receiving the USB data. Unless you use several buffers to achieve higher throughput, a single call at the start of the program is sufficient.
Step 1: Ready to receive data
Call USBD_CDC_ReceivePacket. Other than what the name implies, this function indicates that the app is ready to receive data. It immediately returns before the data has actually been received.
Step 2: Receive a USB packet
You don't need to do anything here. It will happen automatically. Once it's complete, CDC_Itf_Receive will be called.
Step 3: Indicate that you are no longer ready to receive a USB packet
Nothing to do here. This happens automatically whenever a packet has been received (and double buffering is not enabled).
Step 4: Transmit the data via UART
I guess you know how to do this. It's up to you whether you want to do it in a blocking fashion or using DMA.
Since a callback is involved, you cannot put this code into the main loop. It might be possible to put all code into CDC_Itf_Receive if blocking UART is used. It would appear in the order 2, 3, 4, 1. Additionally, initialization is needed (0 and 1).
In the UART-to-USB direction, you would need to implement flow control on the UART. The USB flow control is managed by the host. Even though USB is much faster than UART, flow control is relevant as the application on the host can process data as slow as it likes to.
Regarding question 2: I'm not sure I understand it... The microcontroller cannot set the baud rate on the host. Either the host can specify a baud rate (transmitted over USB and applied to UART), or if the UART has a fixed baud rate, you can ignore baud rate (any baud rate set on the host side will work as it does not apply to USB).
I have a Gateway - Node application using the LoRa module but I don't know whether to choose the LoRa module to interface UART or SPI.
Can someone help me distinguish the difference when using these two types? Example: when I have 5 Nodes connected to Gatewway, which one should I use? and same when I have 50 Nodes.
Thanks!
A UART converts the signals to RS232 signaling(NOT VOLTAGES, You will need an additional adapter chip like the FTDI 232H) to hook up to a serial port on a computer. Speeds are usually limited to less than 400 Kilobits per second(varies based on distance and devices)
If you are connecting multiple devices to the same micro-controller(Arduino), use SPI. The connection speeds are not limited by standards. It is a bus arrangement with 4 pins (clock SCLK, input MISO, output MOSI and Slave select SS) The SCLK, MISO, MOSI are connected to all devices.To chain additional devices it requires an additional SS pin per device.
SPI is going to be faster(several (<5?)Megabits per second is not uncommon (depends on length(not greater than .3 meters), wire quality, environmental noise and device specifications) and requires less discrete components.
Since LoRa speeds max out around 300kbps, a single SPI connected gateway could theoretically handle 15 LoRa transceivers on a single gateway.
Doing 15 devices may violate local RF duty cycle restrictions resulting in fines and/or imprisonment.
Please check with your regulatory institutions prior to implementation of any solution.
I would suggest using four transceivers with external antennas each pointing in a different cardinal direction(possibly offset) at each gateway. This configuration should permit 400+(depending on usage patterns) client devices per gateway.
I'm learning embedded development, and I'm trying to communicate with the accelerometer (LIS3DSH) on the discovery board using the SPI protocol. I'm only using CMSIS headers so that I'm forced to interact directly with the registers.
According to the schematics, these are the pins being used by the board for communication with the accelerometer:
PA5: SPI1_SCK
PA7: SPI1_MOSI
PA6: SPI1_MISO
PE3: CS_I2C/SPI
From my theoretical understanding of the SPI protocol, whenever I want to receive or transmit data between the master and the slave, I first need to pull the CS pin (PE3) down and then start the communication. This seems to be confirmed by the LIS3DSH user manual as well.
But now I'm confused about what the meaning of SSM is. According to the board's user manual, this is what the software slave management bit does:
When the SSM bit is set, the NSS pin input is replaced with the value from the SSI bit.
The NSS pin is nothing but the slave select pin, right? Which means it is PE3 in this case.
The SSI bit is bit 8 on the SPI_CR1 register. Does this mean I should instead toggle this SSI bit instead of PE3? That doesn't make sense because how would board know that the PE3 is the relevant CS pin?
So how are the CS pin/line and the SSM bit related, if at all?
If they're not related, do I need to configure the PE3 pin with alternate function mode and and as a pull-up, and then pull it low every time I need to communicate using SPI with the accelerometer?
The NSS pin is an input used as a CS by some other device when the SPI peripheral is in slave mode, or can be used as an output to support multi-master configurations.
If you are operating the SPI in single-master mode, the pin is not used at all.
Moreover SPI1_NSS is an alternate function of PA4 or PA15 so not related to the CS GPIO on PE3 in your case. In master mode, any number of available GPIO pins may be used as CS lines for each peripheral on the same SPI bus, and is driven in software - it is not an "alternate function", and not part of, or controlled by, the SPI peripheral.
I am working on an embedded project which includes two half duplex UARTS, and one full duplex UART.
UART1 is connected to Device A. UART2 is connected to Device B, and UART3 is connected to the PC. UART1 and UART2 are half-duplex, thus RX/TX modes have to be configured properly.
When a signal on UART1 is triggered, UART2 fetches some data from Device B. That data is put into a buffer, and then transmitted back to UART1, AND UART3. Device A consumes the data, and sends more items on UART1, which then has to be passed to UART2 for Device B to respond.
I was thinking about an efficient state machine that can handle the switching modes between TX/RX mode, and so far my UART code is interrupt driven. What would be some ways to tackle the flow of this program?
I don't think you will need a state machine for this case. Why not just hook up all interrupts accordingly and just forward anything received from one devivce to the other(s)?
You may want to include a TX (ring-)buffer to accomodate for different speeds of each UART and then just have a RX-ISR write the data received to the appropriate TX buffer(s), from where it will then be consumed by the other UARTs' UDRE-ISRs.