In our application we are sending ADC data(240 bytes) to host computer through USB at full speed and using Serial application like (teraterm/minicom/Docklet) to validate the data, but we are facing the issue of data loss.
We are not getting where the issue is weather the seral application is not able to handle the incoming data or is there any limitations at controller side operating at USB full speed?
Microcontroller - NRF52840
USB class - CDC ACM
Best regards
Sagar
Suggest you entirely disable (temporarily) the ADC function and only have the microcontroller send a counting sequence to verify the known pattern is transferred without loss to the PC side. If the pattern is detected without loss, then re-enable the ADC function, but still only send the counting sequence and test again. If data is missing, then the problem is most likely the ADC function is causing a timing condition (such as blocking the CPU too long).
Related
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 BLE application on a embedded platform where there are frequent connect/disconnect events. The issue I am seeing is re-connection takes too long. The high frequency of connect/disconnect is a part of usage scenario so I can't change that. What I can do is make the re connection more efficient. I noticed, the bulk of re-connection is spent of service/characteristic discovery of other devices.
I still want to make sure the service/characteristic of the connecting device hasn't been changed. In stead of discovering all the service , can we instead use a characteristic that has the hash of all the service/characteristic on the device? So each device can compare the received hash with the stored one. Only in case of mismatch perform full service discovery. Is there a precedent of doing it in BLE?
Bluetooth Low Energy (BLE) allows devices to leave their transmitters off most of the time to achieve its “Low Energy”.
I would expect a central device to subscribe to notifications from the peripheral. That way the peripheral only turns on and transmits when there are updates.
The other approach would be to put the data (or hash) in the advertising data (manufacturer data or service data) like many sensor beacons do. That way you might not need to connect at all or only connect if needed.
I'm developing an embedded app, written in C, using a M16C/28 uC from Renesas.
The app manages two simple task:
RFID for detection and reading MIFARE tags. ( Using HW: Mf500 from NXP ). The uC handles whole FW implementation.
To deal with a RS485 frame protocol as slave. ( This app, have to be able to process RS485 frames every 10ms ).
The RFID implementation contains blocking code and the time response to detect a RFID tag is about 15ms. This causes RX reception buffer overflows on the RS485 processing.
My questions are as follows:
Is it normal to deal with such time responses in the RFID world?
Should I use a RTOS to preempt RFID task to meet RS485 frames requirements?
Should I use an external uC acting as host controller to release the load of the RFID manager uC?
Thanks in advance
To answer your questions:
Depends
You could use a RTOS.
You could use an additional uC.
Better options would be to:
Use DMA on serial communications.
Make the RFID code non blocking.
Do more in your serial interrupt.
The response time varies depending on the type of card/rfid that your are communicating with. I don't know the timings of Mifare RFIDs but 15 ms does not seem to be bad.
In your situation, you may have more requests coming from RS485 than you can handle on the RFID part. You can use queues or FIFOs to store the input requests so that you can treat them later on, according to the physical limitations of your system.
Using an RTOS can help but usually, they are not free. Plus, you may have to port it to your platform if it is not already supported. If all your firmware does is handling RS485 requests and communicating with the RFID, you should sort this out with interruptions to store the incoming commands and a loop to process them separately.
And for the second uC, it's like the RTOS. It can help but might not be the right solution in this scenario (you will have to manage 2 firmwares, a communication protocol or a FIFO between uCs, it will cost twice the price, ...).
Good evening!
I'm configuring NTP on an embedded Linux system connected with an U-Blox GPS receiver. I've used NTPD and GPSD.
I would like to know what's the technical difference between:
PPS Signal provided by the GPSD shared memory SHM, (Pseudo IP Address 127.127.28.1);
PPS Signal "Stand Alone", but always connected in some way I would like to understand, with GPS (Pseudo IP Address 127.127.22.0)
It is critical for me to understand because I really need an high level synchronization and I would like the right information from the receiver.
Searching all over the web I've found only confused answers to my doubt...
Thanks in advance!
FL
The SHM driver is not designed to provide a PPS signal by itself. So maybe your notion here is misguided.
A PPS signal is used for getting a (precise) notion of the
frequency of the local clock (the one used for measuring external signals), as it just provides a well known timing distance of the "pulses" (1s in this case). Actually pps is a frequency source.
GPSD on the other hand is communicating with some device (could be built into your HW). It then proovides the time data read from the GPS source via shared memory to ntp. This provisioning of data does not guarantee any timing relation (delay). (E.g. could occur earlier or later within the second due to load or scheduling)
From the perspective of ntp, you will have a true date/time label, but you might not know exactly when the related point in time did occur related to your local clock. (Usually not precisely enough for common ntp use cases.) This is where PPS kicks in.
Depending on how the GPS device is being connected to your local machine (parallel, serial, internal bus) you will have some way of getting an interrupt on the pulse from the pps signal. (e.g. with serial connection you usually will get a transition on the DCD pin).
The internal processing of the related interrupt will read the local clock and the resulting timing information is then provided for further processing. This information is exactly what the PPS clock discipline is using and providing to ntp. What you need to configure here, is the offset from the triggering of the pulse to reading the local clock. (Pulse usually is assumed to occur "on the second.)
So, in your configuration, it is likely that the "source" of the PPS signal is the same GPSD is using for providing date/time data (your GPS device).
However, the actual signal used for date/time data and pps is different. Date/time will use a data telegram or some register content read from the GPS device while pps will be a level change on an input pin proveded from this very device.
For details start with the interfacing information from your GPS receiver, especialy any timings stated there. Then look at ntp and figure what driver(s) will allow exploiting such input data for best time quality.
I am new to Wireshark and capturing packets and all Stuff. Let me get it to the straight.
I have a hardware which outputs its data over Ethernet using a UDP Broadcast. I Can directly plug a Ethernet Cable to a In-line RJ-45 Coupler (attached to the hardware) and my PC Running Wireshark.
REQUIREMENTS : I need to Capture RAW Data which my hardware is broadcasting so that it can be given to other team so as to know the format in which it is providing for further post processing.
What I Did : Initially , I connected the Ethernet Cable from my home and Started capturing the packets which didn't make any sense to me.
Can you please point out if I am going in correct direction ? Sorry if its a very basic question, but raw data from the hardware is important for my further tasks....
As far as any software can understand a wire you will always get a packet. Between you (in front of a computer) and the cable in the in the RJ-45 jack sits a NIC (network interface controller, i.e. your network card).
Your Ethernet NIC will read the current on the cable (in manchester encoding for ethernet) and synchronize itself to any Ehternet traffic on that cable. What does "synchronizing" mane in there? In front of any Ehternet traffic come 64 alternate bits of 0s and 1s which are meant to synchronize the clocks on both communicating NICs. Without proper clock synchronization some data may be misinterpreted.
But why I am talking about clock synchronization? Because if you want the data as RAW as it is on the cable you will not get it. A NIC will never send any synchronization bit to the rest of the computer, therefore it is absolutely impossible to read exactly what is on the cable by using software.
On the other hand I find hard to believe you want the RAW data as RAW as that. After the synchronization bits come an Ethernet encapsulated packed. Yup, Ethernet uses packets. They're link layer packets (layer 2 in OSI).
And wireshark gives you exactly that (in most cases, see note at the end for two exceptions to this rule): every Ehternet packet that the NIC understands, manages to sync, and manages to read without collision is sent to the kernel and then read by wireshark. A cable has electrical interference and has no provision against collisions (it's just a piece of cooper!) therefore the NIC abstracts things like interferences and collisions.
I'll repeat it once more: After abstracting the synchronization bits, sender collisions (which turn the cable into one huge interference) and plain interferences; all that remains is a stream of packets, one after the other.
Extra Notes
NICs sometimes do ignore some Ethernet packets: packets that are not directed to their MAC. This can be changed by enabling promiscuous mode (available in most NICs). This is irrelevant for broadcast packets.
There are exception to the rule of wireshark getting all the traffic coming from the NIC:
If the traffic comes incredibly quick, wireshark may drop out of kernel schedule and not see some packets. It happens, nothign can be done about it.
If you listen on all interfaces (as opposed to selecting a single interface to listen at), wireshark will strip the Ethernet (or Wifi) headers. This is a wireshark hack needed to make output files uniform (and possible to be read by other applications).
TL;DR, wireshark output (pcap) is pretty much just the stream of packets that it got from the NIC, one after the other. That is as RAW as you can get with software.