Jump to content

Nigel Titley

EstablishedMember
  • Content Count

    7
  • 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. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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. Before I delve into the BoostC generated code and start building test cases to try and track down the exact problem, has anyone got suspicions about the long integer code in BoostC? Nigel
×
×
  • Create New...