Seeking Advice on New Project

[vne147]

All,

I was hoping that you could provide me with some advice and guidance on a project I’ll be starting soon. I’m building a device that I will connect in between a POS (point of sale) computer and a receipt printer. The idea is that whenever the POS computer tries to print a receipt, this box will intercept it and send it to a remote server via the internet. Based on some separate software I’m developing, after a few seconds the remote server will reply to the device. Depending on the response, the device will either send the data on to the receipt printer or not.

The box will have a DB-9 connector for RS-232 input from the POS computer, a DB-9 connector for RS-232 output to the receipt printer, a WiFi board from MikroE (I haven’t decided which one yet), and a MicroSD card.

A slightly more detailed explanation of the overall concept follows (refer to the diagram):

1. Once a transaction completes, the POS will try to send data to the receipt printer so it can print out a receipt but, my device will be in the way. My device will read each byte of data via the first DB-9 connector as it is received from the POS computer. As soon as it is received, The MCU writes it to a file on the MicroSD card.
2. Once the POS computer has completed sending all the data, the device immediately sends the file from the MicroSD card to a remote server via a WiFi board.
3. After the remote server receives the file and looks at it, 1 of 3 things will happen:
   • a. The remote server will tell the device to not print the receipt.
   • b. The remote server will tell the device to print the receipt and the device will read the original data from the file and send it to the receipt printer via the second DB-9 connector.
   • c. If 3 seconds elapse and no reply has been received from the remote server, the device reads the original data from the file and sends it to the receipt printer via the second DB-9 connector.
4. The device erases the file written to the MicroSD card and waits for the next receipt from the POS computer.

For this project I’m looking at using the PIC18F66J94 because it has 4 built in UART modules. I’ll need at least 3 (2 for the RS-232 and 1 for the MicroSD card) and I may need a 4th depending on which WiFi board I go with. I know I can get UART IC that I can interface to the MCU via SPI but I think it would be simpler to have everything built into the MCU.

So, my questions are:

1. Does anyone see any problems with the concept overall? Will it work? Not work? Is there a better way?
2. Can I use the PIC18F66J94 with the MikroE WiFi library? When I unpacked it, I didn’t see that specific processor in the list.
3. What protocol can I use to send a file to a server from the device? I know this can be done with FTP but I didn’t see any examples for that. I saw examples for HTTP but I’m not sure if I can do file transfer with that. I don’t have a lot of experience with internet protocols. Almost all of my programming experience is embedded and standalone desktop.

Thanks in advance everyone for your help. Please let me know if I need to clarify anything or provide any additional info.

 

[be80be]

First off how big is a transaction.
Next why do two things when you only need to do one.
Look at it like this you unplug the printer hook that cable to the black box that holds the data it buffers the transaction sends a copy to look at which can be https no reason it can't and would be faster way to read it. They look at it click ok the black box sends to the printer the buffered data that would save time in handling the data.

 

[Overclocked]

I always thought SD cards used SPI for communications, not UART. That PIC has 2 SPI modules though.

 

[vne147]

First off how big is a transaction.
Next why do two things when you only need to do one.
Look at it like this you unplug the printer hook that cable to the black box that holds the data it buffers the transaction sends a copy to look at which can be https no reason it can't and would be faster way to read it. They look at it click ok the black box sends to the printer the buffered data that would save time in handling the data.

I'm not sure how big the transaction is. I'm not going to know for sure until I get the receipt printer and start fiddling with it but my gut is that it's pretty small. Probably in the kilobytes range or maybe a couple of megabytes at most. I'm just going off of what receipts look like. Usually it's just a text based list with a logo at the top sometimes.

I'm not sure what you mean by "why do two things..." Are you saying why write it to an SD card when I could just buffer it within the MCU flash? If that is indeed your question then there are two reasons I'm leaning towards that approach.

First, I'm not sure how much data I'll need to buffer. Using an SD card will give me the freedom to increase or decrease the available memory at will.

Second, I'm going to need to include an SD card in the box anyway because I'm planning on having the MCU read the WiFi and remote server info from a text file on the SD card. The person I'm delivering this to won't have the know how or capability to update the firmware when he changes WiFi networks or remote servers. My thought is that he'll just pull the SD card out of the box, plug it into a computer, change the text file making sure to keep the same formatting, and when the box powers up the next time the MCU will read the updated credentials from the SD card.

I always thought SD cards used SPI for communications, not UART. That PIC has 2 SPI modules though.

I'm a little confused by this but admittedly, I haven't really done my homework yet. The SD card expansion boards that MikroE sells do indeed have connections for SPI (MISO, MOSI, CS, etc) but when I downloaded their example code, there were tons of UART function calls.

If I only needed two UART modules and two SPI, that would open up a lot of options for me as far as suitable MCUs. There were only a few 8-bit MCUs with 4 UART modules.


Thank you both for your input. Keep the thoughts coming.

 

[be80be]

It is SPI and its not fast as you may think it is and your going to be slowing it down even more with all stuff you want going on.
You can like I said buffer the data then send it https check it and then print and write the card or what ever you want would get the most speed. Or your going to have some one waiting on the printer for this stuff to get done.

write at very low speeds (ie: roughly 10K-bytes/s at best) per second

 

[vne147]

It is SPI and its not fast as you may think it is and your going to be slowing it down even more with all stuff you want going on.
You can like I said buffer the data then send it https check it and then print and write the card or what ever you want would get the most speed. Or your going to have some one waiting on the printer for this stuff to get done.

I'm a little confused when you say buffer the data. Where do I buffer the data, in the program memory of the MCU? I think the PIC18 family has maybe 128K of program memory at the most. What do I do if the data being sent to the printer exceeds that? Or are you saying I should send each byte to the server via https as soon as it's received?

 

[KeepItSimpleStupid]

That's why hardware and software handshaking exists. In software handshaking, the receipt of a ^S from the printer means stop. The sending of a ^Q from the host means startup again. <Resume any character> is sometimes optional. ^S and ^Q came from the punched paper tape days. ^S and ^Q work in Vt100 emulations as well.

Hardware handshaking uses RTS and CTS. Botched hardware handshaking uses DTR and DSR.

 

[vne147]

That's why hardware and software handshaking exists. In software handshaking, the receipt of a ^S from the printer means stop. The sending of a ^Q from the host means startup again. <Resume any character> is sometimes optional. ^S and ^Q came from the punched paper tape days. ^S and ^Q work in Vt100 emulations as well.

Hardware handshaking uses RTS and CTS. Botched hardware handshaking uses DTR and DSR.

So you're saying that I can have my box lower the CTS bit until I do whatever I need to with the data and raise it again when I'm ready for the next byte?

 

[KeepItSimpleStupid]

The device has to support the flow control. See https://en.wikipedia.org/wiki/Flow_control_(data) for a discussion.

 

[vne147]

The device has to support the flow control. See https://en.wikipedia.org/wiki/Flow_control_(data) for a discussion.

OK, I'll go read that. Thanks for the input.