Jump to content

Nigel Titley

EstablishedMember
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Nigel Titley

  • Rank
    Newbrie

Contact Methods

  • MSN
    nigel@titley.com

Profile Information

  • Gender
    Male
  • Location
    UK
  1. Well, I think I may have fixed this. Secret is to use a MOVFF instruction to load data into the RTCCFG register // Unlock the RTCCFG register rtccfg_tmp = rtccfg; set_bit(rtccfg_tmp, RTCWREN); asm { movlw 0x55 movwf _eecon2 movlw 0xAA movwf _eecon2 movff _rtccfg_tmp, _rtccfg } rtccfg_tmp is a global unsigned char and because the MOVFF instruction doesn't need a bank switching register the compiler doesn't put a MOVLB instruction into the middle of the load sequence.
  2. I'm getting this exact problem when trying to enable the RTC on the PIC18F27J53. This requires an eeprom2 = 0x55; eeprom2=0xAA; set_bit(rtccfg, RTCWREN); sequence and whatever I do I get the spurious movlb 0x0f instruction in the middle of the sequence, which breaks the operation. I've even tried asm { movlw 0x55 movwf _eecon2 movlw 0xAA movwf _eecon2 bsf _rtccfg,RTCWREN } Which generates 2834 0E55 MOVLW 0x55 2836 6EA7 MOVWF gbl_eecon2 2838 0EAA MOVLW 0xA
  3. I generally use a switch statement to build a small (4 state) state machine to do this, but I'm usually debouncing multiple switches in parallel and I don't want to hang around waiting for each switch to settle.
  4. I know how this *should* work. The tested value is tested once only at entry to the switch statement. So in this case, the code in all three cases is executed in sequence and at the end "a" will be equal to 3 and both do_something() and do_another_thing() will be executed.
  5. That's because the MPLAB X IDE is doing its own syntax checking and "interrupt" is a reserved word in the X8C compile which it expects you to be using. The syntax in X8C would be void interrupt foo() { } whereas sourceboost would expect just void interrupt() { } I can't offhand think of an obvious fix.
  6. Does anyone have thoughts about how to work around the FASTINTS bug in the PIC18F4550 silicon. The microchip X8C compiler puts in appropriate workaround code but the sourceboost compiler doesn't. Actually this is a generic question. How do the sourceboost compilers handle known silicon bugs?
  7. Does the BoostC compiler support the "offsetof" macro? I can't find it anywhere and I can't make any of the published suggestions for it work. The "offsetof" macro indicates the offset of a structure member within a structure and is typically defined as #define offsetof(type,member) ((unsigned long) &(((type*)0)->member)) This doesn't work in BoostC, however.
  8. I'm trying to implement the SHA2-256 hash function in software. There are a number of C implementations of this using unsigned 32 bit integers which should have been simple to just port to the 18F4550. It uses 32 bit logical operations and 32 bit unsigned additions. I'm a reasonably competent C programmer, and I've checked a couple of these implementations on 32 bit machines under Linux. They seem fine. However, when ported to the 18F4550 they don't deliver the correct hash. As far as I can see, the problem can only be incorrect code generated for 32 bit integers by the BoostC compiler.
×
×
  • Create New...