PBP Glcd

[Ioannis]

...what happens if they do not extend the range in the years to come...

And I am sure they won't extend the support to 16xxx series with GLCD support. These routines need a lot of program memory and speed.

Ioannis

[tenaja]

Proton (PDS) is a PBP-like basic compiler that has GLCD support. For reference, a very short program takes up about 750 program words, about 1/3 of which is the GLCD commands, half is the font file, an the remainder is the basic code that you actually type. Additional GLCD command use takes very little space. Just like all of the other commands, adding the first one is what consumes the most overhead; additional commands just load registers and call the existing subroutine.

In any case, this really is not very much memory, considering how many PIC's have so much more than 4KB of space, and they go on up to 64KB or more. The amount of overhead really is irrelevant, unless you are counting your pennies on the PIC--and that's unlikely if you are using basic to control a GLCD.

The real issue is that PBP is more designed to be a beginners tool, primarily for those stepping up from Stamps. Most of those beginners don't have what it takes to make a GLCD work, with or without the basic commands. If you must have built-in commands, look at PDS or SF for Basic. PDS has the advantage of being as simple as PBP, but more powerful. SF is no where near as simple, but it's more capable.

[mister_e]

The real issue is that PBP is more designed to be a beginners tool,

Well that's probably the most funny one I saw since awhile but anyways... let me dry the beer i've spilled everywhere here..

It's not what you have, but what you do with... Power is behind the keyboard not in the computer... But yeah, it looks better because it's simpler.. sob sob sob...

[tenaja]

Mister E, that is not supposed to be a limitation upon the tool, but a description of their target demographic. You do not see PBP advertised in advanced embedded engineering journals, do you? No, but you do see several C compilers advertised. MELabs designed PBP to be a step up from Stamps--the language is almost an exact copy. It's 99% fool proof, compared to C which is about 10% fool proof. And they advertise almost exclusively in the hobby magazines.

Of course, it is all about what you can do with the tool. It is an excellent tool. However, you will never get PBP code as compact or as fast running as any C compiler, and probably the other two basic compilers, and certainly no where near as compact as asm code. It is not designed for maximum efficiency or anything else... just maximum ease.

[mister_e]

Unfortunately or not, Basic language still have poor reputation, where C language is more considered as Industry standard... no coincidence why it's the one most University I know will teach. In fact C and ASM, whatever MCU brand you're going to learn. No either a coincidence why Microchip have developped their own C compiler and push only third party C compiler(but since few months they also have PBP in their online store.. i don't see PDS over there.. did you?). In the past, ONLY C compiler covered the whole PIC range.. still true... but sure enough MikroeE will raise a PIC32 compiler soon... 'till now.. only C.

Microcontroller are the heart of many, see most new electronic devices, get the job done, as fast as possible... and that's it. I agree many compiler have much more than PBP to offer as standard feature for even less of PBP price, such as: Float, Trigs, Strings, GLCD, etc etc. And that's great, that's what competition is all about. And yes it's much more attractive for new potential customer... "Hey, for the same price or less, I have GLCD feature... I don't know what the heck a GLCD is... but I have it Woohoo, i also have float-point maths... etc etc etc"

Yes Melabs should work on that... but is that a real must? I'm not Melabs, I'm not going to speak for them. One thing is sure, I'm satisfied with, and I use it most of time. 'Till now, I've never been disapointed about their compiler, it's rock solid and work as advertised. If something doesn't work as expected, they have a real great tech support, we have the forum, AND we have access to the library (as in many other compilers).

OK, I'm not a new-comer, so I built, and i still prefer to build my own routines for many different hardware... GLCD is one in the list. Sure I lost time, but I learn something... is this learning stage worth the time invested? I think yes, but it's me. Do i use the built-in features of the compiler... yes and no. For ALL compiler, most of the built-in command can be skipped and be replace by a few code line to generate a faster, a tighter and much efficient code. BUTTON, HPWM, PULSIN, COUNT are some in the list for PBP, equiv is also available in ALL compilers. This raise your point..

Of course, it is all about what you can do with the tool. It is an excellent tool. However, you will never get PBP code as compact or as fast running as any C compiler, and probably the other two basic compilers, and certainly no where near as compact as asm code. It is not designed for maximum efficiency or anything else... just maximum ease.

General fact, you have more line to type in C than in BASIC to do the same job... and that's one thing user are afraid. "Why should I write/read to the CCP register while HPWM is easier to use?" Same rules apply for ADCIN and so on. But i'm not going to tell that all C compilers provide tighter code that Basic compilers... there's a load of Bloat one. Same rules apply in asm.. you can create real bloated ASM code. Still bring this... "the power is behind the keyboard" thought

All compiler support everything... the software programmer (AKA end user) don't

[tenaja]

...But i'm not going to tell that all C compilers provide tighter code that Basic compilers... there's a load of Bloat one. Same rules apply in asm.. you can create real bloated ASM code. Still bring this... "the power is behind the keyboard" thought

All compiler support everything... the software programmer (AKA end user) don't

Ah hah, but not all compilers are equal. PBP was designed with 100% redundancy, and every single command resets the bank registers and program pages. You find this with very few compilers, and it enourmously bloats the code. PBP is an excellent tool for making working code in short time, but it produces very large code that does not run very fast. Compare the output to almost any other compiler... I would be surprised if you find even one compiler that is less efficient with code space or execution time.

[mister_e]

I don't know, I don't care, I don't do any benchmark test, I don't trust any benchmark test, I just find solution... when needed

I like competition though... unless I wouldn't be able to do what I do on a daily basis. I wouldn't use any PIC24, DsPIC, PIC32 or other Microcontroller brands/model either

[skimask]

Ah hah, but not all compilers are equal. PBP was designed with 100% redundancy, and every single command resets the bank registers and program pages. You find this with very few compilers, and it enourmously bloats the code.

Just had a good look at one of my .lst files for a rather large program (80K on an 18F4685), using almost all the on chip ram. Went thru and eyeballed most of the MOVLB instructions along with anything else that modified the SFRs. As far as I can tell, PBP/MPASM do a very good job of keeping track where the BSR was to know if it has to be changed to what it needs to be. And I'm sure it's much, much worse on the 10/12/16 series PICs.
But yes, left to fend for itself, PBP CAN produce very bloated code. That's when it comes down to the keyboard operator to know that DEFINE NO_CLRWDT 1 can easily save a load of space (as is mentioned in the manual, but not directly in so many words), on most PICs, keeping commonly used variables in one bank can also save space/time by not switching banks all the time (mainly on the 10/12/16 series). Would the average programmer know that? Well, I didn't know it at first either. I figured it out accidentally by reading a datasheet one day after about a year of programming with PBP.
PBP doesn't come with optimizations built-in...true...
Among the more complicated projects, I've made it do an MP3 player (hard drive/CF based w/external USB support via FTDI), audio spectrum analyzer (128 channel), OBD2 interface (w/ 2 types of GLCD, no assembly required), 36 channel medium freq software based PWM (for LEDs), and so on. Only the spec'an required an assembly subroutine to function. The rest of them could've been done with bone stock PBP...but they weren't
Not arguing the point (well, maybe a little ), just pointing out a few things that a programmer might learn over time to make PBP a more robust tool.
Why haven't I bought one of the other compilers with more options built in? Because I've already got a compiler with those options practically built-in (into my head anyways).
Besides, I've got enough to think about, let alone trying to remember which compiler I'm using for which individual project!
If you're so dead set against PBP, why are you here?