PDA

View Full Version : In what order do we construct a PBP program?



xnihilo
- 13th October 2008, 09:34
There are various things to write in PBP code but what would be the best order? I put the things empirically but is there an optimal way do do it?

DEVICE DECLARATION
'--------------------------------------------------------------------------
@ device pic16F690, intrc_osc_noclkout, BOD_OFF, PWRT_OFF, wdt_off, mclr_off, protect_off
'--------------------------------------------------------------------------

EEPROM PRESETS
'--------------------------------------------------------------------------
DATA @0,0
'--------------------------------------------------------------------------

OSC DEFINE
'--------------------------------------------------------------------------DEFINE OSC 8
'--------------------------------------------------------------------------

LCD DEFINES
'--------------------------------------------------------------------------
DEFINE LCD_DREG PORTB
...etc
'--------------------------------------------------------------------------

VARIABLES DECLARATIONS
'--------------------------------------------------------------------------
respawns VAR BYTE
'--------------------------------------------------------------------------

CLEAR STATEMENT
'--------------------------------------------------------------------------
CLEAR
'--------------------------------------------------------------------------

REGISTERS SETTINGS
'--------------------------------------------------------------------------
INTCON = 0
TMR0 = 98
T2CON = %00000000
PR2 = %00110001
OSCCON = %01110001
CM1CON0.7 = 0
CM2CON0.7 = 0
ANSEL = %00000000
ANSELH = %00000000
ADCON0.0 = 0
OPTION_REG = %01000110
TRISA = %111111
TRISB = %0000
TRISC = %00000000
WPUA = %011111
WPUB = %0000
PORTA = %011111
PORTA.5 = 0
PORTB = %0000
PORTC = %00000000

SYMBOLS DECLARATION
'--------------------------------------------------------------------------Symbol head = PORTA.0
...etc
'--------------------------------------------------------------------------

VARIABLES INITIALIZATION
'--------------------------------------------------------------------------
a = 0
...etc, and:
READ respawns_,respawns
'--------------------------------------------------------------------------

INTERRUPTS SETTINGS
'--------------------------------------------------------------------------
a = PORTA 'clear any mismatch with latched values
INTCON = %00001000
IOCA = %011111
IOCB = %0000
'--------------------------------------------------------------------------


SET INT HANDLER
'--------------------------------------------------------------------------
ON INTERRUPT GOTO in_sig
'--------------------------------------------------------------------------

START:
normal code here

in_sig:
(the int handler)

skimask
- 13th October 2008, 16:49
There are various things to write in PBP code but what would be the best order? I put the things empirically but is there an optimal way do do it?
At least you got a plan and stick to it..
About the only change I would make is to put the interrupt handler somewhere near the beginning and skip over it. This will keep the interrupt routines as low in code space as possible. They run just a tad bit quicker because there is just a few less BANKSELecting going on, at least on 16F type PICs. Same thing with any commonly used subroutines, right after the interrupt handler, but before the main loop, for the same reasons.

Archangel
- 13th October 2008, 17:30
Put your Port declarations before your Tris registers, so when the code turns on the outputs they will initialize in a known state.

xnihilo
- 13th October 2008, 21:56
At least you got a plan and stick to it..
About the only change I would make is to put the interrupt handler somewhere near the beginning and skip over it. This will keep the interrupt routines as low in code space as possible. They run just a tad bit quicker because there is just a few less BANKSELecting going on, at least on 16F type PICs. Same thing with any commonly used subroutines, right after the interrupt handler, but before the main loop, for the same reasons.

Thanks.
My program is a huge INT handler :p
I thought there was some special sequence, so it does not really matter?

"Put your Port declarations before your Tris registers, so when the code turns on the outputs they will initialize in a known state. "
-> Okay. Right, that's a very good reason.

Normnet
- 13th October 2008, 23:33
You know I'm sure I've answered this very topic before, but damned if I can find it. Perhaps it was on the email list when I used to subscribe to that...

Anyhow... I near enough follow the same program structure every time for most of my programs... I can write a book about how and why things should be structured a particular way, but basically I pretty much ALWAYS follow the same pattern...

1. Comments & Objectives
2. PIC Config Fuse Definitions
3. PIC Hardware Definitions (ie Pin-Out & Port Assignments)
4. Software Definitions
4a. EEPROM Assignments
4b. RAM Assignments & variables
4c. Software Constants
5. Actual Program Start (usually a "Goto Start" jump)
6. Subroutines
7. Start: (Program Starts Here)
8. PIC Register Initialisation
9. External Hardware Initialisation (eg LCD's)
9a. External Hardware Settling Delay (usually needed with LCD's)
10. Loop: (Main Program Loop Point)
11. Main Program Body
12. Loop Counter & PIC/LCD Reinitialisation
13. Goto Loop
14. Interrupt Handler
15. Error & Special Handlers
16. End

Sometimes for simpler programs I put my subroutines at section 15 rather than at section 6 and do away with item 5, however placing the subroutines at 6 does save on Program Codespace (see other threads for further comments on this).

I am however MOST PARTICULAR that ALL Hardware definitions are together, all RAM definitions are together (and more often than not in alphabetical order too), likewise Constants, Subroutines etc etc. That way, I know where to find whatever I'm looking for. In larger more complex programs, I even place my subroutines in alphabetical order so I can find them easier (ie the subroutine GetKey will be located before the subroutine GetMessageExternal). Little things like that all help.

Section 12 needs some explanation. You initialise the PIC Registers at section 8. It's naïve to assume that they will stay that way forever. Static, EMP's and other disturbances do affect your hardware. To guard against those, I reinitialise my important PIC's registers (TRIS, OPTION_REG, CMCON etc etc) every 'n' times through the Loop (and secondary registers like ADCON before I use that particular piece of PIC hardware). Doing it at every pass is a waste, but I tend to reinitialise sometime between five and twenty seconds or so, and if I have an LCD, I ensure the display is cleared ($FE,1) and completely redisplayed at least once per minute. To this end I have PICs in the field that have been running constant 24/7 Mission Critical applications without break for YEARS on end in hostile Industrial Environments without failure. Obviously if your applications are not Mission Critical and you can afford to have your PIC throw an occasional wobbly, you can skip section 12.

Any one of these sections (especially individual subroutines) can be replaced with an "include" statement. My 3-Button Keyboard handler for example is pretty much identical in every program I've ever written that uses those 3 Buttons, as are subroutines for certain functions like displaying messages from Internal or External EEPROM, Date and Time verification, higher Math functions, and the list goes on and on. They are obvious targets for using "include". But I don’t do it.

Why? Because I like to 'see' everything in my program when I scroll through it. Sometimes you'll spot something obvious that you'd otherwise miss if it was invisible (having being linked with an "include"). But that's just my personal preference.

Melanie

10-24-2004?

Norm

xnihilo
- 14th October 2008, 14:25
Pretty cool.
Thanks Norm. And happy to see you arer back. Your computer survived after all?
Did you by any chance have a look at the code I mailed you about a month ago (port to PBP and Microchip eeprom of your serial sound)?

Normnet
- 14th October 2008, 23:11
xnihilo

I now have a new PC.
I PMed my correct email address.

Norm

xnihilo
- 15th October 2008, 08:18
xnihilo

I now have a new PC.
I PMed my correct email address.

Norm

Right, I have resent a mail at the address, I hope you will get it.
Have a nice day and hope to hear from you soon. Best regards.