Bit-banging: is it the 'only' way?
Yes, I'm a newcomer :D and I've sort-of searched the relevant sections. The difficulty is, of course, determining the content of the threads from the title and having to 'view' each and every post (where there is a suitable reply/content that is).
So, if I have missed the answer by not being sufficiently thorough in my searching I do apologise however...... this is probably not 'new' but I'll ask anyway.
If I have a requirement to read serial data of a non-popular format (and here I'm referring to 4800 baud, 1 start, 9 data, 1 stop) i.e. 11-bit data packets, does PBP allow for this? Would I have to 'bit bang' to achieve a proper 'read' of such a serial datastream?
I would prefer to use the '84 PIC rather than one with a built-in UART (which means bit-banging anyway) but if there are any PICs with UARTS that can configure to 9 data bits I'll be happy to be suitably informed.
Similarly, coding examples would be gratefully appreciated.
My interest is to develop test equipment that can read the SEATALK data bus and I'm aiming to make a simple LCD blackbox to offer signal diagnosis of the SEATALK bus (I'm always haviing to attend to SEATALK errors on yacht instruments and would like to have a portable 'reader' to display signals/errors).
The hardware is the easy bit.
I have already reviewed Thomas Knaufs excellent disassembly of the SEATALK protocol and I know of some sites selling ready-made readers/NMEA converters but my ultimate aim is for this specific piece of stand-alone test equipment which would, if I could developed it myself, further improve my understanding of the SEATALK bus principles and allow me to incorporate routines that would further simplfy fault diagnosis of the SEATALK bus.
As a start, therefore, I am looking for code to read the serial data and display the sentences in the simplest format possible.
Has this been approached on this forum before? or has anyone any relevant experience, coding or links that would assist?
Many thanks for taking the time to review my post.
Dave
Re: Bit-banging: is it the 'only' way?
So is the SeaTalk protocol similar to RS-485? Where the 9th bit is used to define data versus address? The PIC EUSART supports 9 bit serial data and 9th bit address recognition, mainly to support RS-485.
Re: Bit-banging: is it the 'only' way?
Quote:
So is the SeaTalk protocol similar to RS-485?
No, RS-485 is a multi-drop whereas the Seatalk bus is similar to RS-232 as far as voltage levels are concerned but devices on the bus can 'talk' at anytime - collision detection being a case of abandoning the currently-transmitting (or receiving) packet and waiting a 'random' interval before trying again if the bus is in conflict (i.e detection of erroneous characters would be one example for 'abandonment').
The 9th data bit is a 'command' ('set' on the first character of a packet but subsequently 'cleared') and sort-of fits the parity bit in a standard serial comms stream - certainly for 'position'. In terms of readability one could configure the serial port (UART) for 8-bit plus parity and somehow read-but-ignore the fact that it is supposed to be a parity bit but instead just read it and treat it as the indicator of a 'command'. Not sure if a UART would permit this as defining it as a parity bit would constantly create errors as the parity wouldn't be corect on most characters received.
I shall download the PIC EUSART datasheet for a shufty.... thanks for the pointer.
Re: Bit-banging: is it the 'only' way?
Reading from PIC 16F877, p97 of USART section:
Quote:
TX9: 9-bit Transmit Enable bit
1 = Selects 9-bit transmission
0 = Selects 8-bit transmission
TX9D: 9th bit of Transmit Data, can be parity bit
Legend:
R = Readable bit
W = Writable bit
U = Unimplemented bit, read as
‘0’
- n = Value at POR
’1’ = Bit is set
’0’ = Bit is cleared
x = Bit is unknown
Re: Bit-banging: is it the 'only' way?
A little more on p. 101:
Quote:
Parity is not supported by the hardware, but can be implemented in software (and stored as the ninth data bit).
Quote:
In order to select 9-bit transmission, transmit bit TX9 (TXSTA<6>) should be set and the ninth bit should be written to TX9D (TXSTA<0>). The ninth bit must be written before writing the 8-bit data to the TXREG register. This is because a data write to the TXREG register can result in an immediate transfer of the data to the TSR register (if the TSR is empty). In such a case, an incorrect ninth data bit may be loaded in the TSR register.
So it seems as if you can use the 9th bit for your use, unless I missed something.
Re: Bit-banging: is it the 'only' way?
This is from the 14 bit core library . . .
Code:
;****************************************************************
;* Default hardware serial port values *
;****************************************************************
ifndef HSER_BITS
HSER_BITS = 8 ; Default to 8 bits
endif
ifndef HSER_RCSTA ; Receive register data
if (HSER_BITS != 9)
HSER_RCSTA EQU 90h ; Receiver enabled
else
HSER_RCSTA EQU 0d0h ; Receiver enabled for 9 bits
endif
endif
ifndef HSER_TXSTA ; Transmit register data
if (HSER_BITS != 9)
HSER_TXSTA EQU 20h ; Transmitter enabled
else
HSER_TXSTA EQU 60h ; Transmitter enabled for 9 bits
endif
endif
ifndef HSER_BAUD ; Baud rate
HSER_BAUD EQU 2400
endif
ifndef HSER_SPBRG ; Baud rate generator register data
if (OSC == 3)
if (((HSER_TXSTA) & 04h) == 0)
HSER_SPBRG = (((3579545 / (HSER_BAUD)) + 32) / 64) - 1 ; For BRGH = 0
else
HSER_SPBRG = (((3579545 / (HSER_BAUD)) + 8) / 16) - 1 ; For BRGH = 1
endif
else
if (((HSER_TXSTA) & 04h) == 0)
HSER_SPBRG = ((((1000000 * (OSC)) / (HSER_BAUD)) + 32) / 64) - 1 ; For BRGH = 0
else
HSER_SPBRG = ((((1000000 * (OSC)) / (HSER_BAUD)) + 8) / 16) - 1 ; For BRGH = 1
endif
endif
endif
ifdef HSER_EVEN
HSERPARITY_USED = 1 ; Parity used if even
endif
ifdef HSER_ODD
HSERPARITY_USED = 1 ; Parity used if odd
endif
;****************************************************************
You might modify to achieve what you want, save an unaltered copy or make up an include file.
Re: Bit-banging: is it the 'only' way?
Sorry for the lengthy delay in replying.
I've downloaded the 16F877 datasheet and obtained a couple of units for experimentation - this seems to be the ideal solution and I thank you all for your imput.
best wishes
