how large and complex firmware you design using pbp?

[rmteo]

I have a program that completely fills a 128K part (18F8723). It has about 8000 lines of source, and the .HEX file that I use to program the part is 342K bytes.

Just out of curiosity, what does your application do that takes up 128K?

[Charles Linquis]

Monitors 9 fan tachometers, 5 analog voltages, 4 temperatures, 4 currents and up to 32 humidity sensors, displays all data on LCD and LEDs, drives about 10 parallel I/O and runs relays and controls fan speeds on the basis of temperature using the PWM controller, talks over RS-232 and Ethernet using UDP, tcp, SNMP and SSH protocols. The heavy network stuff is handled by a Lantronix XPORT or MatchPortAR, although all the SNMP and trap handling is done by the PIC.

Virtually everything is programmable through menus. All the display, entry and bounds checking routines take up quite a bit of codespace.

[rmteo]

Thank you, Charles.

[chrdcv]

Incredible Charles! congratulations for its work! Very nice!

How you structuralized the source code? You use state machine with interrupt for receive data from RS232? And the "parser" for decode each string from serial? You can post more details?

Thanks, christian

[Charles Linquis]

I can give you a few details.
The tachometers are read with an ASM interrupt on a 500uSec timer. Input ports are read and XORed against their last readings. If any bit has changed, a corresponding variable is incremented.
After 1 second (2000 interrupts), the variables are stored and the process repeats.

A main PBP loop reads the stored variables and calculates the fan RPMs. It also reads the A/Ds, calculates the required PWM values and writes that value directly to the hardware PWM registers, and writes to the LCD and LEDs. Another counter in the main timer interrupt routine paces everything.

Two PBP interrupts read the two USARTS and process input serial data and SNMP packets.

It does quite a few other things as well, but I have a conference call starting in a few minutes!

[Charles Linquis]

A few more details - the main PIC communicates with a network of current, humidity and pressure sensors. Each of the remote sensors is built with an 18F2321. Every two seconds the main PIC sends three bytes - the address, a command, and a checksum to all the slaves using DEBUGOUT (since all the USARTS are already used). The appropriate slave sends back 4 bytes - the address of the slave, two bytes of data, and a checksum. Open-collector mode is used so that the outputs of the sensors can all be tied together on one wire (an 820 ohm pull-up is used). The slaves all respond to address 254 by default on programming. Whatever number is sent in the command byte to a slave at address 254 becomes the slave's new address and is stored in the '2321's EEPROM. This way a slave's address can be set without using jumpers. The slaves all run on their internal 8Mhz oscillators, and amazingly, communicate reliably at 19.2K baud with the master (which is running at 40Mhz).
I did have to modify PBPPIC18.LIB to allow DEBUGOUT (on the slaves) to run open-collector.

The slaves basically read their associated sensor(s) and then sit in a tight loop waiting for the main PIC to send their address and command. As soon as they recognize their address, command and checksum, they wait 10uSec and send the data back.


This is probably more than anyone wanted to read, but you asked...

[Ron Marcus]

I started on PBP, and have designed hundreds of programs for commercial products. I was tempted to play with Swordfish for 32 bit variables, but since Melabs released 2.50, I have had no need. The most timing critical app was a video on screen display using a 16F628 and gated oscillator. This I did in assembly.
Being an RF junkie, I recently started programming the TI 1110 and 2510 RF transceivers. These are 8051 derivative cores, so C was the only way to go. It was a real challenge going from PBPs "anything goes" forgiving language to a fanatically rigid structure of program writing, but it helped my coding style.
I still haven't hit my head with PBPs capabilities, but I'll keep trying!
Ron

[Archangel]

This is probably more than anyone wanted to read, but you asked...

Nope, sometimes the thought process behind the code is more valuable than a code example. Very interesting, Thanks Charles !
JS