I have a Raspberry Pi 3 with Android Things running on it, and I'm trying to write an application that makes use of UART serial. I used the sample code in Android Things documentation for sending data, and it worked perfectly, but the code supposed to receive data returns empty bytes.
while ((count = uart.read(buffer, buffer.length)) > 0) {
Log.d(TAG, "Read " + count + " bytes from peripheral");
}
There's an interrupt for when the UART buffer gets some data in, and that gets triggered calling the reading function, but reading the buffer returns nothing but zeros. In fact the loop isn't even entered at all.
I'm using a 5V FTDI Cable with a 5/3.3V Level shifter to send and receive data from the Raspberry.
How can I fix this?
Raspberry pi 3 has some issue with uart, check these answers:
UART peripherals on Android Things for Raspberry Pi 3
Uart / GPS driver sample buffer overflow
Use Docklight to verify UART data with the help of USB-TTL Converter.
Check all the Connections like
Tx -> Rx
Rx -> Tx
GND -> GND
.
Send data from Docklight.
Related
I am trying to communicate with a temperature humidity readout unit, a Fluke 1620, using a Raspberry Pi Pico W. Ultimate goal is to log data and make it available on our work network. I wanted to test the UART connection but I get a null response when I run the code. Here is the code I wrote.
from machine import UART, Pin
import time
uart1 = UART(0, baudrate=9600, tx=Pin(0), rx=Pin(1))
uart1.write(b'*IDN?\n')
time.sleep(0.25)
rxData = bytes()
while uart1.any() > 0:
rxData += uart1.readline()
print(rxData)
The response I get is b'\x00'
I will admit I am pretty new to Python and haven't written a real program in many years but this in my mind should work. I've written a normal Python script very similar to this and received a response. Can anyone tell me where I'm going wrong?
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 am working on interfacing of SIM7600E-H (A GPS + LTE Module) with Arduino UNO over UART using AT Commands. The high-level plan is to acquire longitude and latitude using IZAT feature and transmit them over LTE to data-server.
Development Board: Arduino UNO with UART using <SoftwareSerial.h>
First, I am getting GPS data using IZAT GPS feature, the acquired data is then bifurcated to get actual longitude and latitude position. Then, creating a data-string comprises POST request and acquired longitude & latitude data. The data-string is of 217 bytes. This data-string is then transferred to SIM7600E-H using command AT+CIPSEND and a terminator - 0x1A. Now, as per AT command set manual, +CIPSEND command should return the received bytes, but it is acknowledging with 0,2,2 instead of 0,217,217. Now, If we follow the same steps for Standalone GPS instead of IZAT GPS then we are getting successful acknowledgment with 0,217,217 and data is also getting posted on data-server.
Further tested, with IZAT GPS feature enabled, I found out that I am able to transmit around 150 bytes only, when using +CIPSEND command. If I am adding some more bytes then it is again acknowledging with 0,2,2.
Prior doubt was if <SoftwareSerial.h> is creating this problem or not?
So, I tried with <AltSoftSerial.h> and even with Hardware serial on DIO 0 & 1. But problem still persists.
So, I facing this kind of issue with +CIPSEND command when enabling IZAT GPS feature.
Serial monitor outputs when using IZAT GPS and Standalone GPS separately:
I have two XBees S1-one attached to a temperature sensor. This Xbee reads analog values, converts them into digital values thanks to the ADC and transmits them.
The other XBee - the receiver, is connected to a computer via a USB Explorer.
This XBee works in API mode. The XBee connected to a computer receives the data send by the transmitter. I monitor the received values with the X-CTU software, version 6.2.0. Up until this point, everything works fine.
However, the problem that I encounter is that the data received on the computer is coded: there are bits corresponding to the address of the receiver, bits corresponding to the address of the sender, the data itself, acknowledgment bits,etc. My question is how can I extract only the data bits without all th other information send by the transmitter?
I tried to read the values with a USB to TTL cable, connecting this cable to the Tx, Rx,GND and 5V(there is a 5V input in the USB Explorer despite that the XBee works at 3.3V) of the receiver XBee and using the screen command in Linux. However, in this way I receive ASCII characters and I want to receive the binary code.
I want to put those values in a database in order to be able to treat them later.
Thank you for your assistance.
With a library like this one, you can use function to get the data from your Xbee in python ;) (if you use linux)
You just have to initialise the port (should be on /dev/tty...) and than catch the data with a loop which check if new data is coming.
If you need more help I can send you part of my code (doesn't have it near me, it's on my raspy)
I hope I've help you ;)
Thana
I'm using PIC18F87J11 as the master and LiPower Shield as the slave, and all I want to do is to be able to read the battery voltage value from the LiPower Shield. I'm using MPLAB C18 libraries for the I2C communication. I'm not able to get correct readings as I think the communication between the two devices is not setup correctly.
I'm looking for interpretations of the waveform signals in order to detect the issue. Also I would like to know if I'm missing something in the code. Any recommendations to improve the code would be helpful.
The LiPower Shield came with a sample code for Arduino but I'm using PIC18 chip from Microchip. The sample code is found here.
Here is the signals I'm getting while trying to read the battery voltage.
Code:
SSP2ADD = 19;
OpenI2C2(MASTER,SLEW_OFF);
StartI2C2();
IdleI2C2();
WriteI2C2(0x36);
IdleI2C2();
data = ReadI2C2(); // Read byte of data
printf ("\r\nAddress 32");
printf (" Byte:");
PrintChar(data);
IdleI2C2();
AckI2C2();
IdleI2C2();
WriteI2C2(0x02);
IdleI2C2();
data = ReadI2C2(); // Read byte of data
printf ("\r\nAddress 02");
printf (" Byte:");
PrintChar(data);
IdleI2C2();
AckI2C2();
StopI2C2(); // Stop condition I2C on bus
Output: Which I think is wrong.
Address 32 Byte:FF
Address 02 Byte:FF
I'm not really sure if I'm writing/reading from the correct address, but that's the address they used in the their sample code. I hope I can get some interpretations on the signals and feedback on the code if possible.
I'm not familiar with the PIC but your code looks nowhere near right. Per the MAX17043DS datasheet, page 12, a memory read must consist of the following:
I2C start condition
Write device I2C write address (0x6C)
Check for ACK from slave
Write 8-bit memory address
Check for ACK from slave
I2C repeated start condition
Write device I2C read address (0x6D)
Read first byte of data
Send ACK
Read second byte of data
Send NACK
I2C Stop condition
What I see in your code is an I2C Start condition followed by a write 0f 0x36. Since this is not the device address the slave recognizes, it sends a NACK (as seen on your logic analyzer traces) and ignores everything else.
This question and answer has a lot of information on I2C on a PIC18. You also should probably find a read a basic I2C tutorial.