From richard at imagecraft.com Tue Sep 8 22:28:01 2009
From: richard at imagecraft.com (Richard Man)
Date: Tue Sep 8 23:41:16 2009
Subject: [Icc-430] V7.11 Beta0
Message-ID: <200909090641.n896fFdm000724@mail.imagecraft.com>
http://www.imagecraft.com/pub/iccv7430_v711_beta0.exe
Readme:
V7.11 - Sept 9, 2009
IDE
- "Custom" device was not passing the RAM start address to the makefile
properly.
- Much faster startup time for the IDE
- IDE now keeps a "Build Number" for each project. This is passed to
the linker and emitted to the top of the .mp map file.
- Added -D__BUILD for the Build Number.
- Changed -D__ICC_VERSION=XXX where XXX is the version in integer form,
e.g. 707. This allows easier conditional compilation.
- Added %v (version) and %b (build number) to the macro chars for
the "Execute Before Build" and "Execute After Successful Build"
command box.
- Modified the "checking" options, now they are
"Strict Checking" (equivalent to -A command line switch).
"ANSI C Portability Conformance Checking" (equivalent to -A -A).
This does draconian check on conditions that exceed ANSI C minimum
limits (e.g. less than 512 variables) and is usually not needed.
Asm/linker
- Fixed several 430X related issues.
// richard blog:
// mailing list: http://www.dragonsgate.net/mailman/listinfo
// photo book: http://www.blurb.com/bookstore/detail/745963
[ For technical support on ImageCraft products, please include all
previous replies in your msgs. ]
From jdurand at interstellar.com Wed Sep 9 10:18:22 2009
From: jdurand at interstellar.com (Jerry Durand)
Date: Wed Sep 9 11:30:01 2009
Subject: [Icc-430] V7.11 Beta0
In-Reply-To: <200909090641.n896fFdm000724@mail.imagecraft.com>
References: <200909090641.n896fFdm000724@mail.imagecraft.com>
Message-ID: <4AA7E35E.3030009@interstellar.com>
Testing now. I like the extra info with memory usage, easier to see
when I'm getting into trouble.
Richard Man wrote:
> http://www.imagecraft.com/pub/iccv7430_v711_beta0.exe
>
--
Jerry Durand, Durand Interstellar, Inc. www.interstellar.com
tel: +1 408 356-3886, USA toll free: 1 866 356-3886
Skype: jerrydurand
From richard at imagecraft.com Thu Sep 10 18:30:43 2009
From: richard at imagecraft.com (Richard Man)
Date: Thu Sep 10 19:44:12 2009
Subject: [Icc-430] V7.11 Beta0
Message-ID: <200909110244.n8B2iA7F028422@mail.imagecraft.com>
Some new TI header files and a last minute change was not done
everywhere, so 430X support was broken. Sorry.
***
http://www.imagecraft.com/pub/iccv7430_v711_beta1.exe
Readme:
V7.11 - Sept 9, 2009
IDE
- "Custom" device was not passing the RAM start address to the makefile
properly.
- Much faster startup time for the IDE
- IDE now keeps a "Build Number" for each project. This is passed to
the linker and emitted to the top of the .mp map file.
- Added -D__BUILD for the Build Number.
- Changed -D__ICC_VERSION=XXX where XXX is the version in integer form,
e.g. 707. This allows easier conditional compilation.
- Added %v (version) and %b (build number) to the macro chars for
the "Execute Before Build" and "Execute After Successful Build"
command box.
- Modified the "checking" options, now they are
"Strict Checking" (equivalent to -A command line switch).
"ANSI C Portability Conformance Checking" (equivalent to -A -A).
This does draconian check on conditions that exceed ANSI C minimum
limits (e.g. less than 512 variables) and is usually not needed.
Asm/linker
- Fixed several 430X related issues.
// richard blog:
// mailing list: http://www.dragonsgate.net/mailman/listinfo
// photo book: http://www.blurb.com/bookstore/detail/745963
[ For technical support on ImageCraft products, please include all
previous replies in your msgs. ]
From bgarmer at ambientalert.com Mon Sep 21 08:40:45 2009
From: bgarmer at ambientalert.com (Bill Garmer)
Date: Mon Sep 21 09:51:57 2009
Subject: [Icc-430] Taking three 8 bit numbers and sign extending a 32 bit
In-Reply-To: <200909111900.n8BJ02st037668@mail.imagecraft.com>
Message-ID: <94C5A1526E432B469C9E047B917B0D972C9D9D@ACSDC1.ambient.corp>
I am working on a project where a TI ADS1255 has been interfaced to a
MSP430F5437 via the SPI. The ADS1255 outputs three 8 bit numbers for a
complete 24 bit twos complement result. My first thought was to use a
union as:
union
{
signed long recData;
signed char byte[4];
}adc;
The problem is no matter which order I put the bytes into array, I don't
get a correct result. I can get a 16 bit result with the lower two
bytes but the upper two bytes don't seem to work. Any suggestions?
From jdurand at interstellar.com Mon Sep 21 08:50:52 2009
From: jdurand at interstellar.com (Jerry Durand)
Date: Mon Sep 21 10:03:50 2009
Subject: [Icc-430] Taking three 8 bit numbers and sign extending a 32 bit
In-Reply-To: <94C5A1526E432B469C9E047B917B0D972C9D9D@ACSDC1.ambient.corp>
References: <94C5A1526E432B469C9E047B917B0D972C9D9D@ACSDC1.ambient.corp>
Message-ID: <4AB7A0DC.6060606@interstellar.com>
You've got to do the sign extension to the 4th byte. I use unions all
the time to speed up byte access to data but it's pretty much always
unsigned.
Could you set the A2D into unsigned mode, save the three bytes, clear
the 4th, then change the sign of adc.recData if you need?
Bill Garmer wrote:
> I am working on a project where a TI ADS1255 has been interfaced to a
> MSP430F5437 via the SPI. The ADS1255 outputs three 8 bit numbers for a
> complete 24 bit twos complement result. My first thought was to use a
> union as:
>
> union
> {
> signed long recData;
> signed char byte[4];
> }adc;
>
> The problem is no matter which order I put the bytes into array, I don't
> get a correct result. I can get a 16 bit result with the lower two
> bytes but the upper two bytes don't seem to work. Any suggestions?
>
> _______________________________________________
> Icc-430 mailing list
> Icc-430@imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-430
>
--
Jerry Durand, Durand Interstellar, Inc. www.interstellar.com
tel: +1 408 356-3886, USA toll free: 1 866 356-3886
Skype: jerrydurand
From bailey at peak.org Mon Sep 21 08:58:36 2009
From: bailey at peak.org (bailey@peak.org)
Date: Mon Sep 21 10:13:41 2009
Subject: [Icc-430] Taking three 8 bit numbers and sign extending a 32 bit
In-Reply-To: <94C5A1526E432B469C9E047B917B0D972C9D9D@ACSDC1.ambient.corp>
References: <94C5A1526E432B469C9E047B917B0D972C9D9D@ACSDC1.ambient.corp>
Message-ID:
Bill,
I can't tell from your message if you are storing just the three bytes
you read from the A/D into the byte array? If yes, you can store them in
the three highest order bytes and leave the bottom byte 0. If
you don't want the value scaled up by 256, you need to store the three A/D
bytes in the union low order positions and manually sign extend the
A/D MSB into the union MSB (ie. either all 1's or all 0 bits depending on
the value of the most significant bit in the A/D MSB.
If I've miss-understood your question please ignore the above!
Kirk Bailey
bailey@peak.org
> I am working on a project where a TI ADS1255 has been interfaced to a
> MSP430F5437 via the SPI. The ADS1255 outputs three 8 bit numbers for a
> complete 24 bit twos complement result. My first thought was to use a
> union as:
>
> union
> {
> signed long recData;
> signed char byte[4];
> }adc;
>
> The problem is no matter which order I put the bytes into array, I don't
> get a correct result. I can get a 16 bit result with the lower two
> bytes but the upper two bytes don't seem to work. Any suggestions?
>
> _______________________________________________
> Icc-430 mailing list
> Icc-430@imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-430
>
From bgarmer at ambientalert.com Mon Sep 21 10:54:27 2009
From: bgarmer at ambientalert.com (Bill Garmer)
Date: Mon Sep 21 12:05:38 2009
Subject: [Icc-430] Taking three bytes to 32
In-Reply-To: <200909211900.n8LJ02gs040543@mail.imagecraft.com>
Message-ID: <94C5A1526E432B469C9E047B917B0D972C9DA2@ACSDC1.ambient.corp>
I should probably been more clear. I do sign extend the final byte.
The code is:
/***********************************************************************
****
* Function Name : adc_read
* returns : received 24 bit data sign extended to 32 bits
*
* Created by: : Bill Garmer
* Date created : 24 AUG 2009
* Last revised :
* Description : Reads the data from the ADS1255 ADC and sign extends
* it to 32 bits.
* Notes : This function does not set the chip select port.
That
* must be done before calling this routine
************************************************************************
***/
long adc_read(void)
{
union
{
signed long recData;
signed char byte[4];
}adc;
int i;
while (!(UCB1IFG & UCTXIFG))
{
// Wait for transmit buffer to be empty
;
}
UCB1TXBUF = RDATA; // Command a read data
while (!(UCB1IFG & UCRXIFG))
{
// Wait for first (dummy) received byte
;
}
adc.byte[3] = UCB1RXBUF; // Collect the dummy byte
for(i = 0; i < 13; i++)
{
asm("nop\n");
}
UCB1TXBUF = 0x00; // Write a byte to receive data
while (!(UCB1IFG & UCRXIFG))
{
// Wait for MSB
;
}
adc.byte[2] = UCB1RXBUF; // Collect the MSB
// Sign extend
if (adc.byte[2] & BIT7)
{
adc.byte[3] = 0xFF;
}
else
{
adc.byte[3] = 0x00;
}
UCB1TXBUF = 0x00; // Write a byte to receive data
while (!(UCB1IFG & UCRXIFG))
{
// Wait for NSB
;
}
adc.byte[1] = UCB1RXBUF; // Collect the NSB
UCB1TXBUF = 0x00; // Write a byte to receive data
while (!(UCB1IFG & UCRXIFG))
{
// Wait for LSB
;
}
adc.byte[0] = UCB1RXBUF; // Collect the LSB
//while((UCB1STAT & UCBUSY))
//{
// ; // Wait until not busy
//}
return adc.recData;
} // End adc_read
The problem is that no matter what order I put the data into the byte
array I only get 16 bits out. I have watched the data from the ADC on
an oscope and have cranked up the input but it is only 16 bits in the
return (or its is 0 and -1 only depending on which order I insert the
data).
Bill Garmer, PE
CTO
bgarmer@ambientalert.com
Ambient Control Systems, Inc.
12625 Danielson Ct, Ste. 109
Poway, CA 92064
v: 619.562.5411 x504 f: 619.562.8081
www.ambientalert.com
DISCLAIMER: This e-mail and any files transmitted with it contain
confidential and proprietary information and is intended solely for the
use of the intended recipient. If you are not the intended recipient,
please return the e-mail to the sender and delete it from your computer
and you must not use, disclose, distribute, copy, print or rely on this
e-mail. The contents of this e-mail and any files transmitted with it
may have been changed or altered without the consent of the author.
Email transmission cannot be guaranteed to be secure or error-free.
From design at johnfromarran.org.uk Mon Sep 21 12:03:16 2009
From: design at johnfromarran.org.uk (John Baraclough)
Date: Mon Sep 21 13:14:35 2009
Subject: [Icc-430] Taking three bytes to 32
In-Reply-To: <94C5A1526E432B469C9E047B917B0D972C9DA2@ACSDC1.ambient.corp>
References: <94C5A1526E432B469C9E047B917B0D972C9DA2@ACSDC1.ambient.corp>
Message-ID: <4AB7CDF4.2020600@johnfromarran.org.uk>
I know it will be a lot slower but why don't you try it the old-fashioned way first and see if that works. If it does, then try the byte array.
All the best for now,
John
long adc_read(void)
{
signed long recData = 0;
int i;
while (!(UCB1IFG & UCTXIFG))
{
// Wait for transmit buffer to be empty
;
}
UCB1TXBUF = RDATA; // Command a read data
while (!(UCB1IFG & UCRXIFG))
{
// Wait for first (dummy) received byte
;
}
recData |= (signed long)UCB1RXBUF; // Collect the dummy byte
recData <<= 8;
for(i = 0; i < 13; i++)
{
asm("nop\n");
}
UCB1TXBUF = 0x00; // Write a byte to receive data
while (!(UCB1IFG & UCRXIFG))
{
// Wait for MSB
;
}
recData |= (signed long)UCB1RXBUF; // Collect the dummy byte
recData <<= 8;
UCB1TXBUF = 0x00; // Write a byte to receive data
while (!(UCB1IFG & UCRXIFG))
{
// Wait for NSB
;
}
recData |= (signed long)UCB1RXBUF; // Collect the dummy byte
recData <<= 8;
UCB1TXBUF = 0x00; // Write a byte to receive data
while (!(UCB1IFG & UCRXIFG))
{
// Wait for LSB
;
}
recData |= (signed long)UCB1RXBUF; // Collect the dummy byte
if(recData &0x00800000)
{
recData |= 0xff000000;
}
else
{
recData &= 0x00ffffff;
}
return recData;
} // End adc_read
From bgarmer at ambientalert.com Mon Sep 21 12:47:12 2009
From: bgarmer at ambientalert.com (Bill Garmer)
Date: Mon Sep 21 13:58:25 2009
Subject: [Icc-430] Additional information on extending three bytes
In-Reply-To: <200909211900.n8LJ02gs040543@mail.imagecraft.com>
Message-ID: <94C5A1526E432B469C9E047B917B0D972C9DA3@ACSDC1.ambient.corp>
To verify the limit to 16 bits I added the following to the code segment
I sent out:
// Debug
printf("%02x",adc.byte[3]);
printf("%02x",adc.byte[2]);
printf("%02x",adc.byte[1]);
printf("%02x,",adc.byte[0]);
printf(" %d\n",adc.recData);
It prints out the four bytes (three plus sign extension) then the
resultant long. Here is an example of the results:
0000fce4, -796
0000fca0, -864
Note that the four bytes are a positive number but the result is
negative. If I print it in hex, it comes out only 16 bytes. I believe
the union isn't doing what I expect it to do.
From bailey at peak.org Mon Sep 21 14:41:14 2009
From: bailey at peak.org (bailey@peak.org)
Date: Mon Sep 21 15:52:40 2009
Subject: [Icc-430] Additional information on extending three bytes
In-Reply-To: <94C5A1526E432B469C9E047B917B0D972C9DA3@ACSDC1.ambient.corp>
References: <94C5A1526E432B469C9E047B917B0D972C9DA3@ACSDC1.ambient.corp>
Message-ID: <5fd2dc2a7cbbd6a11cf273bffbda8bfa.squirrel@webmail.peak.org>
Umm, Err, Bill, you might want to look at the format specifier in your
debug printf for the long...
Kirk Bailey
bailey@peak.org
> To verify the limit to 16 bits I added the following to the code segment
> I sent out:
>
> // Debug
> printf("%02x",adc.byte[3]);
> printf("%02x",adc.byte[2]);
> printf("%02x",adc.byte[1]);
> printf("%02x,",adc.byte[0]);
> printf(" %d\n",adc.recData);
>
> It prints out the four bytes (three plus sign extension) then the
> resultant long. Here is an example of the results:
> 0000fce4, -796
> 0000fca0, -864
>
> Note that the four bytes are a positive number but the result is
> negative. If I print it in hex, it comes out only 16 bytes. I believe
> the union isn't doing what I expect it to do.
>
> _______________________________________________
> Icc-430 mailing list
> Icc-430@imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-430
>
From richard-lists at imagecraft.com Mon Sep 21 15:09:40 2009
From: richard-lists at imagecraft.com (Richard Man)
Date: Mon Sep 21 16:24:07 2009
Subject: [Icc-430] Additional information on extending three bytes
In-Reply-To: <5fd2dc2a7cbbd6a11cf273bffbda8bfa.squirrel@webmail.peak.org
>
References: <94C5A1526E432B469C9E047B917B0D972C9DA3@ACSDC1.ambient.corp>
<5fd2dc2a7cbbd6a11cf273bffbda8bfa.squirrel@webmail.peak.org>
Message-ID: <200909212324.n8LNO6gq043365@mail.imagecraft.com>
Kirk meant that you need to write
%ld :-)
or
%lx
At 02:41 PM 9/21/2009, bailey@peak.org wrote:
>Umm, Err, Bill, you might want to look at the format specifier in your
>debug printf for the long...
>
> Kirk Bailey
> bailey@peak.org
>
> > To verify the limit to 16 bits I added the following to the code segment
> > I sent out:
> >
> > // Debug
> > printf("%02x",adc.byte[3]);
> > printf("%02x",adc.byte[2]);
> > printf("%02x",adc.byte[1]);
> > printf("%02x,",adc.byte[0]);
> > printf(" %d\n",adc.recData);
> >
> > It prints out the four bytes (three plus sign extension) then the
> > resultant long. Here is an example of the results:
> > 0000fce4, -796
> > 0000fca0, -864
> >
> > Note that the four bytes are a positive number but the result is
> > negative. If I print it in hex, it comes out only 16 bytes. I believe
> > the union isn't doing what I expect it to do.
> >
// richard
// http://rfman.wordpress.com
// http://www.imagecraft.com/pub/Portfolio09/
From richard-lists at imagecraft.com Mon Sep 21 15:10:31 2009
From: richard-lists at imagecraft.com (Richard Man)
Date: Mon Sep 21 16:24:58 2009
Subject: [Icc-430] Additional information on extending three bytes
In-Reply-To: <94C5A1526E432B469C9E047B917B0D972C9DA3@ACSDC1.ambient.corp
>
References: <200909211900.n8LJ02gs040543@mail.imagecraft.com>
<94C5A1526E432B469C9E047B917B0D972C9DA3@ACSDC1.ambient.corp>
Message-ID: <200909212324.n8LNOvBA043421@mail.imagecraft.com>
BTW Bill, I sent you a reply last week but looks like it went to bit
bucket, but looks like your debug may be leading you astray, so may
be your problem is solved....
At 12:47 PM 9/21/2009, Bill Garmer wrote:
>To verify the limit to 16 bits I added the following to the code segment
>I sent out:
>
> // Debug
> printf("%02x",adc.byte[3]);
> printf("%02x",adc.byte[2]);
> printf("%02x",adc.byte[1]);
> printf("%02x,",adc.byte[0]);
> printf(" %d\n",adc.recData);
>
>It prints out the four bytes (three plus sign extension) then the
>resultant long. Here is an example of the results:
>0000fce4, -796
>0000fca0, -864
>
>Note that the four bytes are a positive number but the result is
>negative. If I print it in hex, it comes out only 16 bytes. I believe
>the union isn't doing what I expect it to do.
>
>_______________________________________________
>Icc-430 mailing list
>Icc-430@imagecraft.com
>http://dragonsgate.net/mailman/listinfo/icc-430
// richard
// http://rfman.wordpress.com
// http://www.imagecraft.com/pub/Portfolio09/
From bgarmer at ambientalert.com Tue Sep 22 11:32:34 2009
From: bgarmer at ambientalert.com (Bill Garmer)
Date: Tue Sep 22 12:43:47 2009
Subject: [Icc-430] Thanks for the help
In-Reply-To: <200909221900.n8MJ01ge053375@mail.imagecraft.com>
Message-ID: <94C5A1526E432B469C9E047B917B0D972C9DA7@ACSDC1.ambient.corp>
Boy am I red faced. Thanks for the help guys.
Bill
From llchisho at paradise.net.nz Wed Sep 30 15:52:33 2009
From: llchisho at paradise.net.nz (llchisho@paradise.net.nz)
Date: Wed Sep 30 17:03:59 2009
Subject: [Icc-430] V7.11 Beta1
Message-ID: <1254351153.4ac3e131655d7@www.paradise.net.nz>
Hi all,
I notice that V7.11 beta 1 still doesn't fix the problem with _PUT_SR()
intrinsic mentioned earlier.
Also, the linker summary after building my test fragment tells me :
-----------
ROM 0% full. 332 out of 49152 bytes used.
RAM 6 bytes used (does not include stack usage).
-----------
The percentage calculations should be rounded up to the next integer
(ceil(x/100)) rather than truncating (int(x/100)).
I'm always annoyed by things that tell me I have used 0% of something or a
0KB-sized file (can't remember the culprit for that now) when it's not true!!
Len Chisholm.
From richard-lists at imagecraft.com Wed Sep 30 20:53:00 2009
From: richard-lists at imagecraft.com (Richard Man)
Date: Wed Sep 30 22:03:32 2009
Subject: [Icc-430] V7.11 Beta1
In-Reply-To: <1254351153.4ac3e131655d7@www.paradise.net.nz>
References: <1254351153.4ac3e131655d7@www.paradise.net.nz>
Message-ID: <200910010503.n9153Unq056401@mail.imagecraft.com>
At 03:52 PM 9/30/2009, you wrote:
>Hi all,
>I notice that V7.11 beta 1 still doesn't fix the problem with _PUT_SR()
>intrinsic mentioned earlier.
Hmm... sorry, I thought I fixed it, but I guess I dreamt it. Sorry.
>Also, the linker summary after building my test fragment tells me :
>-----------
> ROM 0% full. 332 out of 49152 bytes used.
> RAM 6 bytes used (does not include stack usage).
>-----------
>The percentage calculations should be rounded up to the next integer
>(ceil(x/100)) rather than truncating (int(x/100)).
>I'm always annoyed by things that tell me I have used 0% of something or a
>0KB-sized file (can't remember the culprit for that now) when it's not true!!
picky picky picky :-)
>Len Chisholm.
>_______________________________________________
>Icc-430 mailing list
>Icc-430@imagecraft.com
>http://dragonsgate.net/mailman/listinfo/icc-430
// richard
// http://rfman.wordpress.com
// http://www.imagecraft.com/pub/Portfolio09/
From richard-lists at imagecraft.com Wed Sep 30 22:44:37 2009
From: richard-lists at imagecraft.com (Richard Man)
Date: Wed Sep 30 23:55:09 2009
Subject: [Icc-430] V7.11 Beta1
In-Reply-To: <1254351153.4ac3e131655d7@www.paradise.net.nz>
References: <1254351153.4ac3e131655d7@www.paradise.net.nz>
Message-ID: <200910010655.n916t8hG057188@mail.imagecraft.com>
At 03:52 PM 9/30/2009, llchisho@paradise.net.nz wrote:
>Hi all,
>I notice that V7.11 beta 1 still doesn't fix the problem with _PUT_SR()
>intrinsic mentioned earlier.
>
>Also, the linker summary after building my test fragment tells me :
>-----------
> ROM 0% full. 332 out of 49152 bytes used.
> RAM 6 bytes used (does not include stack usage).
>-----------
>The percentage calculations should be rounded up to the next integer
>(ceil(x/100)) rather than truncating (int(x/100)).
>I'm always annoyed by things that tell me I have used 0% of something or a
>0KB-sized file (can't remember the culprit for that now) when it's not true!!
Well, first of all, ceil() returns the integer greater than or equal
to, so you want ceil ((x/100) + 0.5), or lround :-)
>Len Chisholm.
>_______________________________________________
>Icc-430 mailing list
>Icc-430@imagecraft.com
>http://dragonsgate.net/mailman/listinfo/icc-430
// richard
// http://rfman.wordpress.com
// http://www.imagecraft.com/pub/Portfolio09/