Is there way to tell terminal wait before send more data? - embedded

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.

Related

Handling RFID time response functions in C

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, ...).

Sending AT commands from an embedded system to a Fastrack Supreme Wavecom Module

I have an embedded system that controls a motor using pwm and some other things, I send commands through a serial connection, which is connected to a Fastrack Wavecom Supreme GSM Module. However, the module connected to the embedded system (the client), fails to send the message to the server module.
I have been able to send messages back and forth between the two wavecom modules, however, when I try and send from my PIC18F45k22 to the wavecom module, it fails.
Any ideas of what could be going wrong?
You did not specify what type of serial communication you are using. For instance, if you are using the PIC's SPI module you may be sampling on the wrong edge of the clock. There are at least 2 common SPI modes widely used and 4 all together. If you are using the PIC's UART there are "a whole bucket full" of setting that may be off. Speed, number of bits, in band signaling, out of band signaling, parity, ect.

Printer Status Monitoring adobe AIR Desktop App

Want a platform independent desktop app to check the toner/Cartridge level of a network printer and notify the user of the status and give him option to request for purchase of the toner if low.
The info i got till now is that we need to fetch values for OID from MIB files of a SNMP enabled Printer. I want this app to be as generic as possible for all Brands, however need for today is specially for Brother Printers & MFPs.
Sorry for looking nube but i have searched enough and there is not much information available.
Can i use native support & Monitoring tool of the Manufacturer as brother provides its monitoring utility which can be installed on Desktop(In that case where the MIB file will be located(on the device or within installed program on the Desktop?) or need to use network monitoring tools like icanga, negios etc.
Secondly how to implement it on AIR.I am thinking to use AIR for the first time and wondering will it be helpful and do i need to know something more on this technology before proceeding.
There are some networking monitoring tools available like negios & Icinga. which can be installed even over a desktop. Can the data from these can be parsed and used. We need it for brother printer but want to implement it for Multi-Manufacturer solution as per documents format for MIB file is getting standard. We will invest time only if its universal even after a year or so as its not worth time for a single manufacturer.
So following CLI's i find useful in Net-SNMP and believe that it will get me to output by calling these Applictions by External Script(AIR).
convert between numerical and textual forms of MIB OIDs, and display MIB content and structure (snmptranslate).
A graphical MIB browser (tkmib), using Tk/perl.
A daemon application for receiving SNMP notifications (snmptrapd). Selected notifications can be logged (to syslog, the NT Event Log, or a plain text file), forwarded to another SNMP management system, or passed to an external application.
An extensible agent for responding to SNMP queries for management information (snmpd). This includes built-in support for a wide range of MIB information modules, and can be extended using dynamically loaded modules, external scripts and commands, and both the SNMP multiplexing (SMUX) and Agent Extensibility (AgentX) protocols.
Are there any API to read MIB files in AIR.
Any links or some added information is highly appreciated.
For printers without SNMP support, you'll probably have to implement a manufacturer-specific solution. If you want to write an AIR app that talks to SNMP-enabled printers, I can see the following approaches:
Implement SNMP client in ActionScript
Since SNMP is usually based on UDP, you could use flash.net.DatagramSocket to implement your own SNMP client in AIR. AFAIK, there are no ready-to-use ActionScript libraries, so you'd need expert knowledge of the SNMP protocol and a lot of development time.
Write an AIR Native Extension
With a Native Extension (ANE) you could implement the SNMP client in C/C++. This has the advantage that you could use an open source library like Net-SMTP to do the heavy lifting, but you'd still need some experience in developing and building C/C++ libraries.
Use a command-line tool
The easiest solution is probably to use one of the free SNMP command-line utilities from Net-SMTP or SnmpSoft, for example. All you have to do is to call one of these programs using flash.desktop.NativeProcess providing the correct arguments and then parse the output.

Thermal Printer interfacing with the AM1808

I have to interface the thermal Printer with my AM1808 based on the Embedded linux.
I have interfaced a printer having only unidirectional communication, means i need to send only data and no need to receive anything from the printer for verification.
I have my own printer that need the bidirectional communication in which i have to send the data and same way i need to receive something from the printer to verify wether it has successfully printed the data or not.
Yes my printer gets hung when it has printed around 4000 bytes so i have to reinitialize it to empty its inbuild buffer.
Now my question is Once i have configured a UART port. do i have to enable or disable transmission or reception ? means it can work with both the transmission and reception enabled ? How can i do this please help me.
Wether I have to put printer on interrupt. ????
Thank you.
All UART's I've ever worked with have independent tx and rx hardware. Assuming no hardware flow-control enabled, then if you can tx OK, your should be able to rx.
Wether I have to put printer on interrupt? - Well, on a preemptive multitasker, it's usual to use an interrupt driver, (or some variant, eg. DMA with interrupt on completion), yes.
I have interfaced a printer having only unidirectional communication, means i need to send only data and no need to receive anything from the printer for verification.
"... no need to receive anything ..." is probably a faulty assumption.
Your printer should have somekind of flow control to prevent data overrun. Character displays & line printers often can receive the data faster than they can display or print it. These devices use a simple comm protocol that does not have any facility for retransmission of lost data. So there's flow control to notify the host to (temporarily) stop sending data when the device's receive buffer is full.
A EIA/RS-232 serial interface can use either hardware (typically using the CTS control line) or software (embedded data, typically using the XON and XOF characters) for single-ended flow control. Linux serial port drivers and line discipline make flow control invisible to the application program once the serial port is configured.
Yes my printer gets hung when it has printed around 4000 bytes so i have to reinitialize it to empty its inbuild buffer.
This appears to be evidence that you are ignoring whatever flow control the printer is providing, and causing data overrun.
Now my question is Once i have configured a UART port. do i have to enable or disable transmission or reception ?
That's not the salient question. You need to determine what kind of flow control the printer needs, and then implement (i.e. configure) that.

Send and receive data simultaneously on Parallel Port

If I understand the parallel port right, sending data from (D0 to D7) simultaneous, but that it can control the sticks individually?
example:
D0 = Input
D1 = Input
D2 = Output
...
...
...
D7 = Input
would it work?
what I want to do is to both send and receive data simultaneously.
Data wires (D0-D7) are being read or set simultaneously. For various tecniques for bidirectional I/O read the attached articles:
Standard parallel port: http://www.beyondlogic.org/spp/parallel.htm
EPP: http://www.beyondlogic.org/epp/epp.htm
ECP: http://www.beyondlogic.org/ecp/ecp.htm
This site is a good source for programming the parallel port.
The basic idea is that you need a DLL, add-on or library that allows you to access the I/O Ports of the PC. For Windows XP on up you need a specific driver that will allow you do this as the OS doesn't offer access out of the box.
The Parallel port will generally reside at one of three address 278,378, 3BC. This port. have the bytes you are reading or writing.
The (base)+1 port allows access to the status bytes. IE. 279,379, 3BD
The (base)+2 port allows access to the control bytes. IE. 27A,37A,3BE
The parallel port documentation will tell not only how to implement the common modes (like bi-directional) but how to control the port at the byte level to implement your own custom.
Back in the day there was only the standard mode available. You pump out your bytes at the (base) port. Some application, like mine, manipulated individual bits of that ports as form of cheap Digital I/O Controller. We did use the status and control bytes as additional inputs and outputs. There were commands you can send to the Parallel Port chip configure the modes precisely.
Today there are are hundreds of sites with example of using the Parallel Port to solve all kinds of problems. I would be surprised that one of doesn't have something you can use for you specific application.
Again the book I recommend starting with is Parallel Port complete. It tells just about everything you need to start with. If your application is too esoteric for that book it will give a springboard from which you can find the exact setup you need.
Of course by sending a number that has just the required bit set (2n) you'd get the expected result.
I'm not sure about bidirectional access though. I guess it's achieved by using control pins along with the data pins but that's just a guess.
Parallel ports doing EPP or ECP only allow D0-D7 to be all input or all output. Trying to do otherwise may fry your hardware.
See http://www.nor-tech.com/solutions/dox/ieee1284_parallel_ports.pdf, page 6.
However, parallel ports have several control lines that may be useful if you only need a small amount of input/output in the "other" direction.
I believe its bit 5 in the port's control register (base address + 2) that switches direction. (no hardware line attached)