Decline of PicBasic ?

[Scampy]

Due to circumstances beyond my control I find myself with a lot of time on my hands so I thought I would occupy myself by doing some coding.

A friend has been banging on at me to use an arduino, but I found the structure of the code difficult to understand, and up until now PicBasic Pro has covered all the requirements for my projects. But I had a 2.8" SPI TFT that if I could get working would provide the basis of a revision for an old project. So I dug out the uno and searched the net for some example code and library - I found something and it wasn't long before I had a demo program running (lines of text in all sizes, then lines, fills etc). I then stripped out parts of the code that i didn't need and it wasn't long before i had the screen displaying text in various colours that resembled the layout of the existing project. I then repeated this idea of finding a working example (and there are shed loads of them) for DS1307 RTC, and cut and pasted the parts I wanted into the screen code, followed by code for DS18B20's... and in the space of a couple of days and an evening I have the basic code that reads 4 temp sensors and a RTC complete. Often it's been by chance, adding or subtracting various styles of brackets, comma, full stop or semi-colons and testing after each change until it compiles without error, and the code probably isn't as compact or efficient as it could be, but it works and in around 16K.

I have no idea what's behind the two library files that handle the screen, but it's really easy to set up the text using tft.setTextColor(ILI9341_MAGENTA,ILI9341_BLACK) to print magenta text on a black background. It's a shame that PBP hasn't kept up with these sort of developments. I've no idea how powerful the mega328 chip is compared to say an 18F PIC, but I'm sure these ILI9341 based TFT's would be able to run from a PIC micro.

For me I think what's caused PBP to fall behind is the loss of several members that used to actively post on here and develop solutions, either as example code, or include files. Darrel Taylor being at the forefront, but other members such as Steve (mister -e), Alain, and Melanie. I hate to think what would happen if Henrik, Art, Richard, Ken, and Dave moved away... without you guys forming the mainstay of the forum I feel PBP would be long dead.

I appreciate that developing include files etc takes time ( I was involved with forum member Tabsoft in developing the DHT11/22 sensor library so have some idea in what's involved ), and maybe is not able to employ developers to keep pace with things as other compilers have, but its a competitive market place and if you don't keep up people will jump ship and move away to other products.

[tumbleweed]

There are literally millions of people developing arduino code and libraries. Compare that to the resources of melabs and I think it's pretty obvious who wins. Even if everyone who posts on this forum codes like mad it'll never reach the same level of market acceptance.

Add to that the fundamental difference between the languages and environments (C/C++ vs basically an asm macro generator) and you'll be waiting a loooong time for features like the arduino has. Plus, the arduino tools are free.

Apples and oranges if you ask me (not that you did).

[Scampy]

There are literally millions of people developing arduino code and libraries. Compare that to the resources of melabs and I think it's pretty obvious who wins. Even if everyone who posts on this forum codes like mad it'll never reach the same level of market acceptance.

Oh I agree that being open source nothing can compare to it in terms of support and development. But then you have MikroElektronika - not only have they continued to develop the hardware (easyPIC / AVR range of development boards plus all the addons )- they are / have been developing their compilers, be that Basic or C++ . But then you are right, it's comparing apples and oranges given that MikroElektronika's turnover for 2016 was around £4,000,000, I suspect considerably more than crownhills for the same period based on the limited information available on the web.

[mpgmike]

I'm aware of a "DT_INTS" type book in the works based on the marvelous contributions made by the late great Daryl Taylor. It doesn't compete with the myriad of code, libraries, and examples available for other platforms, but please don't discount the courageous efforts being taken by a select few in the PBP camp. Having looked into various offerings, I chose PIC and PBP for my reasons. I try to contribute where I can, and I sincerely hope the PBP/PIC niche will continue to grow & evolve. Instead of complaining about the lack of support, I try to give it in hopes that others will respond in kind when I need help. The simple answer is if you find yourself more comfortable with Audrino (or any other platform), work with it.

[richard]

But then you have MikroElektronika - not only have they continued to develop the hardware (easyPIC / AVR range of development boards plus all the addons )- they are / have been developing their compilers, be that Basic or C++

I would not be too sure about that. I find the source level debug support is years behind and programmer support not much better for recent chips. I regularly have to use the pickit3 or icd3 on the easypic7 board now for the newer chips. the support for pps is pretty rudimentary also.
imho mplabx/xc8/mcc leaves mikroc for dead now

[Scampy]

I just wanted to share an experience with you guys that is somewhat related to this project.

I've had a 2.8" SPI serial TFT screen sitting in my electronics draw for sometime, and as there is nothing (or at least my searches turned up nothing) to support these devices in PBP I opted to get an Arduino Mega and experiment with that, given that there are lots of library files readily available. Now I've never attempted programming in C++ (or the variant the Arduino platform uses) so it was a steep learning curve (learning Klingon may have been simpler). But after a few days had managed to take one of the example files and hack it about to mimic the layout on the GLCD display in my existing vivarium controller project, only better as the display is colour. So what was going to be just an experiment to prove the TFT worked was now developing into a revision of my old PIC based project.

Over the following couple of weeks I had downloaded examples for DS18B20's, DS1307 RTC, etc and with the help of a friend via e-mails adapted them to suit the projects needs. But the road was never smooth and easy. The strange syntax with brackets, semi-colons, and lack of structure like BASIC made things tricky. Simple things like reading the state of a switch and then jumping out of the main loop to a menu seems to be too low level that its complicated to detect the moment the switch is pressed. It ignores what logic would seem to be easy. For example using the included example that lights an LED when the button is pressed, substitute the making of pin high when the button is pressed to print something on the screen and it doesn't work. The biggest headache has been serial communications.... My PIC / PBP project can be updated via serial and a PC application written in Liberty Basic - it works just fine - replicating that in C++ has caused us so much frustration, whether serial ports on the processor are flakey, or there is a timing issues (no DT INT here ) we have no idea. I did manage to get reliable communications working, but that was the only thing happening, sending numbers back and forth and updating an array, add in the option of reading a single DS18B20 and displaying text on the TFT and the serial coms become unstable with data missing after transmission. I've used a com sniffer to confirm data movement, and the problem is code related.

So for me it's a shame that PBP hasn't kept pace with things like TFT screens, Ethernet etc. After this experience with C++ I realise how much I love using PBP. Maybe given the input and development of routines by Darrel PBP would have been developed further to cover these items of hardware, but sadly we lost such a wonderful person with so much expertise. I just wish I had the skill and experience to be able to develop PBP include files to use TFTs, GLCDs etc but I'm no where near that talented.

Having messed about with C++ I much prefer PBP and will, where possible, use this as my preferred language.

[richard]

So for me it's a shame that PBP hasn't kept pace with things like TFT screens

did you upgrade to pbp3 ?
did you upgrade to pbp3.1 ?


is it any wonder progress has ceased ?

if you upgraded to pbp3 the tft include I provided to the forum is a working system that everyone who has tried it has got functional
all three of them that I know of.
imho pbp is dead with a small amount of deckchair shuffling [on titanic] going on .
I now have ported nearly all my code to xc8 , the mcc is a splendid thing for the chips it supports. my last stumbling block is usb-cdc, mcc seems to have missed usb support for the ubiquitous 18f4550