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, ...).
Related
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).
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 trying to implement the UPLINK of a Ground Station controlling a small satellite. The idea is that the link should stay always active in between each transmitted telecommand. For this, I need to insert some DUMMY or IDLE sequence bytes such as 0xAA or similar.
I have found that some people already faced a similar issue and posted their questions here:
https://www.ruby-forum.com/t/constant-carrier-digital-transmission/163379
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-08/msg00148.html
So far, the best I could achieve was to modify the EventStream Source block from https://github.com/osh/gr-eventstream in order to preload the vectors with my dummy sequence (i.e. 0xAA) instead of preloading them with zeroes. This is a general overview of the GNURadio graph I'm using:
GNURadio Flowgraph Picture
This solution however introduces a huge latency and the sent message does not appear at the output until a huge amount of time has expired (in the order of several seconds).
Is there a way of programming the USRP using GNURadio so that it constantly sends a fixed sequence which should only be interrupted when an incoming message is passed? I assume that the USRP has the ability of reading tagged streams in order to schedule transmissions. However, I'm not sure how to fit this in my specific application.
Thanks beforehand!
Joa
I believe this could be done using a TCP or UDP source block.
Your control information could be sent to the socket using TCP/UDP. GNU Radio would then collect and transmit the packets. Your master control program would then have to handle the IDLE stuffing but solving the problem external to GNU Radio is easier.
Your master control program would basically do the following:
1. tx control data as needed
2. if no control data ready before next packet must be sent send an IDLE packet
I'm writing code to learn about the USB peripheral on a Freescale Kinetis microcontroller. I've managed to get through enumeration on a Linux host, and I can send & receive packets using vendor-custom codes on EP0, interacting with a libusb test program.
It looks like I can configure additional control endpoints (non-zero endpoint numbers) on the microcontroller, but I don't see a way to make libusb send / receive control transfers to those endpoints. (libusb_control_transfer doesn't require an endpoint number, though libusb_bulk_transfer and libusb_interrupt_transfer do.)
Are non-zero control endpoints so uncommon or unnecessary that it's not worth bothering with them? Is there some way to get libusb to execute control transactions to non-zero endpoints?
Is there some way to get libusb to execute control transactions to non-zero endpoints?
You can try to modify the endpoint field in the libusb_transfer structure of the asynchronous I/O API.
But it would surprise me if your microcontroller could actually support non-zero control endpoint(s) - not that many do.
In practise you would rather use either interrupt or bulk endpoints. Both have less overhead - allowing higher throughput with bulk transfers (see for example USB 2.0 SPEC Table 5-2 vs. Table 5-9).
I have embedded firmware which have terminal over serial transmission. I am doing command from terminal which waits data (text file) which it should save to flash chip. However, writing flash is much slower than terminal transmission.
Text file may be pretty big (many kB), so in small embedded environment I cannot simply dump it to RAM. I though if it possible to communicate with standard terminal emulator (which have drag/dop support for files) to pause transmission every time when write buffer is full and tell continue again after write is done? I haven't find anything which may help me throught this.
Well, offcourse I can make PC frontend which understands this trick, but in basic level it should be nice if all function can be used through normal terminal if needed.
For a basic serial connection you could see if the hardware supports flow control. This would be the CTS, RTS lines (clear to send, request to send).
http://en.wikipedia.org/wiki/RS-232_RTS/CTS#RTS.2FCTS_handshaking
However many simple embedded systems do not implement this type of flow control.
If the hardware does not support flow control, then you will have to look at using some form of software flow control. You maybe able to implement the Xon/Xoff flow control ( http://en.wikipedia.org/wiki/XON/XOFF ) or could implement a simple file transfer protocol, like XMODEM, or ZMODEM, or even tftp. This depends on what your terminal can support.
I always use XMODEM when programming data into FLASH via a serial link from a PC. When using XMODEM it only sends one data packet at a time and waits for you to acknowledge the packet before sending the next one.
This means we control the flow via software on the receiving side:
Get packet ->
Write packet ->
Ack packet ->
Repeat util done...
XMODEM can be implemented on the smallest of devices (less than 1K RAM) and the code is very simple. All serial terminals support XMODEM (upto windows XP ship with an XMODEM capable terminal). XMODEM requires no special hardware.
Here is the spec.
Here is an example implementation.