SCI Parity GT16A

[Geezer]

Enabling parity on this beast requires that the SCI be placed into 9-bit mode, parity enabled, parity type selected. Fine.

I imagine that on receive the SCI shifts in the proper parity value into SCIxC3 bit R8.

However a full chip simulation run shows that bit T8 is not automatically computed/set on a transmit, simply by loading SCIxD. I don't know if I should trust the simulator. But if true that means that my code will have to compute the parity bit, set T8, then load SCIxD.

Is this a true picture? Alas I'm away from the hardware today and can't run any experiments.

Al, a no-parity guy by inclination. But one must deal with marketing...

[peg]

Hi Al,

The hardware parity generator possibly calculates the parity bit by examining the bits as they shift out, generating the parity bit "just in time" and this may not be visible in the simulator.

Indeed it may never actually be in the register.

Just a thought

Regards

Peg

[Geezer]

Peg-

Not a bad thought... but then one has to wonder why the T8 bit even exists. One possibiliy is in support of a no-parity-9-bit protocol, but who would do that to themselves? :smileyhappy:

g'day
Al

[rocco]

Hi, Al:

I have used parity a lot in the GP32s, and as Peg hypothesized, the parity bit does not show up in T8. If you want to see it, you need a scope

---

Geezer wrote:
. . . but then one has to wonder why the T8 bit even exists. One possibility is in support of a no-parity-9-bit protocol, but who would do that to themselves? :smileyhappy:

---

Yep, it's there to support the old Intel "ninth address-bit ugly" protocol. You can put the receiver to sleep, and it will only wake up when the received ninth is a one, indicating an address byte.

Who would do that to themselves? marketing.

[bigmac]

Hello Al and others,

Yet another variation of serial format - if the serial data consists entirely of standard 7-bit ASCII characters, the transmission might consist of 7-bits plus parity, a total of 8 bits per character.  This usage of the parity bit is probably more common than 8 bits plus parity.  With this setup for the SCI, the parity bit would be at the bit 7 position.  I would guess that you still wouldn't observe the send parity bit during simulation.

And what about the choice of one or two stop bits ...

Regards,

Mac

[Geezer]

Hiya, Mac-

Combing through the docs for the 5th time...
- parity generation is hardware-generated, hardware checked. The boys were right, bit8 wouldn't bother with an update when xmitting, simulation or BKPT wouldn't show the true value.
- if parity is enabled the MSBit is ALWAYS read/set as parity. If 8-bit mode is selected then one is limited to 7-bit ASCII as you suggest, bit7 is used as par.
- the block diagram shows the TX/RX shifter as 11 bits max, hence STOP bit length is FIXED at one (1.5 and 2 not supported.) None of the control registers address this issue. Neither do they address the peculiar parity types, SPACE or MARK. If the remote receiver has to have that kind of stuff then it's coding time!

I'll know more before Thursday football.

Thanks, all.
Al

[Geezer]

AS advertised the parity bit is handled automatically, generated upon TX, checked upon RX. User code does not have to fiddle with it. EXCEPT: the service code (poll or interrupt) MUST read SCIxC3_R8 else the buffer full flag will remain set, a bad thing.

The MCU was tested by chatting with a custom XP PRO .NET program, C#, using Micro$oft's built-in serial component.

Al

[Geezer]

Thanks, rocco, peg...

My dev system will arrive shortly, "just in time" to ruin the holidays. Alas I forgot to ask for the scope but there are other ways to catch that bit. Results TBD.

Marketing? Cause grief and pain to themselves? NEVER !!! To others, each and every time. :smileywink: Just go to one of their health clubs, instead of punching bags you'll find 'inflatable engineers'. Scientific research shows that they then stay longer.

Al