PBP Glcd

Hi,

Have been looking around at various Basic compilers over the last few days - PBP does seem to receive generally good reviews.

Having tried the free edition of Swordfish I was please to find it was easy to run their GLCD code examples ( it will drive 4 types of controllers )

It seems however, that at nearly twice the price, PBP does not include any GLCD code and a search of these and similar forums does not provide any practical examples that a beginner like me could use.

Does anyone know if there are any examples that would drive, say a 128x64 ks0108 Glcd from PBP - seems a bit of a short coming in a 'Pro' version if there isn't .

thanks


Richard

Quote:

---

Originally Posted by RICHARD.C

It seems however, that at nearly twice the price, PBP does not include any GLCD code and a search of these and similar forums does not provide any practical examples that a beginner like me could use.

Does anyone know if there are any examples that would drive, say a 128x64 ks0108 Glcd from PBP - seems a bit of a short coming in a 'Pro' version if there isn't .

---

The debate between PBP vs other compilers comes and goes...
IMO - PBP is solid, does what you want, nothing more, nothing less.
As far as driving a GLCD, there are plenty of examples here that handle GLCDs of various types (off the top of my head, 122x32, 128x64, Nokia 3100 types, Nokia color LCD from Sparkfun, 2 of which I've personally done). Same thing goes with anything else that PBP doesn't directly support. It's easy enough to add support...
Practical examples that a beginner could use? My thoughts are...and these are ONLY my thoughts...maybe a beginner shouldn't be trying to drive a GLCD, maybe a beginner should be more concerned with flashing an LED first and working up to it. After all, you don't hop into a car at 13 years old and try to hit rush hour traffic in a sports car.

Richard,

PBP is a fantastic language (your best choice of BASIC) If you need greater performance than the BASIC language can provide then C might be worth a look into as well. Believe me when I tell you that it's only marginally more involved than most dialects of BASIC. Built-in functions make things just as easy to do as in BASIC.

Trent Jackson

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...

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

Quote:

---

Originally Posted by RICHARD.C

...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

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.

Quote:

---

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...

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.

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..

Quote:

---

Originally Posted by tenaja

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 ;)

Quote:

---

Originally Posted by mister_e

...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.

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 :D

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 :D

Quote:

---

Originally Posted by tenaja

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?

Usually i don't use this kind of method, but since it has been posted on the public area, I thought I should share the following with our community...

http://www.picbasic.org/forum/showth...3926#post63926

End of post #18 is pretty interesting...

Knowing Darrel don't use nor have PDS... this show how bad PBP & community is :D

Almost sure some other competitor seek through this forum and use it for their own product... but never give credit to whom concern. Benefits and credit goes to the competitors... :(

Oh well, that what competition is all about, no complaint when/if it's better!