Jump to content

edeca

EstablishedMember
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About edeca

  • Rank
    Newbrie
  1. Nope, it doesn't work properly. I recently did a fresh install of MPLAB and BoostC on a new machine and did press the integrate button. The BoostC toolkits appeared in MPLAB but all the paths were blank and had to be setup manually. I had exactly this issue with the latest MPLAB and SourceBoost on a clean XP install. Was not too hard to fix, but didn't work quite out of the box.
  2. Well that's an unfortunate pain. Will this be fixed in v7? If so, I can probably hang around and wait a while (it was imminent in February). If not, well, I haven't needed 2k code yet so I hadn't paid up. Which means I should start looking around and seeing what quirks other compilers have.
  3. I am trying to compile some code with an array like this: const rom unsigned char Font[96][7] I have seen some previous posts that are obviously trying to use similar code, but none seem to cover the idx compiler option. The initial compilation error is: ks0108b.c(275): error: total number of array elements can not exceed 0x100 (use -idx 2 compiler command line argument to remove this restriction) ks0108b.c(275:37): error: only 8 bit pointers or one-dimensional arrays can have 'rom' storage type But even after the option is added, the compiler doesn't recognise it: warning: unrecognized command line agrument '-idx', skipped .. C:\Program Files (x86)\SourceBoost\boostc_pic18.exe" ks0108b.c -t PIC18F2321 -idx 2 The manual suggests this is a v7+ feature, which obviously isn't available yet. Is there any workaround, or do I have to wait for v7 to compile this code?
  4. Thanks Dave. Is this something that a PIC compiler can support at some point? Or is it a feature which wont appear? I looked at using strtok to do the same, but it doesn't seem to accept ROM chars.
  5. Thanks, but 375, 625 and 875 are definitely outside the 2^8 storage limit for ROM. If there is no way to store character arrays in ROM instead of RAM I will have to think of an alternative. I also wanted to be able to store months and days of the week in a similar fashion.
  6. Thanks, but 375, 625 and 875 are definitely outside the 2^8 limit for ROM and therefore a char is unsuitable. If it is impossible to store character strings in ROM then I will have to think of an alternative.
  7. Below is some code that takes a 16 bit reading from a temperature sensor and converts it to the whole and fraction part. The lookup table takes a lot of RAM, is there some way to store it in ROM? I have seen some other threads but I don't quite understand. If there is no way to store this entirely in ROM then I will have to look for alternate methods, an array in RAM of January..December is going to take way more memory than I can spare // DS620 temperature sensor format // SIGN | 2^7..2^0 | 2^-1..2^-4 | 0 0 0 void convert(unsigned short reading) { unsigned char whole; unsigned char fract; bool positive = true; // This table is good for 3 bit resolution char* fractions[8] = { "0", "125", "25", "375", "5", "625", "75", "875" }; if (reading & 0x8000) { positive = false; reading = ~reading + 1; // 2s complement } whole = reading >> 7; fract = (reading >> 4) & 0x7; if (!positive) { serial_printf('-'); } else { serial_printf('+'); } serial_print_dec(whole); serial_printf('.'); puts(fractions[fract]); }
  8. Post updated with a link to that forum thread. The utility is really handy, thanks!
  9. I have just spent a few hours reading datasheets and header files trying to figure out the right values for the hardware USART driver. I thought I would document it on my website: Using the hardware USART with BoostC and a PIC Comments really welcome either here or on my site, I hope it helps somebody.
×
×
  • Create New...