I am not using a voltage regulator. A 3.7V Lithium battery will suffice perfectly, and I don't need the wasted current of even an LDO. Thanks for the advice on the regulator tho.. I will be generating an externally powered DC version (powered by >6VDC) and will need a regulator then. -Mark
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Brown Sent: Friday, November 22, 2002 3:16 AM To: [email protected] Subject: Re: [Mspgcc-users] Fwd: MSPGCC question > Ok, well, as for readability, I was going to generate an inline function > call that would perform the assembly DADD: > inline int dadd( int one, int two ); > Or some such. (How do I deal w/ the carry bit?) > As for power, the LCD uses something like 100pA to run.. But 50uS is That's pretty low power :-) Unless you have something else running on the board taking more current, you are going to be well under the leakage current of a common lithium button battery. You can also start getting problems with voltage regulators - on one msp430 card we did, I was surprised to find the 3V line was nearer 6V - it turned out that the regulator could not work with such a low current. Fortunately an unused pin on the cpu had a 10k pull-up on it - the solution was just to drive that pin low. > probably about the complete length of my loop( the CPU will be off most > of the time). 50uS was, of course, a rough guess for a general routine - using a look-up table would take something like 5 clock cycles. But extending it beyond two digits would take longer than using DADD. > Thanks for the info tho, this is definitely fast. > -Mark > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of David > Brown > Sent: Thursday, November 21, 2002 2:25 PM > To: [email protected] > Subject: Re: [Mspgcc-users] Fwd: MSPGCC question > > > I cannot image that converting from hex to bcd is really going to make > any > significant differance to your program - even with a very inefficient > convertion function, the power required for running the core an extra > fifty > microseconds is negligble compared to the power taken to display the > result. > BCD instructions are quite convenient at the assembly level, but they > are > seldom worth the cost in readability for C. If you want a fast (but 100 > byte long) convertion routine for hex to bcd (single byte only), try > using: > > const unsigned char hexToBcd[100] = > {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x10, 0x11, > 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x20, 0x21, 0x22, 0x23, > 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, > 0x36, 0x37, 0x38, 0x39, 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, > 0x48, 0x49, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, > 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x70, 0x71, > 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x80, 0x81, 0x82, 0x83, > 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x90, 0x91, 0x92, 0x93, 0x94, 0x95, > 0x96, 0x97, 0x98, 0x99}; > > Python is just *so* useful for doing this sort of thing, don't you > think? > >>> ', '.join(map(lambda x : "0x%02d" % x, range(100))) > > > > > > > > no way to force gcc to issue 'dadd' > > Instead: > > asm volatile("dadd %1,%0": "=r" (a) : "r" (b)); > > > > > > > > ---------- Forwarded Message ---------- > > > > Subject: MSPGCC question > > Date: Thu, 21 Nov 2002 11:30:42 -0500 > > From: "Mark Stokes" <[email protected]> > > To: <[email protected]> > > > > Howdy, from South Carolina, USA. I am very pleased to find the MSPGCC > > project. Since I've developed a bunch of asm code for the 337 version > > of the MSP430, and am not upgrading to the 44x version, I really > needed > > to find a solution that will work and not cost $2000 (IAR). I had > been > > using the "Simulation Environment" provided by TI, but it doesn't > > support the flash devices. So, here I am. > > > > I have a very fundamental question: > > I am on a very tight power requirements budget. One of the things I > am > > doing to meet that budget is to deal with most/all my numbers as BCD > > numbers. This means when I need to increment something, I use the > DADD > > instruction. This is one of the reasons I like the MSP430 (that it > has > > decimal math instructions). However, the IAR compiler doesn't have > any > > way to force the compiler to use these instructions when performing > +/- > > operations. This seems stupid and I'm not interested in wasting the > > extra battery power it takes to constantly convert a hex# to a BCD# (I > > am using the onboard LCD output/driver). > > Is there a way (aside from generating a library of asm routines, which > > I'm not opposed to doing), to force mspgcc to use DADD? At the time > > (and I think only recently they have fixed this), IAR didn't even > allow > > inline assembly, only inline-machine (which is totally useless). So > > after purchasing it for $3k (US), almost 3 years ago, I sent it back. > > > > > > > > If you want me to put this is the discussion, I will. But I thought > I'd > > ask here first. > > > > Thanks > > -Mark Stokes > > > > ------------------------------------------------------- > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Mspgcc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
