Decline of PicBasic ?

[Scampy]

Just wondering what peoples opinions are as to whether PicBasic has run its course or been impacted with the recent flood of other embedded systems that have now come onto the market such as Arduino, and now the microbit.

The PBP 2.6 and 3 sections used to be heaving, with lots of regular contributors, and plenty of topics, but these days you can return to the forum after a break of a couple of days and there has only been a single reply, and usually from one of three regular contributors.... does this mean less and less people are using PBP ?

[DaveC3]

I can only speak for myself, I do not make as many projects from scratch as I used to, but when I do I find PicBasic the fastest to get something put together. I am using other pre-made platforms such as arduino, Raspberry Pie and generic cheap 32 bit ARM boards for experimenting. I have also noticed a decline in activity in this forum. A few years ago I used Microchip devices exclusively. Now not so much.

Dave

[HenrikOlsson]

This has been discussed several times, here and on the MeLabs forum.
I suspect hobbyists on a budget go to Arduino or something else that doesn't cost anything.
8bit uC with a couple of hundreds byte of RAM isn't "cool" when you can have a 32bit 1GHz multicore CPU with a Gig of RAM to read your DS1812 and turn on a LED.
The hobbyists who do use PBP generally know what they're doing so they don't need much help. Those who do need help come here, ask their question or request for working code and then their gone - until the next project surfaces.
Professionals tend to use C - just face it, C is THE language for embedded stuff and mentioning BASIC usually makes professionals cringe because they think of some old interpreted BASIC they played with in the 70's.
Those professionals that do use PBP don't visit the forum because they don't need the help it provides - with the odd exception. Why? Because they generally can't post their code since it's not theirs (but their employers) to post.

So it really is up to all of the forums users, (you, me and everybody else) to pitch in if we want to see "traffic".
Ask questions, provide answers, post well written and documented code examples etc. Don't expect everybody else to do it.

/Henrik.

[Boater]

Maybe people like me are part of that decline.
Started into electronics and PICS about 2 years ago and found the only way I could get going was with MicroCode Studio Plus vers 5 with PBPX3 compiler which doesn't seem like PicBasic to me.
All I have done is flash some Leds, but then this is a hobby with me.
I enjoy looking into the forum, even though most of it is way above my head.
I'm no spring chicken and still remember the old BBC basic days.
Anyway I hope it doesn't decline to much.
Regards
Jim

[Heckler]

PicBasic is still my goto for any microcontroller project.

Lately I have been wondering and concerned what might eventually happen to the VAST amount of knowledge that is contained within this forum.
I cringe at the thought that someday this forum might be unavailable.

Before that might ever happen I myself would love to be able to get a copy of all the posts contained here in some fashion. If we could somehow get a copy of what is here for offline searching that would be great.

There is a wealth of knowledge here and it would be a shame for it to go away.

I am ~57 and do not see myself ever going to any other platform for my projects that require a microcontroller.

I have often wondered why MElabs doesn't take a more active interest in this forum (possibly they do and I just don't realize it)
I know Darrell (RIP) was here often.
I have been over to the MElabs forum a few times but always find that the support and knowledge base here dwarfs what they have over there.

Hopefully this discussion is VERY premature and this forum will be around for many years to come. :D

others thoughts??

[HenrikOlsson]

Jim,

Started into electronics and PICS about 2 years ago and found the only way I could get going was with MicroCode Studio Plus vers 5 with PBPX3 compiler which doesn't seem like PicBasic to me.
Can you elaborate on that last bit? What are you referring to with the term PicBasic?

The "problem" (no, its' not actually a problem) is that there are several BASIC compilers targeting the PIC microcontroller families. Most of the have the words BASIC and PIC in them and although they're all more or less based on the original BASIC language they are not the same.


Dwight,

I have often wondered why MElabs doesn't take a more active interest in this forum (possibly they do and I just don't realize it)
I know Darrell (RIP) was here often.
I have been over to the MElabs forum a few times but always find that the support and knowledge base here dwarfs what they have over there.
As far as I know there's no one from MeLabs here, Charles (from MeLabs) is on their official forum but if you think this forum is quiet you should look at that one, not a single post for weeks now.

As of what will happen with PBP that was "discussed" on their forum a little while back. Basically they (Charles) said that IF they were to do a new compiler for 16bit PICs it would come at a cost ($600-$1000) that no one participating in THAT discussion seemed willing to pay.

And if I were to read between the lines the current PBP for 8-bit PICs is what it is. There will be bug fixes (there was a new version issued a couple of weeks back) and new devices added but apart from that nothing will happen - but that's MY interpretation. So we'll just have to wait and see, there was just an update issued so it's not dead yet and I'd REALLY hate to see it go because it's the only programming language for PIC that I know how to use, sadly enough.

/Henrik.

EDIT: Here's the thread (http://support.melabs.com/threads/1138-Future-of-PBP-Compiler) on MeLabs forum, if you want read it.

[mark_s]

Some good points above.

I follow a lot different interest and hobbies and have noticed in general, forum activity seems way down across the board. With well over ten years of solid internet access, most of the information and ideas are published. With google you can find most any info in minutes. So why ask questions on a forum and chance seeming stupid or lazy.

I don't think PBP is finished, but not going to advance at this point. It will be maintained as long as Microchip produces the 8 bit family and the ME founders don't retire. It would be a monumental task to catch up - pic24, dspic30, dspic33, and pic32 etc. Plus the new generation of techies want everything for free so it's not a good business plan. I use Mikroe complilers also and it seems they are stalled. Slow updates, unfixed bugs, they push hardware products now for the most part. Proton Basic came out with 16bit compiler a few years back, you don't hear much about that? Arduino/open source and chip makers with free dev tools are killing the old names. Once you learn C you can buy any 8 to 32bit platform for cheap, use the free compiler, free libraries, no programmer or power supply nessesary, just a usb cable. Hard to compete!

[Boater]

Henrik
I think you elaborated on my last bit very well "although they're all based more or less on the original basic language they are not the same".
Some picbasic I understand but not all but then I'm pretty new to this.
I hope it doesn't decline to much.
Regards
Jim

[Boater]

Or maybe Me Labs is going to bring out PBP4 with anl upgrade price tag???
Regards
Jim

[Scampy]

Interesting comments guys. I think Mark has hit the nail on the head, in that there is so much free stuff out there anyone starting in the hobby will tend to opt for this route rather than purchase PBP or Mikroe compilers, and with Henrik's comments about modern 32bit micro's there is so much more power than there used to be a few years back when nearly everything was 8-bit as the cost of anything else was prohibitive and un-supported at the time.

Being a hobbyist I might work on a project once a year, but even with the vast power of Goggle prefer to post questions here amongst friends. I've had some excellent support from members off the board, and even help contributed to a "library" file which was great fun to do, and it's this relationship you build up with people here that would be missed if the forum simply becomes a look up reference site rather than an active forum. Maybe it's just a sign of the times. Several other forums I frequent are experiencing the same decline on posts, often a facebook group is set up and that for some works better.

For the record I hate C - I struggle with the Arduino code structure as it seems so alien. I too got into programming through the introduction of home computers back in the 1980's, spending nearly every hour of the day programming a ZX81 using its quirky BASIC, and then using MBASIC on an CP/M based Amstrad 8256 ! - so PBP seems quite "normal" to me. It's interesting to hear comments about the Mikroe side of things. A few years back I considered moving to MikroeBasic mainly as they had so many library's for their add on boards such as Ethernet, pressure and other sensors, which were lacking in PBP, but it seems that the enthusiasm of the developers to support the compiler is also now behind, from what's been posted in this thread. - Shame really.

Mind you I guess this is only really an issue when you need to do more than the basics such as read some sensors over I2c, turn on some pins as a result of whatever condition is met, and display the result on a serial or 4 bit LCD. If you want to interface with a TFT touch screen and hook up to wi-fi then you're knackered as most of the 8 bit processors will be pushed to their limit to get the results you need. Fortunately for me, most of my projects do not require the latter :)

[ruijc]

In my case, i prefer picbasic rather than arduino or other.
I also think that picbasic is much easier that C (arduino) to learn and use (also dont like much the arduino software platform to upload hex files comparing to microchip).

The only thing i notice is that the arduino platform is so popular because of the libraries. If picbasic makers (and i mean the developers/creators of picbasic) would create more code blocks and libraries, it would be much more popular. Darrel Taylor (programming magician), for example, shared lots of ideas and code blocks for everyone to use. Since the time we lost that kind man the forum started to speed down. There are many users here in the forum that share and help but i think that the developers should contribute and release blocks of code for sensors, displays, usb, etc,etc.

I dont think that arduino is a low budget platform unless you want to build only a couple of projects. Sure picbasic licence is expensive but if you like to build many projects ( hobby or not ) arduino it self gets more expensive that costumized projects.

[HenrikOlsson]

There are many users here in the forum that share and help but i think that the developers should contribute and release blocks of code for sensors, displays, usb, etc,etc.

One issue with writing PBP code for sharing and reusing, which I mentioned in the thread on the other forum, is that it can't be "self contained" due the lack of functions and local variables. That makes it hard to write complex stuff for reuse since it's SO easy to get it "tangled up" in the "main program". Examples of HOW to do things is easier than writing universal "libraries" for PBP.


I dont think that arduino is a low budget platform unless you want to build only a couple of projects. Sure picbasic licence is expensive but if you like to build many projects ( hobby or not ) arduino it self gets more expensive that costumized projects.
Well, the software (compiler, IDE, bootloader, libraries etc) are all free to download - and that's really what we're talking about, right - the software. The Arduino hardware is just a bog standard Atmel microcontroller (which is now Microchip by the way....) with the previously mentioned bootloader programmed into it. Sure, if you buy genuine Arduino boards it'll cost money but buying development boards to put into finished product costs money no matter which uC you're using. You don't need to do that, you can just buy a blank microcontroller, design a board for your product and use the code that comes out of the Arduino development tool/compiler.

And no, I'm not jumping ship. I'll stick with PBP for as long as it's around, or until I get to a point where I "have to" use something else.

/Henrik.

[Art]

I’d only ever use it for mid range controllers now.
I’m not sure what the beefiest pic is that PBP even supports, but do know that’s the first limitation one will run into.
The next one for me is native floating point variable types.

[lester]

Lately I have been wondering and concerned what might eventually happen to the VAST amount of knowledge that is contained within this forum.
I cringe at the thought that someday this forum might be unavailable.

Before that might ever happen I myself would love to be able to get a copy of all the posts contained here in some fashion. If we could somehow get a copy of what is here for offline searching that would be great.

There is a wealth of knowledge here and it would be a shame for it to go away.

I am ~57 and do not see myself ever going to any other platform for my projects that require a microcontroller.

I have often wondered why MElabs doesn't take a more active interest in this forum (possibly they do and I just don't realize it)
I know Darrell (RIP) was here often.
I have been over to the MElabs forum a few times but always find that the support and knowledge base here dwarfs what they have over there.

Hopefully this discussion is VERY premature and this forum will be around for many years to come.

others thoughts??

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.

[mackrackit]

Thank you Lester!!!

[queenidog]

I just went through a process of selecting between Arduino, PBP/PIC, and Raspberry Pi. I have hardware for all and have used each one for a project.
My next project will use i2c which the mentioned hardware all supports. I have a bunch of Arduino boards, but programming is C++. Rasberry Pi has no good editor (like PBP), in fact the "nano" editor is 30 years out of date. I programmed Motorola assembler for years with a better editor 30 years ago!!
So, after considering all three, I'm doing my project with PIC 16F887 and PBP. Why? Best editor on the market (MicroCode Studio), tons of pin-compatible chips, easiest programming in the world, by FAR. RPI would have meant Python language which is as bad as C++. Too syntax heavy, no easy subroutine methods, hard to use labels and macros.

[Scampy]

I just went through a process of selecting between Arduino, PBP/PIC, and Raspberry Pi. I have hardware for all and have used each one for a project.
My next project will use i2c which the mentioned hardware all supports. I have a bunch of Arduino boards, but programming is C++. Rasberry Pi has no good editor (like PBP), in fact the "nano" editor is 30 years out of date. I programmed Motorola assembler for years with a better editor 30 years ago!!
So, after considering all three, I'm doing my project with PIC 16F887 and PBP. Why? Best editor on the market (MicroCode Studio), tons of pin-compatible chips, easiest programming in the world, by FAR. RPI would have meant Python language which is as bad as C++. Too syntax heavy, no easy subroutine methods, hard to use labels and macros.

I quite agree with your logic, however outside of these basic protocols such as I2C, etc PBP is seriously lagging behind the competition. Mikrobasic would appear to support all the add-on boards that they make for their development range of board. Arduino has a stack of library files for all manor of things to make projects easy to get started even if you have little understanding of C++. For me, as a casual user, the cost of upgrading to PBP3 when that came out was not an option, but I don't feel that even with this release there is native support for things such as ethernet (fixed and wifi) etc.

[mpgmike]

Like Queenidog, I occasionally look at other available options. Just looking at PIC, I compared the PBP package to Microchip's MPLAB X using CX8, and a few other things. I stay with PBP because I am comfortable with the language, first and foremost. Microchip charges $995 for their XC8, but they support it with a plethora of prefab turn-key plug-ins and code generating wizards. If you have issues, they have their forum. I saw posts where folks tried getting ahold of a live human being at Microchip for support and it was almost funny. Charles Leo (MELabs) takes my calls, answers my emails, and supports PBP very well in most areas. He is mostly a one-man show. The fact that we got the K40's in a relatively short period of time is a testament to his tenacity. As I type, he is nose-to-the-grindstone preparing the next PBP3.1.x update to include K42 and a couple other tweaks. Looking at other available options, $269 for PBP3.1 seems to be very well spent money.

With that said, I stay with PIC because Microchip keeps up-to-date with new features and new products. PIC is extremely competitive in today's MCU market. I engineer entire projects, so putting a 20-pin MCU on my board makes more sense than interfacing a daughter board (Audrino or RPi). A friend of mine that has worked at an engineering level with analog electronics since the early 1970s finally took the plunge and bought something Audrino. He couldn't fully express just how proud he was that he could control a stepper motor; adding I couldn't possibly know how difficult it was, much harder than I'd think. I gave him the verbal pat on the back, thinking how PIC has Enhanced CCP that makes it rather simple.

Go the direction that makes the most sense to you. I love the PIC/PBP package. I just wanted to share a few thoughts.

[Art]

There’s a free version of XC8, which I haven’t tried, but suspect the difference in efficiency between the free and paid version are much greater
than between the paid and free version of XC16.

XC16 is GCC which Microchip only charge for the use of optimisation options, which is rude, because Microchip didn’t contribute anything to GCC.
That said, you can always compile GCC yourself.

It’s a dream, and I’d never use PBP for a 16 bit pic even if it ever was supported. PBP will never be as developed as GCC.
The difference between C and BASIC isn’t the same as the difference between RISC assembler and BASIC.. which early on,
was the general choice you had to make for 8 bit pics (whether the BASIC meant PicBASIC or BASIC stamps).

[richard]

There’s a free version of XC8, which I haven’t tried, but suspect the difference in efficiency between the free and paid version are much greater
than between the paid and free version of XC16.
quite possible but the free xc8 combined with the mcc is extremely useful , I have nearly converted all my libs to xc8 now and swaping between chips and chip families is just sooo easy.
debugging is fairly easy you don't even need to set watches just hover over var in ide when debugger paused to see actual value .
pbp has been left in the dust

[Art]

I’d still go for PBP over XC8 for 8 bit pics... Probably just because I feel I’d have better control over the final asm.
That’s just a gut feeling, with no real evidence, the same goes for you with your PBP experience.
But keep it up with XC8 because you’ll have no problem using a 16 or 32 bit pic.

One question: Does XC8 have a floating point math library with associated trig functions, etc. ?
If not, a dsPic project will change your life!
But there are still simple tasks that are overdone using anything other than a cheap 8 bit micro.. for that I like PBP still.

[richard]

Does XC8 have a floating point math library with associated trig functions, etc. ?

yes it does , you can select 24 or 32 bit format floats.
math.lib with sprintf add 9k to a pic16 pgm size .

[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

[Scampy]

Hi Richard,

No I didn't upgrade at the time due to the cost and personal circumstances. Maybe it's something that I should look at, but then you have already stated that you are porting your contributions to another platform and will (by the sounds of things) no longer supporting PBP, so maybe it's not a good time for me to upgrade to PB3 given how quiet it is around here and I should consider other options.

[mpgmike]

my last stumbling block is usb-cdc, mcc seems to have missed usb support for the ubiquitous 18f4550
Frankly, after spending 2 years struggling with USB I bit the bullet & purchased HIDmaker. Using HIDmaker, I'm better understanding what I read about and fought with for 2 years. The punch line is I'm functional with USB now.

Scampy and others, a very wise man once told me, "If it is to be, it is up to me." It's nice when I can post an issue on the forum and find someone that has tackled it already. However, when I can't, I just dive in and figure it out myself. All those wonderful Audrino Include files were developed by individuals with the attitude, "If it is to be, it is up to ME!"

[Ioannis]

Mike:
1. Since arduino libs you can find online are if I may say, un-official you cannot trust them for something serious. For hobby it is ok
2. About the hid maker. Can you build a project and never worry about port settings like USB to serial converters? I mean make a really plug and play device?

Ioannis

[mpgmike]

HIDmaker creates the files needed to transfer data between the PIC (in variations of C as well as PBP) and the PC (in Visual Basic, Delphi, and I believe another tool). You get skeletal code to build around. After playing with it for a few months, I'm developing quite a sophisticated dashboard for my controllers. As for the port settings, I just find it and connect. I love HIDmaker!

[Ioannis]

That's nice. So I need to extend now on VB...

Ioannis

[mpgmike]

There is a few sites with a limited function free version. I bought the professional version of Visual Studio 2015. Of course, the newest is 2017. I also bought about a half dozen books to try to learn how to use it. I have worked with industrial PLCs & HMIs in the past which helped me grasp VB quicker than I otherwise could have. At this point I'm barely functional with VB, but I'm getting some cool things done with it.

[Ioannis]

VB6 used to produce easily a stand alone installer to distribute to others.

After that the new studio I tried was too complicated and never managed to make a stand alone installer.

Also I found it much different (as a language) and had not enough time to learn it. Was not proficient with VB6 either but seemed easier to make small projects.

VB6 does not work on new systems anyway. A solution for now I found is to ask a friend and do some apps on LabView but I really have to do the VB way some day.

Ioannis

[pedja089]

For CDC(usb serial port) you have example from DT. And you don't need any PC software, except drivers. And you have another serial port when your device is plugged in.
If you want HID comm, then you need host application.
Only pain with USB is high cost of VID(only 5000$ per year).
But you can try to get free PID and VID fro microchip on request.

[mpgmike]

Only pain with USB is high cost of VID(only 5000$ per year).
It's $4000 per year to become a member of USB-IF. There are only about 500 members. The $5000 is a one-time fee to purchase the Vendor ID (VID). With it the purchaser receives 65535 Product IDs to use any way he/she wants.

For playing, though, you could enter just about any number you want for VID & PID. Just don't sell a product doing that. DT used numbers in his examples. Not sure if he paid the fees or borrowed those numbers. And yes, Microchip has a program where you can request one of their VID/PIDs when you are using their components in your product.

[pedja089]

If I remember correctly DT use test PID/VID from microchip.

[towlerg]

For playing, though, you could enter just about any number you want for VID & PID. Just don't sell a product doing that.

I wonder what the sanction would be against selling a product with an unused VID, it's not like a DNS entry that the internet police can delete? I quess nothing at all.

[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! :D
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.

8620

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

8621

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

8622

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