So perhaps the best solution to my problem is to u-law my 12 bits down to 8 
and then I won't have the 12 bits on an 8 bit channel issue. I'm
sending 
voice BTW. 8ksps should be plenty for that, so after compression, it would be 
64kbs. 

I'll poke around for some u-law code.. I think I have some here somewhere. 

Thanks for the explanation. 
-Micah 

On Sunday 16 January 2005 01:12 pm, onestone wrote:
>  Hi Micah. It really depends a lot on what you are doing. packing 2 x 12
>  bit samples into 3 bytes takes processing time, not a lot if you use
>  registers, but enough. The best answer Depends upon the quality of
>  audio, and the content required. Is the audio music or speech for
>  example? You will need to make sure your input filter is adequate to
>  prevent aliasing. If you are doing voice then I'd A or u-law compand
the
>  12 bit sample to 8 bits, or do something totally different like the
>  single bit voice codec I've posted here. Simply by varying the sample
>  rate you can vary the quality enormously, and it is inherently a 12:1
>  compressor. Sampling voice at 60ksps would give you excellent quality,
>  at 50kbaud data rate. in fact I'd venture a guess (based on real
world
>  tests) that broadcats radio quality music is possible using this
>  technique, at less than the uncompressed 8000sps you would normally
>  employ for voice. At 12 bits thats 96kbps for voice. Stricly speaking
>  music should be sampled around 22ksps minimum, or 262kbps at 12 bit
>  sample size, equivalent to 327.5kbaud compacted but uncompressed.
>
>  Cheers]
>
>  Al
>
>  Micah Stevens wrote:
>  > Hmm.. True it's easier, but not exactly bandwidth efficient.
Currently
>  > I've got quite a bit of overhead, so maybe I can get something
working
>  > that way, but the next revision of product will need to support more
>  > data, so less bandwidth..
>  >
>  > It's for an RF link BTW, hence my bandwidth limitation..
I'm sampling
>  > audio.. so there's a lot of data.
>  >
>  > Speaking of sampling audio, is there an efficient way to oversample
with
>  > the ADC? or should I just up the sample rate and just average the
>  > samples with the CPU? I think it will be a 4:1 oversample. (60Khz
total)
>  >
>  > I'll need to do that eventually as well.. the noise floor is
pretty high
>  > as I have things now.
>  >
>  > -Micah
>  >
>  > On Sunday 16 January 2005 12:37 pm, onestone wrote:
>  >> Just up, or not been to bed yet Kris?
>  >>
>  >> Given that it's C, unless there is an overwhelming need to
keep your
>  >> data compressed it would be easier to send the twelve bits as two
>  >> separate bytes, as they are read from the ADC.
>  >>
>  >> Al
>  >>
>  >> microbit wrote:
>  >> > Hi Micah,
>  >> >
>  >> > Weather still bad up there I here.
>  >> >
>  >> >>Only I'm not sure how to define the adc/spi types.
Is there a way to
>  >> >> define a data type with an arbitrary number of bits in
it? I can't
>  >> >> find any way to do this in my searching.
>  >> >>
>  >> >>
>  >> >>I need a 12 bit type, and an 8 bit type. Actually, 8 bit
is easy
>  >> >> enough, that's a char..
>  >> >
>  >> > Doing it that way you'd need bitfields, I'd say -
some compilers
>  >> > handle unsigned bitfields actually quite well, say, bitfield
[6].
>  >> > The only other way is to shift around of course...
>  >> >
>  >> > No need of course to make sure you don't change
compiler in a hurry,
>  >> > or set it configurable. I;m no expert, but AFAIK Bitorder of
>  >> > bitfields is not guaranteed to overlay in any specifc
consistent way
>  >> > between MCUs ot maybe even different compile settings. Never
really
>  >> > tried that enough.
>  >> >
>  >> > B rgds
>  >> > Kris
>  >> >
>  >> >
>  >> > 
>  >> >
>  >> >
>  >> >
>  >> > .
>  >> >
>  >> >
>  >> > .
>  >
>  > .
>  >
>  >
>  > .

Try the single bit codec in the files section. It works remarkably well 
for voice, and will have far lower data rates. 20ksps gives very good 
quality for just 20kbps. You must pre-filter it anyway. Typically voice 
uses a 3.4-3.5kHz low pass filter, so 8kHz gives you a little 
oversampling, which is good.

Al

Micah Stevens wrote:

> 
> So perhaps the best solution to my problem is to u-law my 12 bits down to 8

> and then I won't have the 12 bits on an 8 bit channel issue. I'm
sending 
> voice BTW. 8ksps should be plenty for that, so after compression, it would
be 
> 64kbs. 
> 
> I'll poke around for some u-law code.. I think I have some here
somewhere. 
> 
> Thanks for the explanation. 
> -Micah 
> 
> On Sunday 16 January 2005 01:12 pm, onestone wrote:
> 
>> Hi Micah. It really depends a lot on what you are doing. packing 2 x 12
>> bit samples into 3 bytes takes processing time, not a lot if you use
>> registers, but enough. The best answer Depends upon the quality of
>> audio, and the content required. Is the audio music or speech for
>> example? You will need to make sure your input filter is adequate to
>> prevent aliasing. If you are doing voice then I'd A or u-law
compand the
>> 12 bit sample to 8 bits, or do something totally different like the
>> single bit voice codec I've posted here. Simply by varying the
sample
>> rate you can vary the quality enormously, and it is inherently a 12:1
>> compressor. Sampling voice at 60ksps would give you excellent quality,
>> at 50kbaud data rate. in fact I'd venture a guess (based on real
world
>> tests) that broadcats radio quality music is possible using this
>> technique, at less than the uncompressed 8000sps you would normally
>> employ for voice. At 12 bits thats 96kbps for voice. Stricly speaking
>> music should be sampled around 22ksps minimum, or 262kbps at 12 bit
>> sample size, equivalent to 327.5kbaud compacted but uncompressed.
>>
>> Cheers]
>>
>> Al
>>
>> Micah Stevens wrote:
>> > Hmm.. True it's easier, but not exactly bandwidth efficient.
Currently
>> > I've got quite a bit of overhead, so maybe I can get
something working
>> > that way, but the next revision of product will need to support
more
>> > data, so less bandwidth..
>> >
>> > It's for an RF link BTW, hence my bandwidth limitation..
I'm sampling
>> > audio.. so there's a lot of data.
>> >
>> > Speaking of sampling audio, is there an efficient way to
oversample with
>> > the ADC? or should I just up the sample rate and just average the
>> > samples with the CPU? I think it will be a 4:1 oversample. (60Khz
total)
>> >
>> > I'll need to do that eventually as well.. the noise floor is
pretty high
>> > as I have things now.
>> >
>> > -Micah
>> >
>> > On Sunday 16 January 2005 12:37 pm, onestone wrote:
>> >> Just up, or not been to bed yet Kris?
>> >>
>> >> Given that it's C, unless there is an overwhelming need
to keep your
>> >> data compressed it would be easier to send the twelve bits as
two
>> >> separate bytes, as they are read from the ADC.
>> >>
>> >> Al
>> >>
>> >> microbit wrote:
>> >> > Hi Micah,
>> >> >
>> >> > Weather still bad up there I here.
>> >> >
>> >> >>Only I'm not sure how to define the adc/spi
types. Is there a way to
>> >> >> define a data type with an arbitrary number of bits
in it? I can't
>> >> >> find any way to do this in my searching.
>> >> >>
>> >> >>
>> >> >>I need a 12 bit type, and an 8 bit type. Actually, 8
bit is easy
>> >> >> enough, that's a char..
>> >> >
>> >> > Doing it that way you'd need bitfields, I'd say
- some compilers
>> >> > handle unsigned bitfields actually quite well, say,
bitfield [6].
>> >> > The only other way is to shift around of course...
>> >> >
>> >> > No need of course to make sure you don't change
compiler in a hurry,
>> >> > or set it configurable. I;m no expert, but AFAIK Bitorder
of
>> >> > bitfields is not guaranteed to overlay in any specifc
consistent way
>> >> > between MCUs ot maybe even different compile settings.
Never really
>> >> > tried that enough.
>> >> >
>> >> > B rgds
>> >> > Kris
>> >> >
>> >> >
>> >> > 
>> >> >
>> >> >
>> >> >
>> >> > .
>> >> >
>> >> >
>> >> > .
>> >
>> > .
>> >
>> > 
>> > .
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

But it's not compatible with a DAC output. I think we went through this 
already. Or at least it wasn't obvious how I could convert the bitstream
back 
into some facsimile of the orignal data. If there was a way to do this, I 
would be interested. 

-Micah 

On Sunday 16 January 2005 04:05 pm, onestone wrote:
>  Try the single bit codec in the files section. It works remarkably well
>  for voice, and will have far lower data rates. 20ksps gives very good
>  quality for just 20kbps. You must pre-filter it anyway. Typically voice
>  uses a 3.4-3.5kHz low pass filter, so 8kHz gives you a little
>  oversampling, which is good.
>
>  Al
>
>  Micah Stevens wrote:
>  > So perhaps the best solution to my problem is to u-law my 12 bits
down
>  > to 8 and then I won't have the 12 bits on an 8 bit channel
issue. I'm
>  > sending voice BTW. 8ksps should be plenty for that, so after
>  > compression, it would be 64kbs.
>  >
>  > I'll poke around for some u-law code.. I think I have some here
>  > somewhere.
>  >
>  > Thanks for the explanation.
>  > -Micah
>  >
>  > On Sunday 16 January 2005 01:12 pm, onestone wrote:
>  >> Hi Micah. It really depends a lot on what you are doing. packing
2 x 12
>  >> bit samples into 3 bytes takes processing time, not a lot if you
use
>  >> registers, but enough. The best answer Depends upon the quality
of
>  >> audio, and the content required. Is the audio music or speech for
>  >> example? You will need to make sure your input filter is adequate
to
>  >> prevent aliasing. If you are doing voice then I'd A or u-law
compand
>  >> the 12 bit sample to 8 bits, or do something totally different
like the
>  >> single bit voice codec I've posted here. Simply by varying
the sample
>  >> rate you can vary the quality enormously, and it is inherently a
12:1
>  >> compressor. Sampling voice at 60ksps would give you excellent
quality,
>  >> at 50kbaud data rate. in fact I'd venture a guess (based on
real world
>  >> tests) that broadcats radio quality music is possible using this
>  >> technique, at less than the uncompressed 8000sps you would
normally
>  >> employ for voice. At 12 bits thats 96kbps for voice. Stricly
speaking
>  >> music should be sampled around 22ksps minimum, or 262kbps at 12
bit
>  >> sample size, equivalent to 327.5kbaud compacted but uncompressed.
>  >>
>  >> Cheers]
>  >>
>  >> Al
>  >>
>  >> Micah Stevens wrote:
>  >> > Hmm.. True it's easier, but not exactly bandwidth
efficient.
>  >> > Currently I've got quite a bit of overhead, so maybe I
can get
>  >> > something working that way, but the next revision of product
will
>  >> > need to support more data, so less bandwidth..
>  >> >
>  >> > It's for an RF link BTW, hence my bandwidth
limitation.. I'm sampling
>  >> > audio.. so there's a lot of data.
>  >> >
>  >> > Speaking of sampling audio, is there an efficient way to
oversample
>  >> > with the ADC? or should I just up the sample rate and just
average
>  >> > the samples with the CPU? I think it will be a 4:1
oversample. (60Khz
>  >> > total)
>  >> >
>  >> > I'll need to do that eventually as well.. the noise
floor is pretty
>  >> > high as I have things now.
>  >> >
>  >> > -Micah
>  >> >
>  >> > On Sunday 16 January 2005 12:37 pm, onestone wrote:
>  >> >> Just up, or not been to bed yet Kris?
>  >> >>
>  >> >> Given that it's C, unless there is an overwhelming
need to keep your
>  >> >> data compressed it would be easier to send the twelve
bits as two
>  >> >> separate bytes, as they are read from the ADC.
>  >> >>
>  >> >> Al
>  >> >>
>  >> >> microbit wrote:
>  >> >> > Hi Micah,
>  >> >> >
>  >> >> > Weather still bad up there I here.
>  >> >> >
>  >> >> >>Only I'm not sure how to define the adc/spi
types. Is there a way
>  >> >> >> to define a data type with an arbitrary number
of bits in it? I
>  >> >> >> can't find any way to do this in my
searching.
>  >> >> >>
>  >> >> >>
>  >> >> >>I need a 12 bit type, and an 8 bit type.
Actually, 8 bit is easy
>  >> >> >> enough, that's a char..
>  >> >> >
>  >> >> > Doing it that way you'd need bitfields,
I'd say - some compilers
>  >> >> > handle unsigned bitfields actually quite well, say,
bitfield [6].
>  >> >> > The only other way is to shift around of course...
>  >> >> >
>  >> >> > No need of course to make sure you don't
change compiler in a
>  >> >> > hurry, or set it configurable. I;m no expert, but
AFAIK Bitorder
>  >> >> > of bitfields is not guaranteed to overlay in any
specifc
>  >> >> > consistent way between MCUs ot maybe even different
compile
>  >> >> > settings. Never really tried that enough.
>  >> >> >
>  >> >> > B rgds
>  >> >> > Kris
>  >> >> >
>  >> >> >
>  >> >> > 
>  >> >> >
>  >> >> >
>  >> >> >
>  >> >> > .
>  >> >> >
>  >> >> >
>  >> >> > .
>  >> >
>  >> > .
>  >> >
>  >> >
>  >> > .
>  >
>  > .
>  >
>  >
>  > .

I believe there is a freely available library from Sun to do u-law.
There must be tons of others.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and now AVR processors   

> -----Original Message-----
> From: Micah Stevens [mailto:micah@mica...] 
> Sent: 16 January 2005 22:42
> To: msp430@msp4...
> Subject: [msp430] Now audio data, was: Union/type help..
> 
> 
> 
> So perhaps the best solution to my problem is to u-law my 12 
> bits down to 8 and then I won't have the 12 bits on an 8 bit 
> channel issue. I'm sending voice BTW. 8ksps should be plenty 
> for that, so after compression, it would be 64kbs. 
> 
> I'll poke around for some u-law code.. I think I have some 
> here somewhere. 
> 
> Thanks for the explanation. 
> -Micah 
> 
> On Sunday 16 January 2005 01:12 pm, onestone wrote:
> >  Hi Micah. It really depends a lot on what you are doing. 
> packing 2 x 
> > 12  bit samples into 3 bytes takes processing time, not a 
> lot if you 
> > use  registers, but enough. The best answer Depends upon 
> the quality 
> > of  audio, and the content required. Is the audio music or 
> speech for  
> > example? You will need to make sure your input filter is 
> adequate to  
> > prevent aliasing. If you are doing voice then I'd A or 
> u-law compand 
> > the
> >  12 bit sample to 8 bits, or do something totally different 
> like the  
> > single bit voice codec I've posted here. Simply by varying 
> the sample  
> > rate you can vary the quality enormously, and it is 
> inherently a 12:1  
> > compressor. Sampling voice at 60ksps would give you 
> excellent quality,  
> > at 50kbaud data rate. in fact I'd venture a guess (based on 
> real world
> >  tests) that broadcats radio quality music is possible using this  
> > technique, at less than the uncompressed 8000sps you would 
> normally  
> > employ for voice. At 12 bits thats 96kbps for voice. 
> Stricly speaking  
> > music should be sampled around 22ksps minimum, or 262kbps 
> at 12 bit  
> > sample size, equivalent to 327.5kbaud compacted but uncompressed.
> >
> >  Cheers]
> >
> >  Al
> >
> >  Micah Stevens wrote:
> >  > Hmm.. True it's easier, but not exactly bandwidth
efficient. 
> > Currently  > I've got quite a bit of overhead, so maybe I can
get 
> > something working  > that way, but the next revision of 
> product will 
> > need to support more  > data, so less bandwidth..
> >  >
> >  > It's for an RF link BTW, hence my bandwidth limitation..
I'm 
> > sampling  > audio.. so there's a lot of data.
> >  >
> >  > Speaking of sampling audio, is there an efficient way to 
> oversample 
> > with  > the ADC? or should I just up the sample rate and 
> just average 
> > the  > samples with the CPU? I think it will be a 4:1 oversample. 
> > (60Khz total)  >  > I'll need to do that eventually as
well.. the 
> > noise floor is pretty high  > as I have things now.
> >  >
> >  > -Micah
> >  >
> >  > On Sunday 16 January 2005 12:37 pm, onestone wrote:
> >  >> Just up, or not been to bed yet Kris?
> >  >>
> >  >> Given that it's C, unless there is an overwhelming need
to keep 
> > your  >> data compressed it would be easier to send the 
> twelve bits as 
> > two  >> separate bytes, as they are read from the ADC.
> >  >>
> >  >> Al
> >  >>
> >  >> microbit wrote:
> >  >> > Hi Micah,
> >  >> >
> >  >> > Weather still bad up there I here.
> >  >> >
> >  >> >>Only I'm not sure how to define the adc/spi
types. Is there a 
> > way to  >> >> define a data type with an arbitrary number 
> of bits in 
> > it? I can't  >> >> find any way to do this in my
searching.
> >  >> >>
> >  >> >>
> >  >> >>I need a 12 bit type, and an 8 bit type. Actually, 8

> bit is easy  
> > >> >> enough, that's a char..
> >  >> >
> >  >> > Doing it that way you'd need bitfields, I'd
say - 
> some compilers  
> > >> > handle unsigned bitfields actually quite well, say, 
> bitfield [6].
> >  >> > The only other way is to shift around of course...
> >  >> >
> >  >> > No need of course to make sure you don't change
compiler in a 
> > hurry,  >> > or set it configurable. I;m no expert, but 
> AFAIK Bitorder 
> > of  >> > bitfields is not guaranteed to overlay in any
specifc 
> > consistent way  >> > between MCUs ot maybe even different
compile 
> > settings. Never really  >> > tried that enough.
> >  >> >
> >  >> > B rgds
> >  >> > Kris
> >  >> >
> >  >> >
> >  >> >  
>  >> >  >> 
> > >  >> >  >> > .
> >  >> >
> >  >> >
> >  >> > .
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 

Yeah, but at least that's 25% wastage by a seasoned programmer.  You
should see what wastage you get from newbies.  ;-) 

> -----Original Message-----
> From: onestone [mailto:onestone@ones...] 
> Sent: 16 January 2005 21:29
> To: msp430@msp4...
> Subject: Re: [msp430] Union/type help..
> 
> 
> 25% wasted storage for 1 variable though ;@}
> 
> Al
> 
> Paul Curtis wrote:
> 
> > 
> > // Send two 12-bit samples x and y packed into 24 bits.
> > void send_two_samples(unsigned x, unsigned y) {
> >   unsigned long data = ((unsigned long)x << 12) + y;
> >   spi_write(&data, 3);  // assumes little-endian addressing 
> of MSP430 
> > }
> > 
> > Simple.  Forget bitfields.  C isn't that crippled.
> > 
> > --
> > Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk 
> CrossWorks 
> > for MSP430, ARM, and now AVR processors
> > 
> > 
> >>-----Original Message-----
> >>From: onestone [mailto:onestone@ones...]
> >>Sent: 16 January 2005 21:15
> >>To: msp430@msp4...
> >>Subject: Re: [msp430] Union/type help..
> >>
> >>
> >>Oh the joys of asm toys ;@}
> >>
> >>Al
> >>
> >>Georg Ritter wrote:
> >>
> >>
> >>>microbit wrote:
> >>>
> >>>
> >>>>Hi Micah,
> >>>>
> >>>>Weather still bad up there I here.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Only I'm not sure how to define the adc/spi types.
Is
> >>
> >>there a way to
> >>
> >>>>>define a data type with an arbitrary number of bits in 
> it? I can't 
> >>>>>find any way to do this in my searching.
> >>>>
> >>>>
> >>>>>I need a 12 bit type, and an 8 bit type. Actually, 8
bit is easy 
> >>>>>enough, that's a char..
> >>>>
> >>>>
> >>>>Doing it that way you'd need bitfields, I'd say -
some compilers 
> >>>>handle unsigned bitfields actually quite well, say,
bitfield [6].
> >>>>The only other way is to shift around of course...
> >>>>
> >>>>No need of course to make sure you don't change
compiler in
> >>
> >>a hurry,
> >>
> >>>>or set it configurable. I;m no expert, but AFAIK Bitorder
> >>
> >>of bitfields
> >>
> >>>>is not guaranteed to overlay in any specifc consistent 
> way between 
> >>>>MCUs ot maybe even different compile settings. Never really
> >>
> >>tried that enough.
> >>
> >>>Yepp I agree, you can do it, but it is not portable and
> >>
> >>platform and
> >>
> >>>compiler depended, so you must be aware and check the
> >>
> >>compiler output
> >>
> >>>everytime things change. I'm still looking for a nice way
> >>
> >>to do it in legal C.
> >>
> >>>"6.7.2.1 Structure and union specifiers" from the c
> >>
> >>standards it says:
> >>
> >>>10 An implementation may allocate any addressable storage
> >>
> >>unit large
> >>
> >>>enough to hold a bit-field. If enough space remains, a
> >>
> >>bit-field that
> >>
> >>>immediately follows another bit-field in astructure shall 
> be packed 
> >>>into adjacent bits of the same unit. If insufficient space 
> remains, 
> >>>whether a bit-field that does not fit is put into the next unit
or 
> >>>overlaps adjacent units is implementation-defined. The order of

> >>>allocation of bit-fields within a unit (high-order to low-order
or 
> >>>low-order to high-order) is implementation-defined. The
> >>
> >>alignment of the addressable storage unit is unspecified.
> >>
> >>>12 Each non-bit-field member of a structure or union object
> >>
> >>is aligned
> >>
> >>>in an implementationdefined manner appropriate to its type.
> >>>
> >>>
> >>>There's a -fpack-struct option for the gcc compiler.
> >>>
> >>>Greetz,
> >>>
> >>>	Georg
> >>>
> >>>
> >>>
> >>>>B rgds
> >>>>Kris
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>.
> >>>>
> >>>>
> >>>>Yahoo! Groups Links
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>.
> >>>
> >>> 
> >>>Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>.
> >>
> >> 
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >> 
> >>
> >>
> >>
> >>
> >>
> > 
> > 
> > 
> > .
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 

The post includes the compressor and decompressor. Combined there are 
just 51 instructions, 28 to compress and 23 to decompress. The default 
output is a speaker with a filter preceeding it, basically a PWM 
circuit, however I don't think it would be too hard to reconvert back to 
12 bit data. Simply assume a start point of 0 (on a +/- scale), so 2048 
on a 12 bit scale and reverse the little predictor routine. You could 
add scaling if you wished or amplify the comparatively low level signal 
you would get around the 0 point.

Al

Micah Stevens wrote:

> 
> But it's not compatible with a DAC output. I think we went through
this 
> already. Or at least it wasn't obvious how I could convert the
bitstream back 
> into some facsimile of the orignal data. If there was a way to do this, I 
> would be interested. 
> 
> -Micah 
> 
> On Sunday 16 January 2005 04:05 pm, onestone wrote:
> 
>> Try the single bit codec in the files section. It works remarkably well
>> for voice, and will have far lower data rates. 20ksps gives very good
>> quality for just 20kbps. You must pre-filter it anyway. Typically voice
>> uses a 3.4-3.5kHz low pass filter, so 8kHz gives you a little
>> oversampling, which is good.
>>
>> Al
>>
>> Micah Stevens wrote:
>> > So perhaps the best solution to my problem is to u-law my 12 bits
down
>> > to 8 and then I won't have the 12 bits on an 8 bit channel
issue. I'm
>> > sending voice BTW. 8ksps should be plenty for that, so after
>> > compression, it would be 64kbs.
>> >
>> > I'll poke around for some u-law code.. I think I have some
here
>> > somewhere.
>> >
>> > Thanks for the explanation.
>> > -Micah
>> >
>> > On Sunday 16 January 2005 01:12 pm, onestone wrote:
>> >> Hi Micah. It really depends a lot on what you are doing.
packing 2 x 12
>> >> bit samples into 3 bytes takes processing time, not a lot if
you use
>> >> registers, but enough. The best answer Depends upon the
quality of
>> >> audio, and the content required. Is the audio music or speech
for
>> >> example? You will need to make sure your input filter is
adequate to
>> >> prevent aliasing. If you are doing voice then I'd A or
u-law compand
>> >> the 12 bit sample to 8 bits, or do something totally different
like the
>> >> single bit voice codec I've posted here. Simply by
varying the sample
>> >> rate you can vary the quality enormously, and it is inherently
a 12:1
>> >> compressor. Sampling voice at 60ksps would give you excellent
quality,
>> >> at 50kbaud data rate. in fact I'd venture a guess (based
on real world
>> >> tests) that broadcats radio quality music is possible using
this
>> >> technique, at less than the uncompressed 8000sps you would
normally
>> >> employ for voice. At 12 bits thats 96kbps for voice. Stricly
speaking
>> >> music should be sampled around 22ksps minimum, or 262kbps at
12 bit
>> >> sample size, equivalent to 327.5kbaud compacted but
uncompressed.
>> >>
>> >> Cheers]
>> >>
>> >> Al
>> >>
>> >> Micah Stevens wrote:
>> >> > Hmm.. True it's easier, but not exactly bandwidth
efficient.
>> >> > Currently I've got quite a bit of overhead, so maybe
I can get
>> >> > something working that way, but the next revision of
product will
>> >> > need to support more data, so less bandwidth..
>> >> >
>> >> > It's for an RF link BTW, hence my bandwidth
limitation.. I'm sampling
>> >> > audio.. so there's a lot of data.
>> >> >
>> >> > Speaking of sampling audio, is there an efficient way to
oversample
>> >> > with the ADC? or should I just up the sample rate and
just average
>> >> > the samples with the CPU? I think it will be a 4:1
oversample. (60Khz
>> >> > total)
>> >> >
>> >> > I'll need to do that eventually as well.. the noise
floor is pretty
>> >> > high as I have things now.
>> >> >
>> >> > -Micah
>> >> >
>> >> > On Sunday 16 January 2005 12:37 pm, onestone wrote:
>> >> >> Just up, or not been to bed yet Kris?
>> >> >>
>> >> >> Given that it's C, unless there is an
overwhelming need to keep your
>> >> >> data compressed it would be easier to send the twelve
bits as two
>> >> >> separate bytes, as they are read from the ADC.
>> >> >>
>> >> >> Al
>> >> >>
>> >> >> microbit wrote:
>> >> >> > Hi Micah,
>> >> >> >
>> >> >> > Weather still bad up there I here.
>> >> >> >
>> >> >> >>Only I'm not sure how to define the
adc/spi types. Is there a way
>> >> >> >> to define a data type with an arbitrary
number of bits in it? I
>> >> >> >> can't find any way to do this in my
searching.
>> >> >> >>
>> >> >> >>
>> >> >> >>I need a 12 bit type, and an 8 bit type.
Actually, 8 bit is easy
>> >> >> >> enough, that's a char..
>> >> >> >
>> >> >> > Doing it that way you'd need bitfields,
I'd say - some compilers
>> >> >> > handle unsigned bitfields actually quite well,
say, bitfield [6].
>> >> >> > The only other way is to shift around of
course...
>> >> >> >
>> >> >> > No need of course to make sure you don't
change compiler in a
>> >> >> > hurry, or set it configurable. I;m no expert,
but AFAIK Bitorder
>> >> >> > of bitfields is not guaranteed to overlay in any
specifc
>> >> >> > consistent way between MCUs ot maybe even
different compile
>> >> >> > settings. Never really tried that enough.
>> >> >> >
>> >> >> > B rgds
>> >> >> > Kris
>> >> >> >
>> >> >> >
>> >> >> > 
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > .
>> >> >> >
>> >> >> >
>> >> >> > .
>> >> >
>> >> > .
>> >> >
>> >> >
>> >> > .
>> >
>> > .
>> >
>> > 
>> > .
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

What I've done a few times in the past when streaming data and size 
mattered was to just send the >>difference<< from the last report.  
In your case, a 7-bit plus sign might work out well.

In most apps with more-or-less continuous conversion there won't be a 
step change greater than the 7 bits.  And if there is, in most apps 
it won't matter if it takes a few samples to "catch up".   

IIRC I used the "-0" value as an escape value to indicate that re-
sync was required.

It doesn't give heavy compression, but is very easy & efficient to 
implement--just save the last value sent, & send the difference this 
time.

Lee

--- In msp430@msp4..., onestone <onestone@b...> wrote:
> 25% wasted storage for 1 variable though ;@}
> 
> Al
> 
> Paul Curtis wrote:
> 
> > 
> > // Send two 12-bit samples x and y packed into 24 bits.
> > void send_two_samples(unsigned x, unsigned y)
> > {
> >   unsigned long data = ((unsigned long)x << 12) + y;
> >   spi_write(&data, 3);  // assumes little-endian addressing of 
MSP430
> > }
> > 
> > Simple.  Forget bitfields.  C isn't that crippled.
> > 
> > --
> > Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> > CrossWorks for MSP430, ARM, and now AVR processors  
> > 
> > 
> >>-----Original Message-----
> >>From: onestone [mailto:onestone@b...] 
> >>Sent: 16 January 2005 21:15
> >>To: msp430@msp4...
> >>Subject: Re: [msp430] Union/type help..
> >>
> >>
> >>Oh the joys of asm toys ;@}
> >>
> >>Al
> >>
> >>Georg Ritter wrote:
> >>
> >>
> >>>microbit wrote:
> >>>
> >>>
> >>>>Hi Micah,
> >>>>
> >>>>Weather still bad up there I here.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Only I'm not sure how to define the adc/spi types.
Is 
> >>
> >>there a way to 
> >>
> >>>>>define a data type with an arbitrary number of bits in
it? I 
can't 
> >>>>>find any way to do this in my
searching.
> >>>>
> >>>>
> >>>>>I need a 12 bit type, and an 8 bit type. Actually, 8
bit is 
easy 
> >>>>>enough, that's a char..
> >>>>
> >>>>
> >>>>Doing it that way you'd need bitfields, I'd say -
some 
compilers 
> >>>>handle unsigned bitfields actually
quite well, say, bitfield 
[6].
> >>>>The only other way is to shift
around of course...
> >>>>
> >>>>No need of course to make sure you don't change
compiler in 
> >>
> >>a hurry, 
> >>
> >>>>or set it configurable. I;m no expert, but AFAIK Bitorder 
> >>
> >>of bitfields 
> >>
> >>>>is not guaranteed to overlay in any specifc consistent way 
between 
> >>>>MCUs ot maybe even different
compile settings. Never really 
> >>
> >>tried that enough.
> >>
> >>>Yepp I agree, you can do it, but it is not portable and 
> >>
> >>platform and 
> >>
> >>>compiler depended, so you must be aware and check the 
> >>
> >>compiler output 
> >>
> >>>everytime things change. I'm still looking for a nice way 
> >>
> >>to do it in legal C.
> >>
> >>>"6.7.2.1 Structure and union specifiers" from the c 
> >>
> >>standards it says:
> >>
> >>>10 An implementation may allocate any addressable storage 
> >>
> >>unit large 
> >>
> >>>enough to hold a bit-field. If enough space remains, a 
> >>
> >>bit-field that 
> >>
> >>>immediately follows another bit-field in astructure shall be 
packed 
> >>>into adjacent bits of the same unit.
If insufficient space 
remains, 
> >>>whether a bit-field that does not fit
is put into the next unit 
or 
> >>>overlaps adjacent units is
implementation-defined. The order of 
> >>>allocation of bit-fields within a unit (high-order to low-order

or 
> >>>low-order to high-order) is
implementation-defined. The 
> >>
> >>alignment of the addressable storage unit is unspecified.
> >>
> >>>12 Each non-bit-field member of a structure or union object 
> >>
> >>is aligned 
> >>
> >>>in an implementationdefined manner appropriate to its type.
> >>>
> >>>
> >>>There's a -fpack-struct option for the gcc compiler.
> >>>
> >>>Greetz,
> >>>
> >>>	Georg
> >>>
> >>>
> >>>
> >>>>B rgds
> >>>>Kris
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>.
> >>>>
> >>>>
> >>>>Yahoo! Groups Links
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>.
> >>>
> >>> 
> >>>Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>.
> >>
> >> 
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >> 
> >>
> >>
> >>
> >>
> >>
> > 
> > 
> > 
> > .
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> >

Hey! I represent that! 


On Sunday 16 January 2005 04:47 pm, Paul Curtis wrote:
>  Yeah, but at least that's 25% wastage by a seasoned programmer. You
>  should see what wastage you get from newbies. ;-)
>
>  > -----Original Message-----
>  > From: onestone [mailto:onestone@ones...]
>  > Sent: 16 January 2005 21:29
>  > To: msp430@msp4...
>  > Subject: Re: [msp430] Union/type help..
>  >
>  >
>  > 25% wasted storage for 1 variable though ;@}
>  >
>  > Al
>  >
>  > Paul Curtis wrote:
>  > > // Send two 12-bit samples x and y packed into 24 bits.
>  > > void send_two_samples(unsigned x, unsigned y) {
>  > > unsigned long data = ((unsigned long)x << 12) + y;
>  > > spi_write(&data, 3); // assumes little-endian addressing
>  >
>  > of MSP430
>  >
>  > > }
>  > >
>  > > Simple. Forget bitfields. C isn't that crippled.
>  > >
>  > > --
>  > > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>  >
>  > CrossWorks
>  >
>  > > for MSP430, ARM, and now AVR processors
>  > >
>  > >>-----Original Message-----
>  > >>From: onestone [mailto:onestone@ones...]
>  > >>Sent: 16 January 2005 21:15
>  > >>To: msp430@msp4...
>  > >>Subject: Re: [msp430] Union/type help..
>  > >>
>  > >>
>  > >>Oh the joys of asm toys ;@}
>  > >>
>  > >>Al
>  > >>
>  > >>Georg Ritter wrote:
>  > >>>microbit wrote:
>  > >>>>Hi Micah,
>  > >>>>
>  > >>>>Weather still bad up there I here.
>  > >>>>
>  > >>>>>Only I'm not sure how to define the adc/spi
types. Is
>  > >>
>  > >>there a way to
>  > >>
>  > >>>>>define a data type with an arbitrary number of
bits in
>  >
>  > it? I can't
>  >
>  > >>>>>find any way to do this in my searching.
>  > >>>>>
>  > >>>>>
>  > >>>>>I need a 12 bit type, and an 8 bit type.
Actually, 8 bit is easy
>  > >>>>>enough, that's a char..
>  > >>>>
>  > >>>>Doing it that way you'd need bitfields, I'd
say - some compilers
>  > >>>>handle unsigned bitfields actually quite well, say,
bitfield [6].
>  > >>>>The only other way is to shift around of course...
>  > >>>>
>  > >>>>No need of course to make sure you don't change
compiler in
>  > >>
>  > >>a hurry,
>  > >>
>  > >>>>or set it configurable. I;m no expert, but AFAIK
Bitorder
>  > >>
>  > >>of bitfields
>  > >>
>  > >>>>is not guaranteed to overlay in any specifc
consistent
>  >
>  > way between
>  >
>  > >>>>MCUs ot maybe even different compile settings. Never
really
>  > >>
>  > >>tried that enough.
>  > >>
>  > >>>Yepp I agree, you can do it, but it is not portable and
>  > >>
>  > >>platform and
>  > >>
>  > >>>compiler depended, so you must be aware and check the
>  > >>
>  > >>compiler output
>  > >>
>  > >>>everytime things change. I'm still looking for a
nice way
>  > >>
>  > >>to do it in legal C.
>  > >>
>  > >>>"6.7.2.1 Structure and union specifiers" from
the c
>  > >>
>  > >>standards it says:
>  > >>>10 An implementation may allocate any addressable storage
>  > >>
>  > >>unit large
>  > >>
>  > >>>enough to hold a bit-field. If enough space remains, a
>  > >>
>  > >>bit-field that
>  > >>
>  > >>>immediately follows another bit-field in astructure shall
>  >
>  > be packed
>  >
>  > >>>into adjacent bits of the same unit. If insufficient
space
>  >
>  > remains,
>  >
>  > >>>whether a bit-field that does not fit is put into the
next unit or
>  > >>>overlaps adjacent units is implementation-defined. The
order of
>  > >>>allocation of bit-fields within a unit (high-order to
low-order or
>  > >>>low-order to high-order) is implementation-defined. The
>  > >>
>  > >>alignment of the addressable storage unit is unspecified.
>  > >>
>  > >>>12 Each non-bit-field member of a structure or union
object
>  > >>
>  > >>is aligned
>  > >>
>  > >>>in an implementationdefined manner appropriate to its
type.
>  > >>>
>  > >>>
>  > >>>There's a -fpack-struct option for the gcc compiler.
>  > >>>
>  > >>>Greetz,
>  > >>>
>  > >>> Georg
>  > >>>
>  > >>>>B rgds
>  > >>>>Kris
>  > >>>>
>  > >>>>
>  > >>>>
>  > >>>>
>  > >>>>
>  > >>>>
>  > >>>>.
>  > >>>>
>  > >>>>
>  > >>>>.

That's what I'm using right as we speak. Thanks.. In case anyone else
is 
looking:

http://www.mnlab.cs.depaul.edu/~ehab/Courses/TDC573/resources/AudioResources/G.723/g711.c

is the u-law/a-law converters. If you go up into the directory, you'll also

find code for ADPCM stuff. 

-Micah 


On Sunday 16 January 2005 04:45 pm, Paul Curtis wrote:
>  I believe there is a freely available library from Sun to do u-law.
>  There must be tons of others.
>
>  --
>  Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>  CrossWorks for MSP430, ARM, and now AVR processors
>
>  > -----Original Message-----
>  > From: Micah Stevens [mailto:micah@mica...]
>  > Sent: 16 January 2005 22:42
>  > To: msp430@msp4...
>  > Subject: [msp430] Now audio data, was: Union/type help..
>  >
>  >
>  >
>  > So perhaps the best solution to my problem is to u-law my 12
>  > bits down to 8 and then I won't have the 12 bits on an 8 bit
>  > channel issue. I'm sending voice BTW. 8ksps should be plenty
>  > for that, so after compression, it would be 64kbs.
>  >
>  > I'll poke around for some u-law code.. I think I have some
>  > here somewhere.
>  >
>  > Thanks for the explanation.
>  > -Micah
>  >
>  > On Sunday 16 January 2005 01:12 pm, onestone wrote:
>  > > Hi Micah. It really depends a lot on what you are doing.
>  >
>  > packing 2 x
>  >
>  > > 12 bit samples into 3 bytes takes processing time, not a
>  >
>  > lot if you
>  >
>  > > use registers, but enough. The best answer Depends upon
>  >
>  > the quality
>  >
>  > > of audio, and the content required. Is the audio music or
>  >
>  > speech for
>  >
>  > > example? You will need to make sure your input filter is
>  >
>  > adequate to
>  >
>  > > prevent aliasing. If you are doing voice then I'd A or
>  >
>  > u-law compand
>  >
>  > > the
>  > > 12 bit sample to 8 bits, or do something totally different
>  >
>  > like the
>  >
>  > > single bit voice codec I've posted here. Simply by varying
>  >
>  > the sample
>  >
>  > > rate you can vary the quality enormously, and it is
>  >
>  > inherently a 12:1
>  >
>  > > compressor. Sampling voice at 60ksps would give you
>  >
>  > excellent quality,
>  >
>  > > at 50kbaud data rate. in fact I'd venture a guess (based on
>  >
>  > real world
>  >
>  > > tests) that broadcats radio quality music is possible using
this
>  > > technique, at less than the uncompressed 8000sps you would
>  >
>  > normally
>  >
>  > > employ for voice. At 12 bits thats 96kbps for voice.
>  >
>  > Stricly speaking
>  >
>  > > music should be sampled around 22ksps minimum, or 262kbps
>  >
>  > at 12 bit
>  >
>  > > sample size, equivalent to 327.5kbaud compacted but
uncompressed.
>  > >
>  > > Cheers]
>  > >
>  > > Al
>  > >
>  > > Micah Stevens wrote:
>  > > > Hmm.. True it's easier, but not exactly bandwidth
efficient.
>  > > Currently > I've got quite a bit of overhead, so maybe
I can get
>  > > something working > that way, but the next revision of
>  >
>  > product will
>  >
>  > > need to support more > data, so less bandwidth..
>  > > >
>  > > > It's for an RF link BTW, hence my bandwidth
limitation.. I'm
>  > > sampling > audio.. so there's a lot of data.
>  > > >
>  > > > Speaking of sampling audio, is there an efficient way to
>  >
>  > oversample
>  >
>  > > with > the ADC? or should I just up the sample rate and
>  >
>  > just average
>  >
>  > > the > samples with the CPU? I think it will be a 4:1
oversample.
>  > > (60Khz total) > > I'll need to do that eventually
as well.. the
>  > > noise floor is pretty high > as I have things now.
>  > > >
>  > > > -Micah
>  > > >
>  > > > On Sunday 16 January 2005 12:37 pm, onestone wrote:
>  > > >> Just up, or not been to bed yet Kris?
>  > > >>
>  > > >> Given that it's C, unless there is an
overwhelming need to keep
>  > > your >> data compressed it would be easier to send the
>  >
>  > twelve bits as
>  >
>  > > two >> separate bytes, as they are read from the ADC.
>  > > >>
>  > > >> Al
>  > > >>
>  > > >> microbit wrote:
>  > > >> > Hi Micah,
>  > > >> >
>  > > >> > Weather still bad up there I here.
>  > > >> >
>  > > >> >>Only I'm not sure how to define the
adc/spi types. Is there a
>  > > way to >> >> define a data type with an arbitrary
number
>  >
>  > of bits in
>  >
>  > > it? I can't >> >> find any way to do this in
my searching.
>  > > >> >>
>  > > >> >>
>  > > >> >>I need a 12 bit type, and an 8 bit type.
Actually, 8
>  >
>  > bit is easy
>  >
>  > > >> >> enough, that's a char..
>  > >
>  > > >> >
>  > > >> > Doing it that way you'd need bitfields,
I'd say -
>  >
>  > some compilers
>  >
>  > > >> > handle unsigned bitfields actually quite well,
say,
>  >
>  > bitfield [6].
>  >
>  > > >> > The only other way is to shift around of
course...
>  > > >> >
>  > > >> > No need of course to make sure you don't
change compiler in a
>  > > hurry, >> > or set it configurable. I;m no expert, but
>  >
>  > AFAIK Bitorder
>  >
>  > > of >> > bitfields is not guaranteed to overlay in any
specifc
>  > > consistent way >> > between MCUs ot maybe even
different compile
>  > > settings. Never really >> > tried that enough.
>  > > >> >
>  > > >> > B rgds
>  > > >> > Kris
>  > > >> >
>  > > >> >
>  > > >> > 
>  >
>  > >> > >>
>  >
>  > > > >> > >> > .
>  > > >> >
>  > > >> >
>  > > >> > .
>  >
>  > .
>  >
>  >
>  > .

Then consider this a lesson.  ;-)

Are you sure that the MSP430 can do u-law or a-law conversion in real
time?  I'm not convinced, but have no numbers to back it up.

Regards,

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and now AVR processors   

> -----Original Message-----
> From: Micah Stevens [mailto:micah@mica...] 
> Sent: 17 January 2005 00:57
> To: msp430@msp4...
> Subject: Re: [msp430] Union/type help..
> 
> 
> Hey! I represent that! 
> 
> 
> On Sunday 16 January 2005 04:47 pm, Paul Curtis wrote:
> >  Yeah, but at least that's 25% wastage by a seasoned 
> programmer.  You  
> > should see what wastage you get from newbies.  ;-)
> >
> >  > -----Original Message-----
> >  > From: onestone [mailto:onestone@ones...]  > Sent: 
> 16 January 
> > 2005 21:29  > To: msp430@msp4...  > Subject: Re: [msp430] 
> > Union/type help..
> >  >
> >  >
> >  > 25% wasted storage for 1 variable though ;@}  >  > Al 
>  > Paul 
> > Curtis wrote:
> >  > > // Send two 12-bit samples x and y packed into 24 bits.
> >  > > void send_two_samples(unsigned x, unsigned y) {
> >  > >   unsigned long data = ((unsigned long)x << 12) + y;
> >  > >   spi_write(&data, 3);  // assumes little-endian
addressing
> >  >
> >  > of MSP430
> >  >
> >  > > }
> >  > >
> >  > > Simple.  Forget bitfields.  C isn't that crippled.
> >  > >
> >  > > --
> >  > > Paul Curtis, Rowley Associates Ltd  
> http://www.rowley.co.uk  >  > 
> > CrossWorks  >  > > for MSP430, ARM, and now AVR processors 
> >  > 
> > >>-----Original Message-----  > >>From: onestone 
> > [mailto:onestone@ones...]  > >>Sent: 16 January 2005 
> 21:15  > 
> > >>To: msp430@msp4...  > >>Subject: Re: [msp430]
Union/type 
> > help..
> >  > >>
> >  > >>
> >  > >>Oh the joys of asm toys ;@}
> >  > >>
> >  > >>Al
> >  > >>
> >  > >>Georg Ritter wrote:
> >  > >>>microbit wrote:
> >  > >>>>Hi Micah,
> >  > >>>>
> >  > >>>>Weather still bad up there I here.
> >  > >>>>
> >  > >>>>>Only I'm not sure how to define the
adc/spi types. 
> Is  > >>  > 
> > >>there a way to  > >>  > >>>>>define
a data type with an arbitrary 
> > number of bits in  >  > it? I can't  >  >
>>>>>find any way 
> to do this 
> > in my searching.
> >  > >>>>>
> >  > >>>>>
> >  > >>>>>I need a 12 bit type, and an 8 bit type.
Actually, 8 bit is 
> > easy  > >>>>>enough, that's a char..
> >  > >>>>
> >  > >>>>Doing it that way you'd need bitfields,
I'd say - some 
> > compilers  > >>>>handle unsigned bitfields actually
quite 
> well, say, bitfield [6].
> >  > >>>>The only other way is to shift around of
course...
> >  > >>>>
> >  > >>>>No need of course to make sure you don't
change 
> compiler in  > 
> > >>  > >>a hurry,  > >>  >
>>>>or set it configurable. I;m 
> no expert, 
> > but AFAIK Bitorder  > >>  > >>of bitfields  >
>>  > >>>>is not 
> > guaranteed to overlay in any specifc consistent  >  > way 
> between  >  
> > > >>>>MCUs ot maybe even different compile settings.
Never 
> really  > 
> > >>  > >>tried that enough.
> >  > >>
> >  > >>>Yepp I agree, you can do it, but it is not portable 
> and  > >>  > 
> > >>platform and  > >>  > >>>compiler
depended, so you must 
> be aware and 
> > check the  > >>  > >>compiler output  > >> 
> >>>everytime things 
> > change. I'm still looking for a nice way  > >>  >
>>to do 
> it in legal 
> > C.
> >  > >>
> >  > >>>"6.7.2.1 Structure and union specifiers"
from the c  > >>  > 
> > >>standards it says:
> >  > >>>10 An implementation may allocate any addressable 
> storage  > >>  
> > > >>unit large  > >>  > >>>enough to
hold a bit-field. If 
> enough space 
> > remains, a  > >>  > >>bit-field that  > >> 
> 
> >>>immediately follows 
> > another bit-field in astructure shall  >  > be packed  > 
> >>>into 
> > adjacent bits of the same unit. If insufficient space  >  > 
> remains,  
> > >  > >>>whether a bit-field that does not fit is put
into the next 
> > unit or  > >>>overlaps adjacent units is 
> implementation-defined. The 
> > order of  > >>>allocation of bit-fields within a unit 
> (high-order to 
> > low-order or  > >>>low-order to high-order) is 
> implementation-defined. 
> > The  > >>  > >>alignment of the addressable storage
unit is 
> > unspecified.
> >  > >>
> >  > >>>12 Each non-bit-field member of a structure or union

> object  > 
> > >>  > >>is aligned  > >>  > >>>in
an implementationdefined manner 
> > appropriate to its type.
> >  > >>>
> >  > >>>
> >  > >>>There's a -fpack-struct option for the gcc
compiler.
> >  > >>>
> >  > >>>Greetz,
> >  > >>>
> >  > >>>      Georg
> >  > >>>
> >  > >>>>B rgds
> >  > >>>>Kris
> >  > >>>>
> >  > >>>>
> >  > >>>>[Non-text portions of this message have been 
> removed]  > >>>>  
> > > >>>>  > >>>>  > >>>>.
> >  > >>>>
> >  > >>>>
> >  > >>>>.
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
>