Jump to content

philb

EstablishedMember
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

0 Neutral

About philb

  • Rank
    Newbrie
  1. Hello Bill, thanks for the offer of help, however I think you didn't quite get what I was trying to do - it was all about determining the address of functions and manipulating the address to make it suitable for modifying the code at runtime. * Issue 1: No, the function pointer is the correct type (i.e. pointer to function of "void foo (void)") - it's not the return value of the function I want, but the address of the function. As a "function pointer" is a pointer to a function, it should contain the address of the function being pointed to (which is fine on other architectures, b
  2. Thanks for the clarification. OK, so it's a 'speciality' of PICs that this sort of code wont work. Perhaps you can suggest how I get the address of a function into a 16-bit variable... is it only possible using assembler? btw: I need the address of a function as my application performs self-modification to switch between sets of interrupt handlers (i.e. it reads/modifies/writes the first 64-bytes to change the jump addresses for the high/low priority interrupt handlers) - this allows each (separate) mode of operation to have optimal interrupt performance. To do this I need to know the
  3. Sorry I disagree - this form of code is fine on various platforms using various compilers (e.g. GCC on x86) - how else would you generate function pointer based callback jump tables in code such as DLLs/shared objects? A function pointer is a variable of a standard type - it must have a size and location, and in essence is the same as any other pointer. If you initialise a function pointer variable to the address of a function, then the storage associated with the function pointer should be initialised to the address of the function. What you later choose to do with the contents of that
  4. Hello. v6.95 on WinXP, compiling for 18F24k20. When I try to use function pointers I get weird results, for example: typedef void (*fp) (void); void TestFP (void) { //determine the values to input fp low = InitCapture; //any global function with the write signature fp high = ClearRDSState; //ditto unsigned short adrs = (unsigned short)high >> 1; puts("\nhigh value is: "); puthex(adrs>>8); puthex(adrs); adrs = (unsigned short)low >> 1; puts("\nlow value is: "); puthex(adrs>>8); puthex(adrs); } the output sho
  5. 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 bett
  6. 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 ob
  7. 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!
  8. Oops, sorry about that - I was using the old one. Yep, it's clear in the current manual, my mistake. regards Phil.
  9. 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.
  10. No problem. However the compiler error message is somewhat cryptic. May I suggest you update the user doc's to make it clear that the only valid syntax is the multi-line one. thanks. Phil.
  11. 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
  12. v6.95, win XP, 18f24k20 Now I know this is a bit odd, but... I'm toying with dynamically switching the interrupt handlers, by reflashing the first 32 bytes so that the GOTO's point to different handlers. So I need to have multiple instances of high and low priority interrupts. Part of the experiments in this area have been to create the correct prolog/epilog code in the new handlers... which mimics the code in the default handlers. The below code compiles and links.... extern unsigned char Int1Context[4]; void my_interrupt_high (void) { asm { MOVFF _fs
  13. v6.95, on WinXP, compiling for 18f24k20 After a bit of chasing around it seems that the compiler is very picky on the placement of the curly braces when using inline asm - i.e. the curly braces must be on separate lines... code of the form void foo (void) { //some C code asm { tblrd*+ } //some more C code } will cause the compiler to throw a 'missing paren' error on the following function. whereas: void foo (void) { //some C code asm { tblrd*+ } //some more C code } is fine. From memory I think that even void foo (void)
  14. 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;
×
×
  • Create New...