I noticed a similar problem with printf (outputting to the UART) with the MSP430X branch. Adding -mdata-64k to CFLAGS fixed it for me, maybe it'll work for you as well. I'm guessing it doesn't know how to handle the new 20 bit pointers? HTH, Michiel
> -----Original Message----- > From: Jordi Soucheiron [mailto:[email protected]] > Sent: maandag 30 november 2009 13:27 > To: [email protected] > Subject: Re: [Mspgcc-users] Problem with sprintf and snprintf in > amsp430x2617 > > Thanks for your reply. > I posted this line as an example, but there could be cases where I > actually use variables and therefore need s(n)printf instead of > strcpy(). For example: > snprintf(debugbuf, 256, " Z (%d) \n", data); > I haven't placed any 0xa0 character on purpose, but if there was a > problem of the code handling the output of the s(n)printf function my > code would fail independently of the compiler version used (or at > least it should). But the handler is the following: > > static void writedebug() > { > uint16_t i = 0; > > while (debugbuf[i] != '\0' && i < 256) > UARTPutChar(debugbuf[i++]); > } > > #line 150 > static void UARTPutChar(char c) > { > if (c == '\n') { > UARTPutChar('\r'); > } > > while (!(IFG2 & (1 << 1))) ; > { __nesc_atomic_t __nesc_atomic = __nesc_atomic_start(); > #line 157 > UCA0TXBUF = c; > #line 157 > __nesc_atomic_end(__nesc_atomic); } > } > > 2009/11/30 JMGross <[email protected]>: > > > > > > After reading your message once again, I stumbled over the words > "debugbuf keeps the same information as if '...' was a null string" > > IMHO if the format string is a null string, the destination buffer > should contain a null string too and not 'keep the same' (except if it > was a null string before already). > > > > Anyway, if you just want to compy your constant text into debugbuf > (this is what your code actually does), you can simply use strcpy() > instead. Faster, smaller and much less stack usage. :) > > > > JMGross > > > > ----- Ursprüngliche Nachricht ----- > > Von: Jordi Soucheiron > > An: [email protected] > > Gesendet am: 24 Nov 2009 13:54:25 > > Betreff: [Mspgcc-users] Problem with sprintf and snprintf in a > msp430x2617 > > > > Hi, > > I've been trying to fix a problem with my build of mspgcc but I got > > out of ideas to fix it. Some time ago I used a build from july 2008 > > and everithing worked just fine, now I've switched to the last cvs > > version and I've found out that sprintf for some reason doesn't write > > to the destiny. I've tryed to exec this (this line is from the output > > of a nesc precompiler): > > snprintf(debugbuf, 256, " + Accelerometer Started\n"); > > But instead of moving the string to the debugbuf keeps the same > > information just as if " + Accelerometer Started\n" was a null > > string. > > > > > > > > --------------------------------------------------------------------- > --------- > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > > trial. Simplify your report design, integration and deployment - and > focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Mspgcc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > > > -- > Jordi Soucheiron > Software Engineer > > DEXMA > Parc Tecnològic la Salle > Sant Joan de la Salle, 42 > 08022 Barcelona > t/f: [+34] 93 181 01 95 > www.dexmatech.com > [email protected] > > ----------------------------------------------------------------------- > ------- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
