Decline of PicBasic ?

[Ioannis]

The obvious thing is that the arbitrary selected VID/PID may be already known to Windows/MacOS etc and the system load the wrong drivers. These drivers will not work with your PIC of course.

The second are Legal consequences I suppose, as you are using something that is protected and must be paid so you can use it.

I have not cared so far as I have limited production and cannot justify the expenses of 4-5K $USD. I prefer, as long as I can, to use serial or ethernet solutions but to read the long legal documents, you may apply and read them.

Ioannis

[John_Mac]

Please keep this going! I will be back after a long hiatus. The wealth of knowledge here has always solved my problems. I'm not throwing out my old PICs and want to be able to have access.

Thanks for doing this Lester.

I have no intention of closing this forum or the ProtonBasic forum. Both will run for as long as i am able to keep them running.

If at any stage it looks as though I may not be able to support the forums, I will offer the community the opportunity to take total control and arrange alternate hosting.

Of course situations change, I cannot guarantee anything, but that is my current thinking and has been the commitment that I have made several times in the past.

The PICBASIC forum and the PROTON BASIC forum have been run and supported by Crownhill Associates for many years. Prior to the forum and web discussion formats Crownhill ran and supported the mailing lists. Crownhill have been supporting PICBASIC via an online support platform since 1996......there is no plan to cease.

[Art]

Oh man, you can cross me off the list sorry Scampy, I have long moved away!
PBP can’t support newer devices simply because PBP compiles to 8 bit RISC assembler, and would have to be entirely rewritten to support dsPic or Pic32.
I still visit in some effort to stay fresh because I maintain PBP is still my choice if a task does call for an 8 bit controller, but I don’t find that exciting at all.
PBP has (had) far more going for it in terms of transparency, and it’s use as a stepping stone than the Arduino environment will ever have.

It’s never been the job of a language or compiler to support any particular hardware unless that language or compiler came part and parcel with a particular computer.
Any serial display is far less complicated to interface with than an HD44780 character display. There are only libraries already existing for the Arduino ecosystem that
make things easier. PBP certainly does support any display that Arduino can though.

The best thing you could do for yourself is to move as far as possible away from the PBP manual, which is full of bad practice in it’s own examples,
and also as far away as possible from it’s canned library routines (commands).
Did you know that to write to a character LCD only requires the control of a port and two pins without any use of LCDOUT?
At least assuming it’s permanently wired to write as they typically are.

LCDSENDINSTRUCTIONBYTE:
enable = 1; // set enable pin
RS = 0; // set data or instruction (0 = instruction)
port = bytevalue
delay
enable = 0 //
RETURN

LCDSENDDATABYTE:
enable = 1; // set enable pin
RS = 1; // set data or instruction (1 = data)
port = bytevalue
delay
enable = 0 //
RETURN

That’s it! It only takes two more small routines to entirely abstract away the LCD hardware to the same extent that LCDOUT does.
There’s never a time in any real program that the string “Hello World” will be available at your fingertips.
Data always arrives byte by byte from somewhere, and that is how PBP canned commands and manual examples are a hinderance.

byte = $FE : GOSUB LCDSENDINSTRUCTIONBYTE // clear display
byte = $01 : GOSUB LCDSENDINSTRUCTIONBYTE
byte = $FE : GOSUB LCDSENDINSTRUCTIONBYTE // return home
byte = $02 : GOSUB LCDSENDINSTRUCTIONBYTE

Get some ASCII data from serial:

FOR i = 0 TO 20
SERIN byte : GOSUB LCDSENDDATABYTE
NEXT i

All untested and quite impractical pseudo code of course (though will mostly be right), and some delays are needed,
and in four bit mode, bytes are set nibbles a a time,
but enough to catch the drift, and closer to a normal cyclic program flow than manual examples.
The PBP manual doesn’t really give any good example of how a program would really work. only proper syntax.

[Ioannis]

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

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

[Art]

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

For the use of any language or platform other than PBP, which might be around forever,
but it's supported pics become less & less appropriate for a project as better peripheral devices come along.
If you used any PBP supported pic to control an ESP8266 for example, the peripheral chip is much more powerful,
and the PBP program and hardware it’s running on could only hinder the entire project,
and also require the unnecessary part that is the PBP microcontroller.

I wouldn’t want to even think about using PBP to interface with an SD card with any standard file system.

Most importantly though, every PBP manual example that could possibly block code execution when it doesn’t have to, does.
Typically a programmer aims for the illusion of the program doing multiple tasks simultaneously, which becomes harder and harder with blocking code.

Arduino does assist with this, but it isn’t C that is anything like PBP in this way, only libraries that others have written.
Arduino is also another trap that is limited in ways because it hides workings from the user in a similar manner PBP does,
to prevent the user having to think about it, and also prevent them breaking things.
Arduino is essentially C, but doesn’t do much to help anyone learn much about any other C compiler (for example).

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

[Dave]

One thing I try to do is look for the actual data sheet and NOT the Preliminary sheet. I have found in the past MicroChip does NOT update the Preliminary sheets. It is in the footer...