Printable View
Hello, I need to interface my PIC with a dollar bill acceptor. The protocol is MDB. I have seen this project done with an AVR (I have purchased the product.. ) and the hardware looks pretty trivial.. But for the software, that is another story with the unstandard bit stream (start bit, 8bits, addressing bit, stop bit)
Has anyone worked on a project like this?
Any help would be great!!
thanks-Lee
I just found a schematic.. Now all that is needed is software :/
Does anyone know how to allow 9600, 1start,8data,1special data,1stop traffic?
I guess I might have to do some bit banging.. but that will not be to bad
thanks! Lee
Hello Trend,
Trend>>Does anyone know how to allow 9600, 1start,8data,1special data,1stop traffic?<<
Ouch... I haven't worked with that...11 bit.
The only thing I could suggest, is Scope it, and do the timing from there.
Dwayne
Whoops, I think i ment 9 data bits... Just one more than normal
Sorry for the confusion... Or would that just equal out to be 11bits after you add in stop and start?
thanks-Lee
Lee, All you need to do is use 8 bits and parity. You just need to define either HSER2 _ODD or EVEN or, SER2_ODD or EVEN. this will give you 1 start bit, 8 data bits, 1 parity bit and 1 stop bit for a total of 11. I am not sure if the 9th bit is used for data or if it's used for parity in your situation. If it is used for data rather than parity you will have to manipulate it using the uart registers.
HTH
Dave Purola,
Hello Trend,
If it is 8 bit with parity like Dave said (Thanks Dave! I was thinking it was a actual 11 bit with a standard 8bit baud transmisstion. Since I have never worked with one, I figured it has some added security features of somekind.), you will need at least a 8 mhz Crystal. 4 mhz is no guarantee a solid connection. though at *times* you can get 9600 baud out of a 4mhz chip, I wouldn't count my chickens before they hatch.
Your command would be something like:
Pin1 var GPIO.1
Input var byte
SERIN Pin1,N9600,Input
or
SERIN Pin1,T9600,Input
the "N" inverts the data. Since I do not know how the data is coming out of the device. Look at Serin and Serin2 commands. You have even and odd parity too... on Serin2
Dwayne
Actually it is 8bits plus one data bit..
This data bit signifies who is talking on the bus.. And sometimes other things.
any ideas?
thanks-Lee
The MODBUS protocol says that;
1 start bit , 8 data bit, 1 CRC (CheckSum) bit, 1 stop bit.
If you do not use crc in your system you have to use this bit as stop bit and in this case you will have two stop bit.
ERO
I didn't think modbus = MDB.
mdb = vending protocol...
Anyone want to prove me wrong??? Hopefully I am wrong.
thanks guys!
Hi Trend, had you any success with your project to connect a MDB bill acceptor to a PIC?
I'm running in the same situation and I think the additional bit after the 8th data bit could be a problem because IT IS NOT a parity bit. It is a basically a flag.
For who wish to help on that, I'll report what the official documentation said about the MDB protocol:
Baud rate: 9600 NRZ
Serial bit format:
1 start bit
8 data bits
1 MODE BIT
1 stop bit
Total: 11 bits
MODE BIT: Master-To-Peripheral
"The Mode bit differentiates between ADDRESS bytes and DATA bytes. ADDRESS bytes must be read by all peripherals, DATA bytes are only read by the peripheral that has been addressed".
"The MODE BIT is set (logic one) to indicate an ADDRESS byte, and not set (logic zero) to indicate a DATA byte".
MODE BIT: Peripheral-To-Master
"The MODE bit must be set on the last byte sent when data is sent from a Slave to the Master".
Any idea?
Thank you a lot.
mikebar , Look at post number 5......
Dave Purola,
N8NTA
Thank you Dave.Quote:
Originally Posted by Dave
Actually the 9th bit it is really NOT a parity bit, for that protocol. Is is used as a flag in different moments.
What I'm trying to do is a Master (that in the MDB documentation is called V.M.C., that means Vending Machine Controller).
So, a Master has to send a "message" to a "slave" indicating, in the first byte, the address and then the serial message has to continue sending eventually any "DATA".
So, the schema should be:
- send the slave's address with the 9th bit set
- eventually start sending data with the 9th bit cleared.
When the slave answer, then the 9th bit assume another meaning at the VMC side: it has to be cleared while the answer's bytes are sent from the slave and then on the LAST byte it has to be set. This will help the VMC understand the transmission is finished.
So, the questions are:
- should I manipulate the TX9D register BEFORE use some HSEROUT?
- If I'll write to the TX9D register despite the "Define HSER_EVEN 1", will the HSEROUT command use the content of the TX9D register in the way I wish?
- when I'll go to receive some message, will HSERIN load the content of the RX9D register in the proper way?
...or just I can't use any HSERIN/HSEROUT for that purposes?
I'm sorry for that questions that looks silly, but it is the first attempt to that world and I'm trying to find some help that put a light over a more than 350 pages of documentation about that MDB protocol...
Thank you for your help.
Mikebar, I dont use the Hserout or Hserin commands in any of my code. I truly do not know how MELabs handles the parity bit in its implementation of there code. The uart register TXD9 is for setting the bit manually. It is upto the programmer to set this bit and to interpret the RXD9 bit after reception. I have done this in the past, using it for the same purpose as you have discribed. I would suggest maybe looking at Darrels DT_INTS routines and use the hardware uart and place it into the 8 bit w/parity mode then set the TXD9 bit to your liking.. Same thing on the receive side of things.. I would however try the implementation you described in your last post and see if you can set the TXD9 bit just before the Hserout command and then see if it sticks...Quote:
Originally Posted by mikebar
Dave Purola,
N8NTA
Ok, thank you Dave.Quote:
Originally Posted by Dave
I'll go on studying the MDB documentation (as said more than 300 pages). As soon I can I'll buy some MDB client device (like a bill acceptor) and wire-up some circuit to test it.
If, in the meanwhile, you have some idea to test it will be really appreciated.
mikebar, What I would do if I were you is: wire up 2 pic's connected the same way you discribe in post #10 and write the code to do the exact same thing. One of the pic's would be the master and one pic would act as the bill exceptor. Then see if it works....
Dave Purola,
N8NTA