Decline of PicBasic ?

[Scampy]

You are correct in using the registers directly. PBP does not always support hardware modules, like I2C using only software.

But on the other hand, PBP gives this easy of use and piece of mind in a, say, LCDOUT $fe,line1,"Hello!".

What's the use of PBP if one needs to do some asm or C like digging into the registers?

Ioannis

I have to agree. I dare say most things like TFT screens, Ethernet etc that doesn't have native commands in PBP could be used could work with the aid of asm code etc, but then IMO that then defeats the object of using PBP.

[mpgmike]

PBP simplifies working with SFRs over ASM. For example:

ASM
MOVLW 0x60
BANKSEL OSCCON1
MOVWF OSCCON1
ENDASM

versus:

OSCCON1 = $60

More & more I manipulate Registers manually, but in PBP where practical. I reserve ASM for time sensitive operations. Even without PBP Commands to do everything possible, the PBP IDE Suite is certainly more user-friendly than MPLABX.

A mentor once told me, "Instead of complaining something should be done, go and do it!" I can appreciate the frustration of not being able to get a PIC to do what you want it to do, and it's convenient to blame something other than yourself, like PBP or Microchip. With much discussion about Audrino, take it for a test drive, see if you like it better than PIC/PBP. Perhaps take the time to read the Data Sheets and Application Notes/Technical Bulletins available. What I have found is there is always a way to get it to work; I just needed to learn how.

Admitted, I work with PIC & PBP as part of my job. As a hobby I don't think I would devote as much time & resources to educating myself. However, when all else fails, Read the directions/Data Sheet/Application Note/Technical Bulletin/book.

[richard]

I dare say most things like TFT screens, Ethernet etc that doesn't have native commands in PBP could be used could work with the aid of asm code etc, but then IMO that then defeats the object of using PBP.

while thats true a pbp that can incorporate external libraries and the sort of memory management needed to support them would not resemble the existing version in any familiar way. it would also need to support all the existing on chip hw modules and pps, not to mention have realtime source level debugging. [xc8free does all that and more]
if you look around all the pic 8bit forums are pretty quiet and getting quieter , a few have diappeared . its not an enviroment to inspire investment .

perhaps we could add a couple of new dimensions to the forum

xc8 and asm

and be more like a pic8 support group. pic hardware is pic hardware and pbp is stalled ,but we can still learn .

any thoughts ?

ps i have not joined the microchip forum , i do look but have not found it particularly useful

[Ioannis]

ps i have not joined the microchip forum , i do look but have not found it particularly useful

I did but initially was not treated very friendly...

Anyway, as many said, select the proper tool for the job.

PBP is not for SD cards or Ethernet (natively that is). So, either use a module to do this or XC8 or ... Arduino.

For me PBP gives me a very speedy project development for the things it can do.

I wish and also asked Melabs for the 16/32 bit support and I thing it will come one day, but not tomorrow.

Ioannis

[Art]

LCDOUT isn’t a particularly slow command, but a better example I thought of in English is if you only ever send one byte at a time with an LCD,
you inherently strip the dead delay that LCDOUT has to put between bytes, because you can be using that delay to process the next byte live.
So everything is faster for something simple, and that’s still PBP.

Hmm the Microchip company forum, I haven’t found bad reception there when I do use it, more that either none can answer the question,
or just haven’t been very helpful for a specific problem for one reason or another. Better help with C or assembler stuff I have found on other forums altogether.

[Scampy]

The one thing that struck me when I got into programming PICs with PBP was the warm friendly welcome I received on this forum, and regardless of what I was seeking assistance on always received the support in a kind and helpful way. Hentik, Darrel and Alaine have all been instrumental in getting my multi-channel reptile environment controller project up and running, and looking at the work involved was beyond my level of knowledge or experience. I'm currently doing a re-write for the Arduino platform and as mentioned it's been a steep learning curve, especially given the fact that most of the forums are no where near as friendly or supportive as it is here.

Whilst Art has mentioned that these high level languages hide what goes on under the hood, for me as a hobbyist I'm not that bothered. The TFT library the Arduino uses is no more complicated than PBP's LCDOUT command (tft.print ("hello") for example) and for me that's all I'm after. I have no idea how powerful the chip on the mega2560 is compared to an 18F PIC (other than the mega has 256K of memory !!), and if this is the limitation of PBP when it came to developing it to embrace new hardware such as SD cards, TFT screens, or wifi modules, in that its chip support is now limited to devices that even the hobbyist would now not consider as being the first choice because by modern standards they lack memory or functionality. I still have my old (and no longer supported) EasyPIC 5 development board, and where possible will continue to use PBP and PICs for any future projects, provided the hardware requirements are covered.

[mpgmike]

If I had a major gripe, it isn't with PBP, it's with the occasional mistake in the data sheets. For example, look at this first picture. It clearly states in the body of text regarding CCP that all 4 PICs represented in this data sheet come equipped with 2 CCP modules.



When I tried to compile, I got errors for everything related to CCP2. I opened the PBP document describing all functions pertaining to the PIC16F1765 only to find there was no CCP2. Frustrated I looked at the Memory Map for it. It should be in Bank5; see next picture



How bad was this mistake? Looking further I discovered that the PIC16F1768_9 does indeed have a CCP2. Look at Bank5 in the next picture



This is the second time I tried to use a Special Function listed in the body of text describing that SFR, which the text claims is there, only to find the error.