I am working on an STM32f401 Nucleo board and ESP8266 wifi module. I am using Eclipse gcc-arm tool chain and cubeMx to generate code. I can transfer and receive data perfectly with USART/UART DMA.
Now I am stuck with ESP8266. I cannot send data from MCU to ESP and I'm not getting response from ESP to MCU. I already tested the ESP module communication, I can connect TO THE wifi with AT commands through USB and can also receive data in web via socket connection.
I configured USART1_TX/USART1_RX with PA9/PA10
Thanks in advance.
I'm not an expert, but I try to help you.
Which baud rate are you using? Is it coherent with the ESP8266 documentation?
Check the power supply and the connections.
Therefore, remember that the AT commands are case sensitive (they must be written with capital letters only) and they must terminate with carriage return and line feed, so "/r/n".
That's right at first check baud rate are matching
Then do you use dma for both tx/rx direction ?
For dma rx note that the "completion" callback will be called only when the full buffer will be filled.
If you neeed to "break" reception on ending "\n" "\n" then you might use the interrupt rx method oen hatr at a time and inspect it as it arrives in the callback that keep on asking one more byte until not done.
Alternatively with dma keep on polling the dma count and analyzed current rx buffer for some \r \n. abort/Stop dma when done.
Related
As we all know, in the CAN bus communication protocol, sender know whether the data was successfully sent. I send socketcan data as follows.
ret = write (socket, frame, sizeof (struct can_frame));
However, even if the CAN communication cable is disconnected, the return value of ret is still 16(=sizeof (struct can_frame)).I queried the information and found that the problem was due to the tx_queue of the network stack used by socketcan. When write is called multiple times, the buffer is full and the return value of ret is -1.
But this is not the behavior I expect, I hope that every frame of data sent will immediately get the status of success or failure.
By
echo 0> / sys / class / net / can0 / tx_queue_len
I want to cancel the tx_queue, but it does not work.
What I want to ask is, is there a way to cancel the tx_queue of socketcan, or to get the status of the each sending frame about controller through the API (such as libsocketcan).
Thanks.
You cannot use write() itself to discover whether a CAN frame was successfully put on the bus, because all it does is write the frame to the in-kernel socket buffer. The kernel then moves the frame to the transmit queue of the SocketCAN network interface, followed by the driver moving it to the transmit buffer of the CAN controller, which finally puts the frame on the bus. What you want is a direct write which bypasses all those buffers, but that's not possible with SocketCAN, even if you set the transmit queue length to 0.
However, there is another way to get confirmation. If you enable the CAN_RAW_RECV_OWN_MSGS socket option (see section 4.1.4 and 4.1.7 in the SocketCAN documentation), you will receive frames that were successfully sent. You'll need to use recvmsg() so you get the message flags. msg_flags will have the MSG_CONFIRM bit set for a frames that was successfully sent by the same socket on which it is received. You won't be informed of failures, but you can detect them by using a timeout for the confirmation.
It's not an ideal solution because it mixes the read and write logic in your application. One way to avoid this would be to use two sockets. One for writing and reading MSG_CONFIRM frames, the other for reading all other frames. You could then create a (blocking) write function that does a write() followed by multiple calls to recvmsg() with an appropriate timeout.
Finally, it is useful to enable error frames (through the CAN_RAW_ERR_FILTER socket option). If you send a frame on a socket with a disconnected cable, this will typically result in a bus off state, which will be reported in an error frame.
I am using asynchronous USART on STM32L4R5 for communication with PC. I am able to receive data on PC side but I am not able to receive any data on nucleo board send by PC. Following is the code I am using for transmission
while (1)
{
HAL_GPIO_TogglePin(LD2_GPIO_Port,LD2_Pin); //Toggle LED
HAL_Delay(1000);
for(i = 0; i < 5; i++)
{
USART1->TDR = p[i];
while((USART1->ISR & 0x40) == 0);
}
while ((USART1->ISR & 0x20) == 0);
uint32_t receivedByte = (uint32_t)(USART1->RDR);
}
In the above sending part is working fine but receiving is not working. I have checked and wiring is proper.
Why don't you just using USART Receiving interrupt it will help you in capturing received data. Rather than polling for USART Reception.
There are two reasons for no response
You might not sending EOD and Carriage return while sending data on USART. Many USART based operation based on these character. Module will listen to USART untill these characters are received.
Your hardware connections are not right. Make sure you are connecting TX to Host to Rx of Slave and vice versa.
I suggest USART interrupt because polling is not a good method while writing a code.
My gateway uses the Raspi and RFM95 configuration and operates at 915 MHz. I am using the single channel packet forwarder code by tfelkamp (https://github.com/tftelkamp/single_chan_pkt_fwd).
My gateway only the detects the first message it received and ignores the all messages afterwards. It is still connected to the TTN server but does not receive any more messages.
Can anyone explain what might be the cause of this? Might it because the RFM95 sleeping or the code no longer forwarding the message from the transceiver.
Thanks
I experienced a similar issue. Please note your sender is using different channels, but starts with channel(0). This is the first successful message you receive. Your single channel receiver is just able to receive channel(0). There is a work around for this issue for your sender explained here
This sounds like your transmitter sends the messages using frequency-hopping, while your receiver does not handle it correctly (or the other way around).
Definition of frequency-hopping found in chapter 4.1.1.8 of Semtech's SX1272 datasheet:
Frequency hopping spread spectrum (FHSS) is typically employed when
the duration of a single packet could exceed regulatory requirements
relating to the maximum permissible channel dwell time. This is most
notably the case in US operation where the 902 to 928 MHz ISM band
which makes provision for frequency hopping operation. [...]
If you're using the LMIC-Arduino library for your node then yes, by default it is transmitting in a range and the single_chan_pkt_fwd gateway is only receiving on the frequency you specify in the global_conf.json or the .cpp source (depending on your chosen library).
With the assumption that you're using the arduino-lmic library, make the changes/additions mentioned in the this TTN forum post linked by Rainer which is the same I ran into.
Also... you'll find this further down the thread: in src > lmic > lmic.c edit the following:
void LMIC_disableChannel (u1_t channel) {
if( channel < 72+MAX_XCHANNELS )
//LMIC.channelMap[channel>>4] &= ~(1<<(channel&0xF)); // comment this one
LMIC.channelMap[channel/16] &= ~(1<<(channel&0xF)); // add this one
}
Then pick a frequency on channel 0 and set that for both node and packet forwarder. Here's a table snip from this page. I went with 902300000 and it's working fine.
"freq": 902300000,
"spread_factor": 7,
I'm sending out probe requests using scapy. It works perfectly fine on my desktop but when I send it out from scapy, using the exact same code, the packets arrive malformed. I'm watching them in wireshark.
The malformed one has a Logical-Link Control layer and the bits are all just out of order. I don't really know how else to put it. The source and destination mac addresses are both offset by a few bits. The packet is twice as large, I'm just really baffled.
For example
in scapy, my destination address is "aa:bb:cc:dd:ee:ff"
In the packet capture, the destination is "00:00:00:aa:bb:cc"
EDIT:
The packets show up fine on my laptop in wireshark, but in wireshark on my desktop is where there is an issue.
sendp(Dot11(addr1=dest,
addr2=source,
addr3=source)/
Dot11ProbeReq()/
Dot11Elt(ID="SSID",info='test')/
Dot11Elt(ID="Rates", info='\x02\x04\x0b\x16\x0c\x12\x18$')/
Dot11Elt(ID="ESRates", info='0H`l')/
Dot11Elt(ID="DSset", info='\x06'),
iface='wlan0', count=3)
EDIT: I believe the issue is because scapy is sending the wrong type/subtype.
The packet should have
Type/subtype: Probe Request (0x04)
but the packet in wireshark displays
Type/subtype: Data (0x20)
Monitor mode was not initiated correctly. The packets became malformed when not sent over a monitor interface.
try
sendp(RadioTap()/
Dot11(addr1=dest,
addr2=source,
addr3=source)/
Dot11ProbeReq()/
Dot11Elt(ID="SSID",info='test')/
Dot11Elt(ID="Rates", info='\x02\x04\x0b\x16\x0c\x12\x18$')/
Dot11Elt(ID="ESRates", info='0H`l')/
Dot11Elt(ID="DSset", info='\x06'),
iface='wlan0', count=3)
It is possible to read and send data with TComPort for modbus RTU protocol?
I have read wiki http://en.wikipedia.org/wiki/Modbus for modbus, but what mean start and end with 3.5c idle?
I use C++Builder2009
Of course it's possible.
In MODBUS ASCII it is easy to determine end of message since 2 bytes are used for single byte transmitted over communication line (byte is transmitted as it's ASCII hexadecimal representation), but in MODBUS RTU you have 1 byte used for single byte transmitted which means that they had to know somehow that messages has ended. So, bytes are added to a new message as long as pause between them is less then 3.5 characters. When pause is greater then 3.5, you have an end of a message and you can parse the message, process it, and get ready for new one. This idle time is measured in characters since that is the only constant. Time period of 1 character transmitted over 9600 and over 115200 is not the same, and it is also not the same for 9600-8N1 and for 9600-8E2, so you have to adjust that time based on COM port settings.
yes its possible to send data with comport using modbus protocol.
There are various packages for that like RXTXcomm.jar,comm.jar which provide functions to communicate with slave device using com port