how large and complex firmware you design using pbp?

[chrdcv]

Thanks mackrackit!

I would like hear some commentaries about vast usage of BASIC programming dialect in embedded world! Personally, I am re-writting all code in C or forth (programming languages that I dominate), but my boss insistis finishes it with BASIC.

About replicate topic, sorry I put firs message in wrong section then I put again in correct area! I would advice that the same error not will occur again!

Thanks again and have a nice weakend!
christian

[Charles Linquis]

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.

[Bruce]

I've been designing embedded products for over 15 years now. Started on the 8051, and
migrated to the PIC when a friend of mine introduced me to PBP.

I have never looked back to the 8051 series, and have never had a single problem with any
code that wasn't something "I" caused. PBP is hands-down the best BASIC compiler for the
PIC - period.

Write a tiny program - or one that completely fills the chip, and it's still rock soild.

I know it sucks to take over a project done by someone that may/may not have had a clue,
but if you're using PBP, then you have one of the best PIC compilers on the planet, and you
should have no problems cleaning up the mess you've been handed...;o}

I also do a lot of work in C, and assembler, but nothing beats PBP for quick & reliable results.

[Acetronics2]

Hi, CHRDCV

Reading your post Twice ...

I do not think you are facing a "tool" problem ... but "Method" problem ...

as Bruce says ... " nothing beats PBP for quick & reliable results " and I really do agree !!! On my amateur side, I build lots of programs ... but each program for few chips !!!

You won't find a better tool for developing applications quickly ...

IF you look for Bytes saving ... do not say PBP need Huge memory room nor ( cf your point 3 ) : PBP produced code for tables is very close to assembler !!! ... and the "structure" is very similar !!!

Most of time it is a "programming style" issue, as Basic permits dozens of ways to solve one "operation"
Some funny contests on this forum have shown code size factor could vary from 1 to .... 10 and even more !!!


Now ... the ONLY Basic language ( straight following the manual ... ) "weakness" i've found is for interrupts ... that often leads to carefully design the flow of the program.
But with some "unregistered" tricks ... It can be as quick as Assembler !!!

And remember "structuring" a program is not a must with Basic ... but it greatly helps to get a readable listing ... once more, it's not a Language but writer question.


In the End ...

What elders did is not always stupid ... they just thought another way of us ...

What about trying to understand their work a bit ???

Alain

[Pedro Santos]

Hello

It depends what you want doe. For many years i wrote all my programs in PBP Pro and all work fine. For a new project that i need use spi, sd card with FAt32, Color TFT, RTC and Temperatur i have change to Atmega2561 and BAscom and i can only say fantastic. I like PBP Pro but all that i need for the project the Bascom compiler support it and mutch more.
For little projects i use sometimes PBP Pro

Regards
Pedro

[chrdcv]

Thanks all for answers!

I think that like say Mr. Nygaard: "Programming is understanding", independent of the used languages. But even language have yours tricks and my intention here is know more about then in pic basic pro.

I describe the current work for give some ideas and find similars works made with the same language, in last metrics of the entire project, I discover that all project have 11675 lines (excluding commentaries and pre-processor directives). So to implement new methods, I will need know more about the greats techniques using pic basic pro and re-write some pieces of code. In firs view of actual code, I´ve found some unstructural programming method (large usage of goto´s) and wast time in main loop using pause , serin2 and another polling methods. My first intention is re-write these methods in structural way, withou of use of goto´s statements and communications serial polling for two hardware serials.

In essence, the product is one avl then I need some peaces of code giving support for "application" code.

Again, thanks a lot ...

[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!