I'm a little confused about the parity bit used with serial communications. I understand why it's used and I understand how to use it. I have a device which uses 1 start bit, 8 data bits, even parity bit, 1 stop bit. I know the picaxe adds the start bit and stop bits automatically and doesn't use a parity bit. If I have a device that uses even or odd parity, can I still communicate with it? Will the picaxe just ignore the parity bit while receiving data?
Question about parity
- Thread starter Schu1212
- Start date
If you send a byte with parity to a device not expecting it you will get a framing error on average 50% of the time (depending on the nature of your data). The receiving device will test the 9th bit expecting to see a 1 (the stop bit), if it sees a 0 it will raise a framing error flag somewhere and/or generate an interrupt.
The question is what does the Picaxe do about that, the manual doesn't state what happens. Hopefully one of the resident Picaxe experts will know.
In general though with a micro you should be able to ignore the error flag and conduct business as usual (not best practice but should work, of course if you get a real framing error you won't detect it).
The question is what does the Picaxe do about that, the manual doesn't state what happens. Hopefully one of the resident Picaxe experts will know.
In general though with a micro you should be able to ignore the error flag and conduct business as usual (not best practice but should work, of course if you get a real framing error you won't detect it).
Last edited:
Chavaquiah
Senior Member
What Picaxe will you be using?
I ask because I know some Picaxes with UARTs can be convinced to transmit a parity bit. I assume (withouth really knowing) that they can also receive. This would involve SFRing a configuration register or two. Time to hit the Microchip datasheets...
Otherwise, if you can guarantee that only one byte shall be transmitted at a time and with enough pauses between transmissions, it might work. Probably not very reliably. As graynomad pointed out, the parity bit may fool the Picaxe into thinking a new byte is just arriving.
I ask because I know some Picaxes with UARTs can be convinced to transmit a parity bit. I assume (withouth really knowing) that they can also receive. This would involve SFRing a configuration register or two. Time to hit the Microchip datasheets...
Otherwise, if you can guarantee that only one byte shall be transmitted at a time and with enough pauses between transmissions, it might work. Probably not very reliably. As graynomad pointed out, the parity bit may fool the Picaxe into thinking a new byte is just arriving.
I have 20X2, 28X2 or 40X2 picaxe chips on hand, so I could use whichever one would work best. Right now I'm just getting in to the specifications of the equipment and I noticed they are using parity bits and I have never run in to this situation before. I need something reliable so if the picaxe "may" interpret it as a new byte even occasionally is too much error for my project.
My project is just to refurbish an old blackjack machine I got from a friend. Some parts and pieces were broke and I need to replace them with new ones. But in order for the new parts to work I need to design an interface between some boards so it works the way I want it to. I'm basically trying to make the thing playable and cheat the money in system so I don't have to keep putting money in to play the darn thing. But I also want the option of having to put money in, so receiving and transmitting is what I need to be able to do. Right now I'm trying to make sure it will all work together before I dive in to the project full heartedly
My project is just to refurbish an old blackjack machine I got from a friend. Some parts and pieces were broke and I need to replace them with new ones. But in order for the new parts to work I need to design an interface between some boards so it works the way I want it to. I'm basically trying to make the thing playable and cheat the money in system so I don't have to keep putting money in to play the darn thing. But I also want the option of having to put money in, so receiving and transmitting is what I need to be able to do. Right now I'm trying to make sure it will all work together before I dive in to the project full heartedly
The sequence of events should go like this when Rxing to the Picaxe.
At point A the receiver will test for a stop bit and 50% of the time get a low parity bit instead of a high stop bit. As mentioned before this may or may not be a problem with the Picaxe in question and it probalby really needs a Picaxe techo to answer because it will depend on the way the chip has been programmed.
As for reliably receiving the next byte, that should be OK as it shouldn't test again until half way through the following bit (point B) and this is garanteed to be a high stop bit which will be read as an idle state. The first time a new start bit can appear is after that, the receiver will detect the falling edge, sample for a start bit at point C and read the following byte OK.
At point A the receiver will test for a stop bit and 50% of the time get a low parity bit instead of a high stop bit. As mentioned before this may or may not be a problem with the Picaxe in question and it probalby really needs a Picaxe techo to answer because it will depend on the way the chip has been programmed.
As for reliably receiving the next byte, that should be OK as it shouldn't test again until half way through the following bit (point B) and this is garanteed to be a high stop bit which will be read as an idle state. The first time a new start bit can appear is after that, the receiver will detect the falling edge, sample for a start bit at point C and read the following byte OK.
Last edited:
Chavaquiah
Senior Member
With X2 parts, I think you're in luck. They have a hardware Enhanced USART and can, at least theoretically, be programmed to receive 9 bits messages. You'd have to be using HSERIN and at some point POKE $18, %x1xxxxxx, ie, set bit 6 of RCSTA.
See westaust55's PICAXE Memory Map and SFR Details Chart for address details.
See westaust55's PICAXE Memory Map and SFR Details Chart for address details.
hippy
Ex-Staff (retired)
Parity bits appear to have no affect on data read using SERIN and SERRXD as these are software bit-banged operations. I haven't exhaustively tested operation. SERIN and SERTXD will just read the 8 bits of data, ignore the parity, bit whether correct or not.
Hiardware serial can be configured to use and expect parity by poking SFR's as suggested. There should be example code for this on the forum. I am not sure exactly how the hardware serial behaves and the outcome when received data has incorrect parity. In most cases parity will be correct so it may not actually be an issue, and there may be additional means to determine that a data packet was incorrect.
If you need to transmit with parity you will have to use hardware serial. The PICmicro can send a parity bit but has no means of calculating it automatically; you will need to send a byte at a time and calculate the parity bit value before each transmission. This should be fairly easy on the X2 using the Number Of Bits (NOB) command.
Hiardware serial can be configured to use and expect parity by poking SFR's as suggested. There should be example code for this on the forum. I am not sure exactly how the hardware serial behaves and the outcome when received data has incorrect parity. In most cases parity will be correct so it may not actually be an issue, and there may be additional means to determine that a data packet was incorrect.
If you need to transmit with parity you will have to use hardware serial. The PICmicro can send a parity bit but has no means of calculating it automatically; you will need to send a byte at a time and calculate the parity bit value before each transmission. This should be fairly easy on the X2 using the Number Of Bits (NOB) command.