Goodbye

[sayzer]

I also don't want to decipher someone elses code with out documentation. That's a waste the time? It seems to get you off track of the REAL project at hand. I have found that most Libraries aimed for the Arduino system lack documentation. Most designers of the Arduino systems are just PLUG and PLAY type people. If it doesn't work they are on to a new project or modifying someone else's code to make it work for there purpose and NOT documenting it....

IMHO,

I agree with this.

People with less electronic and/or programming knowledge are using Arduino with ready to use sample codes.
And if there is something wrong, they ask "you" to solve the issue;
So at the end, it gets back to "you" as a headache anyway.

[Scampy]

It's strange how the Arduino platform gets lumped in with the raspberry pi and other single board computers, but the two are so far apart. Unlike the Pi and other single board computers, the arduino doesn't run an operating system (typically linux based). The arduino platform is similar to PICs in that you upload compiled code in a HEX format.

I've only recently dabbled with Arduino's for the reasons already stated, but all the examples I found and used were well documented, either on the website I found them on, or in the comments within the scripts. I was able to either extract parts of the code I needed for my project, or use the complete code as a routine within the code. No different than taking a sample code from the code section on this forum and modifying it to suit my own needs.

Agreed nothing ever stays still, and maybe PBP has had its day. From what I gather, for commercially robust PIC based projects the preferred method of coding is either some form of C or direct assembly code. Over the years I've been associated with many a forum on various hobbies, and have seen them go the same way as this forum, from being so active that its hard to keep up with posts in an evening, to hardly a single post in two or three weeks, all because the company behind the products never kept up with progress. Years back I was approached by a fellow forum member who wanted to give something back by offering a free library for PBP, and between us (he coded and I tested) developed the DHT22 / AM2002 library for that range of sensors. But surely, with PBP being a commercial product, these sort of things should be part of its development and not left to its users to develop ?

Given the above, I can see why a lot of people have move to a different platform or compiler. Which in some way is sad as I used to love the knowledge that I could get a quick reply to an issue from a handful of experienced and regular users.

One of the comments someone mentioned was that these days people seem to want to get something running without understanding what goes on under the hood so to speak. Is that a bad thing? When I coded in BPB I was interested to learn how the code worked, the logic behind it, but I have no real interested in what goes on inside the PIC, with stuff being moved in registers or whatever. The part I often struggled with was when the likes of Darrel, and Henrik helped out and provided code for a project was when there was no alternative but to add in some assembly code inside the PBP code. I appreciate and bow down to their knowledge, but it was no point them trying to explain the ASM code as it never sank in, and when I asked why they had to use ASM it was either because there was no function in PBP to do what was required, or because it was quicker than the equivalent PBP command for some reason.

I never migrated to PBP3 as I couldn't justify the cost for the small amount of hobby projects I developed, so a lot of my comments and experience relate to 2.60c. Also as a lot of my projects could be developed around PICs that my EasyPIC5 supports rather than the newer PICs I couldn't see the need to upgrade. I'll still come back here on a regular basis, just to see how things are, but I sadly can't see myself using PICs and PBP for my next project.

[Normnet]

A somewhat poor analogy but relevant none the less: An OCR (optical character recognition) system was developed to transfer data however was discontinued as it was found a skilled typist could enter the data more reliably that being OCR errors proved quite difficult to spot.