No, especially with all the other crap I need to make this chip do at the
same 
time, but I'm willing to try. I'm running it at 8mhz.. so maybe.. I
might 
need to do 2 channels worth sometimes too.. which may suck. 

-Micah 


On Sunday 16 January 2005 05:01 pm, Paul Curtis wrote:
>  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] > >>>>
>  >
>  > > > >>>> > >>>> >
>>>>.
>  > > > >>>>
>  > > > >>>>
>  > > > >>>>.
>  >
>  > .
>  >
>  >
>  > .

It's not far from a adpcm method, so it makes sense it would be possible.
I'll 
poke around with it. I'm not in the lab today though, so it's tough..
I'll 
make more progress tomorrow. 

What do you mean by 'scaling'? (sorry if it's a dumb question..) 

-Micah 

On Sunday 16 January 2005 04:52 pm, onestone wrote:
>  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
>  >> >> >> >
>  >> >> >> >
>  >> >> >> > 
>  >> >> >> >
>  >> >> >> >
>  >> >> >> >
>  >> >> >> > .
>  >> >> >> >
>  >> >> >> >
>  >> >> >> > .
>  >> >
>  >> > .
>  >> >
>  >> >
>  >> > .
>  >
>  > .
>  >
>  >
>  > .

Touche.

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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>.
>>>>>>
>>>>>>
>>>>>>Yahoo! Groups Links
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>.
>>>>>
>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>.
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>.
>>>
>>> 
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>
>>
>>
>>.
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
>>
>>
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Yes it can, but I've never tried it in C, I tried it a while ago, but 
decided on a different tack in the end.

25% by a seasoned programmer! and you call that efficient? Damn you 
should use a little hot paprika and chilli instead of salt and vinegar. 
Now that's seasoned!

Al

Paul Curtis wrote:

> 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
>>
>>
>>
>> 
>>
>>
>>
>>
>>
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Hi,

> You can't create an array of bitfields in
C... 

yes, but you can create an array of objects (structs, chars, or ...) with
bitfields.
But the standard allows things like stuffing bits and trap representations and 
genelly that array depends on the endianess.

Regards,

Rolf

If you simply increment or decrement by 1 per data bit you'll not get 
much deviation around 0, however you can scale the increments to achieve 
greater volume. there are many ways to unravel this data, which is ADPCM 
like, but which actually gives far better quality than most ADPCM 
routines I've seen. If you read all the accompanying data you'll see 
that you can employ fractional scaling as well as simple 1 bit. You 
could adapt the scheme for 2 bit, 1.25 bit, 1.5 bit etc.

Al

Micah Stevens wrote:

> 
> It's not far from a adpcm method, so it makes sense it would be
possible. I'll 
> poke around with it. I'm not in the lab today though, so it's
tough.. I'll 
> make more progress tomorrow. 
> 
> What do you mean by 'scaling'? (sorry if it's a dumb
question..) 
> 
> -Micah 
> 
> On Sunday 16 January 2005 04:52 pm, onestone wrote:
> 
>> 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
> 
> 
> 
>  
> 
> 
> 
> 

Wow.. you guys seem to have some history together.. ;-) 

On Sunday 16 January 2005 05:37 pm, onestone wrote:
>  Yes it can, but I've never tried it in C, I tried it a while ago, but
>  decided on a different tack in the end.
>
>  25% by a seasoned programmer! and you call that efficient? Damn you
>  should use a little hot paprika and chilli instead of salt and vinegar.
>  Now that's seasoned!
>
>  Al
>
>  Paul Curtis wrote:
>  > 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] > >>>>
>  >>
>  >>>>>>>> > >>>> >
>>>>.
>  >>> > >>>>
>  >>> > >>>>
>  >>> > >>>>.
>  >>
>  >>.
>  >>
>  >>
>  >>.

Okay, thanks, I'll play with the code tomorrow when I have some
hardware to 
listen to. 

-Micah 


On Sunday 16 January 2005 05:43 pm, onestone wrote:
>  If you simply increment or decrement by 1 per data bit you'll not get
>  much deviation around 0, however you can scale the increments to achieve
>  greater volume. there are many ways to unravel this data, which is ADPCM
>  like, but which actually gives far better quality than most ADPCM
>  routines I've seen. If you read all the accompanying data you'll
see
>  that you can employ fractional scaling as well as simple 1 bit. You
>  could adapt the scheme for 2 bit, 1.25 bit, 1.5 bit etc.
>
>  Al
>
>  Micah Stevens wrote:
>  > It's not far from a adpcm method, so it makes sense it would be
>  > possible. I'll poke around with it. I'm not in the lab
today though, so
>  > it's tough.. I'll make more progress tomorrow.
>  >
>  > What do you mean by 'scaling'? (sorry if it's a dumb
question..)
>  >
>  > -Micah
>  >
>  > On Sunday 16 January 2005 04:52 pm, onestone wrote:
>  >> 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
>  >> >> >> >> >
>  >> >> >> >> >
>  >> >> >> >> > 
>  >> >> >> >> >
>  >> >> >> >> >
>  >> >> >> >> >
>  >> >> >> >> > .
>  >> >> >> >> >
>  >> >> >> >> >
>  >> >> >> >> > .
>  >> >
>  >> > .
>  >> >
>  >> >
>  >> > .
>  >
>  > .
>  >
>  >
>  > .

Hi Sepp,

Thanks for the code, it's actually a little more efficient than how I was 
doing it. I'll try it tomorrow.. 

-Micah

On Sunday 16 January 2005 12:48 pm, Sepp Holzmayr
wrote:
>  Hi Micah!
>
>  > So I was thinking, 3*8 bits is 24 bits, and 2 * 12 bits is 24 bits.
So
>
>  perhaps
>
>  > I could declare a union to do this. Something like:
>  >
>  > union sample {
>  > adc[2]
>  > spi[3]
>  > }
>
>  As far as I know, there's NO way of defining a 12bit data type in C.
>
>  > I need a 12 bit type, and an 8 bit type. Actually, 8 bit is easy
enough,
>  > that's a char..
>  >
>  > Or am I going about this the wrong way? Perhaps there's a better
way to
>
>  buffer
>
>  > this data.
>
>  There IS some way of having some kind of union, as you call is, but I
> would use
>  2 ints (16bit) to read in 2 ADC-values, repack them so int1 is fully used
>  and int2
>  only the lower byte, for example, and then transmit the stuff via
>  char-pointer.
>
>  Code example - Just an idea which might work, I haven't tried it!!!
>  (I assume the 12bit-value is returned on the lower 12bits and that
>  typecasting a
>  char-pointer on an int will result in pointing at the lower byte. If not
> so, some shifts
>  and incs/decs will help)
>
>  int Buffer1, Buffer2;
>  char *transmit;
>
>  Buffer1 = GetADValue1();   // get the ADC values
>  Buffer2 = GetADValue2();
>
>  Buffer1 &= 0x0FFF;    // Clean Buffer bits...
>  Buffer2 &= 0x0FFF;
>
>  transmit = &Buffer1;    // point @ lower byte,
>  ADC-val1
>
>  SendVal(*transmit);    // and transmit it
>  Buffer1 |= (Buffer2 & 0x000F) <<12;  // pack lowest
nibble of
>  ADC-val2 into ADC-val1
>  transmit++;      // adjust pointer
>  SendVal(*transmit);    // and transmit the highest
>  nibble of ADC-val1 and lowest nibble of ADC-val2
>  Buffer2 = (Buffer2 & 0x0FF0) >> 4;  // repack ADC-val2
>  transmit = &Buffer2;    // adjust pointer one more
>  time
>  SendVal(*transmit);     // and transmit the rest!
>
>  ... got the idea? It surely needs some fine-tuning, but the general way
>  should work, I think.
>
>  Hope to have helped, Sepp
>
>  PS: this might be delayed, as it is my first post.....
>
>
>
>
>
>
>  .
>
>
>
>
>
>  .

HI Rolf,

Sure you can create an array of objects with bitfields, but the packing
of bitfields does not apply across elements of an array, so there is NO
WIN in doing so.

As an example:

// Stores a single bit
typedef struct 
{
  unsigned value : 1;
} bit_t;

// An array of bits
bit_t bits[256];

So, what do you think sizeof(bits) is?  And what what it is when you
*measure* it?  And does it differ between compilers?

-- Paul.

> -----Original Message-----
> From: rolf.freitag@rolf... [mailto:rolf.freitag@rolf...] 
> Sent: 17 January 2005 01:41
> To: msp430@msp4...
> Subject: RE: [msp430] Union/type help..
> 
> 
> Hi,
> 
> > You can't create an array of bitfields in C... 
> 
> yes, but you can create an array of objects (structs, chars, 
> or ...) with bitfields.
> But the standard allows things like stuffing bits and trap 
> representations and genelly that array depends on the endianess.
> 
> Regards,
> 
> Rolf
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
>