Hi Neil.

14-Nov-03 11:29:00, Neil Heller wrote to Jasen Betts


 RS>> I'm not following you here...  He is describing a system that is
 RS>> based on a 12 bit word.

 NH> I thought that the size of a word was non-changing:  2 bytes.  How
 NH> about the size of a short?  Is that _always_ half the size of an
 NH> int?  I was under the impression that the only varying description
 NH> was that of int.

no, turboc C 2.0 has ints and shorts the same size. (16 bits)

All that's guaranteed in the standard is that shorts will be no bigger than
ints and that ints will be no bigger than longs - they could all be the
same size.  (the standard may also say that chars will be no bigger than
shorts)

is software discussions "word" generally means the width of the processors
internal data bus... but us 80*86 users havs stuck with the definition that
the 8088 used (16 bits) even though 386 and later processors had wider
word-sizes.

 JB>> I thought he was describing a need to split up a datastream
 JB>> coinsisting of concatenated 12 bit BCD values I assumed he was
 JB>> doing that in 8 bit hardware.

 NH> You've almost got it right... the values displayed on the face of
 NH> the meter (with LCD displays) were stored and transmitted in BCD.
 NH> The interval values (power usage for a particular location for a
 NH> particular period of time [interval]) were stored and transmitted
 NH> as a stream of 12-bit values.

 NH> The processor (and the OS, I assume) in the meter was 16-bit.

bit-counting an operating system is generally meaningless,
(bit-counting applications even more so)

 JB>> the second question I thouight referred to splitting a single
 JB>> byte in half using sscanf.

 NH> That's exactly correct.  Is there any way of doing that without
 NH> using shifting and/or masking?

 you could use a lookup table  splitting a single byte is easiest to code
 using bitwise oprtations, but converting BCD to binary may be most
 effficient using a lookup table.

 RS>> when received at the 8 bit byte machine the stream would flatten
 RS>> out like this...

 RS>> 11010000 00011001 01000001 11001100 00011101 00000001

 JB>> Not if a synchrionous link was used.

 NH> Why is that?

 on re-looking I think RS was describing a synchronous link...

 NH> I thought that from the end-user-machine's point of
 NH> view there is no difference between sync and async.  In fact, the
 NH> only appreciable difference is in frame formation.

if you put eight 6-bit symbols into a synchronous link you can get six 8-bit
symbols out the other end.

with an async link each symbol is transmitted separately.

I think it was an example of how messy it could get....

 -=> Bye <=-

---