Hi,

This will expose my ignorance of the C language I'm sure, but here goes: 

I'm taking 12 bit samples with the ADC on a '169, and need to send
them out 
the SPI interface, which is of course only 7 or 8 bits.. 

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]
} 

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.. 

Or am I going about this the wrong way? Perhaps there's a better way to
buffer 
this data. 

Thanks for your help,
-Micah 

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

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
> 
> 
> 
>  
> 
> 
> 
> 

Thanks for the quick reply.. It's actually Sunny today, just a couple
of 
clouds, things are still quite soggy though.. Glad I don't live closer to
the 
mountains.. a lot of mud came down last week. 

IAR seems to support bitfields.. Thanks.. my humble google skills didn't
bring 
that up. 

I don't really care if the ordering is consistant between compilers or 
compile, as long as both 'views' of the union correspond. I would
think as 
the union refers to the same memory locations, it would have to correspond. 
i.e.

union bitfield_test {
bitfield a[5];
bitfield b[5];
} test;

does test.a[3] always equal test.b[3]? 

Thanks,
-Micah

On Sunday 16 January 2005 12:22 pm, 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
>
>
>  
>
>
>
>  .
>
>
>
>
>
>  .

A good question, Micah.

Don't use bitfields that often, although more recently I did some tests
with CrossWorks for MSP430, and some 4 and 6 bit-wide boolean operations
came out very well, I'd have strained to better it.

AFAIK, there is no guaranteed correlation between bitfield member when
they're
overlaid, but I could be way off. Maybe Paul will put in his 2 bob, or can sniff
on the Net
more. I got 2 good C books here, and I'll take a look as well, now I'm
curious myself.

Cheers,
Kris


Thanks for the quick reply.. It's actually Sunny today, just a couple of 
clouds, things are still quite soggy though.. Glad I don't live closer to
the 
mountains.. a lot of mud came down last week. 

IAR seems to support bitfields.. Thanks.. my humble google skills didn't
bring 
that up. 

I don't really care if the ordering is consistant between compilers or 
compile, as long as both 'views' of the union correspond. I would
think as 
the union refers to the same memory locations, it would have to correspond. 
i.e.

union bitfield_test {
        bitfield a[5];
        bitfield b[5];
} test;

does test.a[3] always equal test.b[3]? 

Thanks,
-Micah

I just noticed my syntax is way off for the bitfields, I'd have to
make a 
structure I suppose. 

struct spi {
	data	: 8; // data load
} spi_data[3]; 

or something like that.. still playing with it. 

I was just thinking, perhaps if I declared a long int, then I could do some 
pointer arithmetic to achieve the same result? would that be more efficient? 

-Micah


On Sunday 16 January 2005 12:38 pm, Micah Stevens
wrote:
>  Thanks for the quick reply.. It's actually Sunny today, just a couple
of
>  clouds, things are still quite soggy though.. Glad I don't live
closer to
> the mountains.. a lot of mud came down last week.
>
>  IAR seems to support bitfields.. Thanks.. my humble google skills
didn't
> bring that up.
>
>  I don't really care if the ordering is consistant between compilers
or
>  compile, as long as both 'views' of the union correspond. I
would think as
>  the union refers to the same memory locations, it would have to
> correspond. i.e.
>
>  union bitfield_test {
>  bitfield a[5];
>  bitfield b[5];
>  } test;
>
>  does test.a[3] always equal test.b[3]?
>
>  Thanks,
>  -Micah
>
>  On Sunday 16 January 2005 12:22 pm, 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 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.....

I dunno anymore Al :-}
Days and nights kinda shift in and out of phase this time of the year.
Well, you know , big dreamers never sleep.


> 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

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
>  >
>  >
>  > 
>  >
>  >
>  >
>  > .
>  >
>  >
>  > .

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

> -----Original Message-----
> From: microbit [mailto:microbit@micr...] 
> Sent: 16 January 2005 20:23
> To: msp430@msp4...
> Subject: Re: [msp430] Union/type help..
> 
> 
> 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
> 
> 
> 
>  
> 
> 
> 
> 
>