Bit banging reliable and RS485 protocol

[mr Clauds]

Hey guys...

Firstly thanks to all those that have helped me where I got stuck...
I have managed to implement what I have learnt and made a system for my workplace that makes my life easier

now onto bigger projects

1stly im struggling to find chips locally with 2 x UART's... I need data from rs232 barcode scanner and input from keypad teminal to send over rs485 to a far away pc...
UART 1 = RS232
UART 2 = RS485

How reliable is bit banging?
Would it be better for me to source a PIC with 2 x UART's, use 2 small PIC's with 1 x UART each, communicating with eachother or bit bang?

2ndly, I've had success with RS232 comms as there are planty tutorials on it, but am finding it a little harder to find a good RS485 tut, does anyone know of one?
RS485 as half duplex, would it be smarter to implement it as USB protocol where the one driver goes and requests info from each terminal?

I've read some modbus, but since i'm still quite a beginner, I found the jump a little too big for me to digest...

Lastly, I've seen the max232 chip can cope with 2 x rs232 ports from same uController Rx and Tx. Would the data sent be the same on both ports?

Thanks in advance
Clauds

 

[Mr RB]

You can send bit banged serial very reliably and easily, using timer delays for each bit.

Receiving bit banged serial is much harder as your PIC must be ready at all times to detect the start of incoming serial data, or you must use an interrupt etc to detect the start of incoming data.

In your application, reading barcode serial it should be fairly easy. I would use the serial port on the important received data (probably the scanner) and use bit banged serial to send data out to the PC. Both serial budrates will probably be pretty low.

 

[mr Clauds]

Thanks Mr RB

Would it be easier to implement bit banging or multiple microcontrollers with 1 x UART each communication with one another?

Just realised im going to need a third device input for thr RFID reader...
Since it's near impossible to get 2 UART PIC's here, never mind three...Ill have to go with bit banging...

Was thinking this:
The employee will have to scan his card first, so maybe use that UART to check for the scan and bit bang that data via rs485 to pc and wait for data from pc...
Then have the pic prog enter a loop waiting and reading data from scanner, and once again bit bang via rs485 and wait for data back from pc...

Using 9600 8N1

Does anyone see a potential problem with this?

Thanks
Clauds

 

[Mr RB]

Yes I think using multiple PICs just compounds your problem as the PICs need to communicate with each other.

Please provide more details about the serial comms;
1. does the scanner just OUTPUT serial?
2. at 9600 baud?
3. does the scanner only send a data packet when it gets scanned? or constant output?
3. for the PC you send data to it? (at 9600?)
4. the PC sends a serial data packet back?

I would be tempted to use a pin change interrupt to detect the scanner serial output, then bit bang receiving the data from the scanner. At 9600 baud and a 20MHz PIC 16F you get 520 instructions per baud, so that's pretty easy. Then use the hardware USART to do the bidirectional comms with the PC later.

 

[mr Clauds]

Thanks for the response...

Basically...

Each terminal will have :
LCD screen
Keypad
RFID reader
Barcode scanner
RS485 interface
barcode scanner and keypad will not be active until the correct proceedure...


1. A LCD will ask for RFID scan. The employee will use his RFID card and it will sent to PIC via RS232 (the microcontroller will be in a loop waiting for RFID; the scanner interface is RS232 and will output only).

2. As soon as PIC recieves it, it will pass info to PC via RS485

3. The PC will verify that the card is valid and store user name in a field, then send a command back to PIC saying user is valid and to activate the barcode scanner (scanner runs on 5 volts and will be powered by pin on chip). The LCD will ask for a barcode scan.

4. Barcode scanner will scan info and send it to PIC (output only) which will then forward it to PC via RS485.

5. PC will store that info as well and then send a command back to PIC to activate the keypad and the LCD will ask for a quantity input

6. Employee will input numbers via the keypad which shows on LCD and hit the hash key to send to PC via RS485

7. System will go back to waiting for RFID data

All this will be done at 9600 since I do not need it any faster, with a 4Mhz crystal

Thanks very much
Clauds

 

[3v0]

Mr RB is doing a great job.

Run the PIC as fast as you can. More cycles to work with means higher baud rates.

 

[Mr RB]

It's an ambitious project but should be quite do-able if you make it in modules that can be tested individually.

It's good that your RFID and barcode will be used at separate times, and only output serial. I think you can bit bang input from those 2 devices with no problems.

Bit banging the input is pretty easy, you can use an interrupt on pin change to detect the start bit, then set TMR1 to overflow after a 1.5 baud period. At that point you are in the middle of bit0, so you read the bit0 and set TMR1 to overflow after 1 baud period. Then repeat that part another 7 times.

I like to test the baud timings, adjust the period up to the point it stops working and adjust period down until it stops working, then use a value right in the middle of the "safe" zone.

Anyway, good luck with it!

 

[mr Clauds]

Thanks so much for all the guidance...

Just a few last questions please...
Im writing in Assemly code...

1. Would it be better to big bang - receive bits for each byte and then store bytes in a sequential registers until completion of data, and only then Tx each register out? Or Recieve a byte and instantly put it on Tx?

2. Would I have enough time in PIC instruction cycles to recieve and store or send bits with 1 stop bit?

3. I'm struggling to figure out the coding in assembly to do the same in vb:

For i = 1 to 'EOT' (End of Transmision) do
'read port'
register(i) = 'recieved byte'
next

Basically, how do you setup and code so that registers automatically increment to recieve each byte for the duration of the data (data isn't always the same length)

Thanks very much
Claudio

 

[Mr RB]

Hmm, ok I'll try to answer but some of these things you will need to make some hard decisions on how you want to do each task, then do the code for each task.

1. I think so, receive all the data from the scanner and when you have it then send to PC.
2. Sure. Like I said at 20MHz xtal you get 520 PIC instructions per incoming BIT.
3. I can't help with the VB side, maybe someone else can help.
4. That's a good question. Basically these are initial design decisions. You need to decide what it is going to do, then break that into modules or tasks and make code for each module.

I can't make the decision for you, but a logical choice would be to have an array of memory large enough to hold the *longest* string you will ever get from the scanner. I'm assuming it's just a handful of bytes.

Then you would load all the incoming bytes into that string, byte after byte, and have another memory variable that keeps count of how many bytes are in the string.

Then when you have the whole string, send it to PC and wait for any confirmation back from the PC.

The more information you provide the easier people can help you, for instance you could have said how many bytes come from the scanner etc.

 

[OlPhart]

Gotta poke my "tuppence"... other flavors of uC (Freescale+) have multiple serial intf (UART) built in. RS232/RS485 are signaling conventions, not related to protocol.
I still will sometimes bit-bang either serial and/or I2C, just because main code & interrupt structures can get "interesting". Good Hunting... <<<)))

 

[mr Clauds]

Thanks very much, I will go and learn more about arrays in assembly. Have a hole in that bit of knowledge. Thanks for all the help guys. I'll try sort myself out from here. Thanks again