Jump to content
philb

Error Using String Constant Array For Hex Output

Recommended Posts

Hello.

 

V6.95, compiling for 18F24k20 on Win XP.

 

The below code has been used on various PICs (18f2431,16f690,16f886,16f688) using previous versions of SourceBoost C, and has until now always been fine - last known working version was 6.91.

 

Now the output is garbage, most notably, it's not just that the output is wrong (i.e. wrong hex value displayed, but non-printable ASCII is output, which should never happen).

 

static const char conv[] = "0123456789ABCDEF";

 

inline void putc(unsigned char byte)

{

/* output one byte */

while((pir1 & TX_TXIF) == 0);

txreg = byte;

}

 

void puthex (unsigned char p)

{

putc(conv[((p>>4) & 0x0F)]);

putc(conv[(p & 0x0F)]);

}

 

I took a look at the generated asm, and it seems to make sense, but simply doesn't work... (PS: other character/string functions still work fine, so it's not the UART setup, and if I modify the function not to use the string array, it works)

 

regards

 

Phil.

Share this post


Link to post
Share on other sites

Hi Phil,

 

Try something like this:

void puthex (unsigned char p)
{ 
putc(conv[p]>>4 & 0x0F);
putc(conv[p] & 0x0F);
}

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

Hello,

 

thanks for the reply, but surely using p (which could have any value from 0 to 255) as the array index is bound to fail? The idea is to limit the array index to a value between 0 and 15 based on the upper, and then lower nibbles of the input character. Otherwise you'll index past the end of the array and end up with garbage output.

 

I've been using this 'coding trick' to convert from binary to ascii for many years on many platforms ranging from workstations down to PICs, usually it generates compact and fast code. It's only after upgrading (both to v6.95 and to 18f24k20 from v6.91 on 18f2431) that this stopped working.

 

regards

 

Phil.

Share this post


Link to post
Share on other sites

Sorry Phil, I misinterpreted what it was you were trying to do. You want the hex value of p as two ascii chars.

 

Using V6.95 your code does work as it should.

 

FSR0H is not being set but maybe the compilers knows something we don't about its value.

 

Cheers

 

Reynard

 

I take that back. I missed the LFSR instruction setting FSR0H. Doh!

Edited by Reynard

Share this post


Link to post
Share on other sites

Hmm, most odd that it works for you on v6.95 - as I said, it was always OK until I upgraded - but there is of course a possibility that there is an error elsewhere in my code that the upgrade has exposed - I'll double check (that may take a little time). Certainly the generated code looks OK to me...

 

regards

 

Phil.

Share this post


Link to post
Share on other sites
I took a look at the generated asm, and it seems to make sense, but simply doesn't work... (PS: other character/string functions still work fine, so it's not the UART setup, and if I modify the function not to use the string array, it works)

 

I stepped trough assembly generated by this code but could not spot any errors.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Well, I've spent quite a lot of time (on and off) with this, as the problem came and went with different builds. Having checked the hardware, tried 2 different boards etc... and given that for a given build the errors I got were consistent for each run, I did some more investigation...

 

There is a circular buffer of 16 shorts which is used to store capture values - values get added within the interrupt handler, and get popped off in the handler loop... it turns out that instead of the values being stored in elements 0-15 of the array, they actually are being stored in elements -4 to 11! That means that whatever happens to be mapped before the array in memory, gets corrupted - hence the bizarre errors I saw.

 

Now the problem is why is the array 'offset' in memory by -4 (8 bytes)? I can make the app run by forcing the location of the array, and allocating an unused buffer in the 8 bytes preceding it. Honestly at this point I have no idea! The C code was used previously on other chips without a problem. I've looked through the asm code, and it all makes sense, I can't see anything obvious - I'm in the process of trying to construct a simple example for the problem both in order to find out what it is, and if it turns out to be a compiler error, then to provide it to you (the current code is analysis a number of digital signals and decoding them so I can't just send it to you).

 

In general, it seems to be a problem with arrays/pointers and indirection on this particular combination of chip/compiler (18f24k20/6.95) - but exactly what is eluding me.

 

I'll keep you posted when I have more.

Share this post


Link to post
Share on other sites

Finally. So with my suspicions raised regarding why it suddenly fails when changing to the 18F24K20, it turns out that I had (stupidly?) assumed that the extended instruction set would be supported/targetted by the compiler - as soon as I disabled the configuration for xinst, everything burst into life.

However from reading the manual only the usage of FSR2 gets affected by enabling xinst, so as the code I was looking at used FSR0, I'm not sure what was going on... any ideas/comments? btw: some failing simple test code seemed fine on the simulator, but failed on real hardware.

 

So the obvious questions are:

 

1) Does the toolchain support the xinst configuration?

2) If so is there a switch?

3) Any ideas why code built with it enabled would fail (specificallyin using the FSR0 registers)?

 

thanks

Share this post


Link to post
Share on other sites
...1) Does the toolchain support the xinst configuration?

2) If so is there a switch?

3) Any ideas why code built with it enabled would fail (specificallyin using the FSR0 registers)?

 

SourceBoost does not support extended instruction set (neither compilers not the sim/debugger).

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Yep, as I realised. Of course it was my mistake to assume that it did, I'm still slightly confused by the failure mechanism, but will double check the PIC manuals (for my own understanding).

 

 

On searching the Boost C manual, I couldn't find any mention of the extended instruction set (+ve or -ve) - so it doesn't explicitly state that it does support it, but then again it doesn't explicitly state that it doesn't.

 

Can I request that you update the docs to make it clear (just to stop others falling into the same trap as I did).

Also, any plans to support it (allegedly it can give better code for array/structure operations)?

 

Thanks.

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...