• About PSAS
• Get Involved!
• Schedule
• Projects
• Presentations
• Mailing lists
• Contact us

• Teams
  • Airframe
  • Avionics
  • Communications
  • Ground
  • Payload
  • Propulsion
  • Rocket Science
  • Safety
  • Software
  • Uncertainty
  • Regulation
  • PSU Student Club

PicCore Coding Conventions

Here are some thoughts from your friendly neighborhood PicCore programmer.

Things that actually matter:

• Keep the code very, very simple. Weird convoluted C-isms may screw up the compiler. It's a good solid, broken compiler. Always remember that. But mostly, don't forget, I have to understand it.
• Try to think like a PIC (Auuughh! The PPPAAAAIINNN....) and emulate that in C. Ugly, but efficient. That's why I call it "broken C":
  • Try to use bit and uint8_t's whenever possible.
  • Use static as much as possible; accessing auto variables takes a million years because pointers are so slow on the PIC. More correctly, it's 3 cycle access versus one cycle access, but PICC18 swaps out the pointers (the FSR registers) all the stinking time so it's really more than that.
  • User code that tests for bits. That's fast on a PIC. We've got 32K of flash on the 18F series, so don't be afraid to trade code space for speed.

Things that don't matter as much but I'll whine at you if you don't pay attention:

It's nice to see consitent-looking code, especially when you have to look at a lot of it. With that in mind, we've tried to be pretty consistent about how code looks:

• Tabs are four spaces (no tab characters)
• Try to keep it under 80 columns, definitely keep it under 120 columns (everyone's got >80 column editors these days, but there's no reason to go nuts)
• Use C++ style comments '//' for fast line-be-line comments
• Use C style comments for block comments
• Use a line of dashes '-' to seperate blocks of code
• ALL functions have (similar) comment boxes:

/--------------------------------------------------------------------------- | Function: get_battery_state | | Purpose: Sample battery voltage, make some kind of state-of-charge | determination even though voltage sucks for that kind of thing. | | Discussion: We need to get the state of the battery - charged, discharged, | etc - but we don't have a charge count (or even a current | meter!) so we'll use the battery voltage as a terribly rough | state of charge meter. | | Expects: to be called at least once a minute. | | Date | Notes |------------|------------------------------------------------------------ | 02/24/2004 | Created. ---------------------------------------------------------------------------/

• Tried to break up the code into modules which encapsulate some kind of function (e.g., all interrupt code in one module, all main line code in another, etc.)
• Brace Style:

void function (void) { if (condition) { if (condition) { statements; } } else if (condition) { statements; } }

• Functions names: all lower case, use underscores to seperate words:
  • function_name(arg), e.g. piccore_error(GPS_SERIAL_QUEUE_OVERFLOW,PE_LEVEL_WARNING)
• Enums and #defines are all caps with underscores:
  • INTS_CORE_ISR_ENABLED, PE_LEVEL_CRITICAL, etc.