PBP Glcd

[mister_e]

As far as GLCD as concern, why Melabs don't include them in the built-in feature?

Well, there's a load of Different Graphic controller, there's no official standard one, but some more popular model. KS0108 is one of them. I agree , they should consider to include it.

There's quite a lot of pre-canned example for PBP, i think the best one to start is the one from Electronic Workbench website
http://www.compsys1.com/workbench/On...ontroller.html
and the code
http://www.compsys1.com/support/PBP_Files/glipic/

Swordfish is not a bad compiler, but only for 18Fs. There's few other compiler who have GLCD built-in feature as well. It's really up to you to decide... do you want to learn something, or you just want to do something...

[RICHARD.C]

Hi guys,

Many thanks for you helpful comments.

I am a beginner to Basic but do have some assembler experience, part of the reason at moving to Basic was the fact that USB and GLCD was a more accessible option that could be used in the future.

It just seemed a bit strange that the Pro version did not have such a feature; thought I might have missed something about it when reading up.

While Swordfish does have a good working GLCD sample - as rightly pointed out, it only supports the 18F range, which is my current device, but does raise the question of what happens if they do not extend the range in the years to come.

thanks again,

Richard

[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