Arduino type libraries

[picster]

I'm an alien to Arduino, but it's sure caught on among hobbyists. One of the "selling features" is the availability of libraries to perform standard (and some not so standard) functions, saving a lot of messing about.

I'd like to see a "standard" approach taken for something similar for PICBasic Pro, with a central repository for users to contribute modular code into (preferably indexed or searchable). After all, there's a huge community here.

Code would need to be modular, well documented for PIC requirements, and use variables to describe port pins, etc - which could then be assigned "wherever" by the user via aliases for their particular PIC. I'm surprised this hasn't already taken off, tbh.

Is there some show-stopper that I'm missing, or could some of the senior members put their heads together to come up with a format and standard documentation requirements to make these as easy to implement as possible, to move this forward?

[HenrikOlsson]

It's not very easy to do with PBP due to all variables being global and the lack of proper function calls where you can pass parameters.

Just one very basic example:
Say I write a "library" for a GP2Y0A21 distance sensor and I decide to create a variable called Distance. Then you create a "library" for driving a motor with encoder feedback and you decide to create variable called Distance. Then comes the "user" and finds our, on their own, great "libraries" and wants to use them on his/her new robot. Well, you know what happens.

/Henrik.

[picster]

Hi Henrik,

Agreed, you can't fix stupid... but having said that, if the variables for each are commented at the very onset, then the "user" can certainly take the time to compile a list and change any required with a simple search/replace, no?

picster

[Scampy]

Not quite library files, but PBP does have the function to include files, so you could have a "library" file for a function, such as setting up an LCD or using a specific sensor, and then use one line of code in the main file to include that file as part of the main code, but it has the same limitation Henrik mentioned, in that you have to name the variables carefully. It really helps developing your own projects as you know what the variables are called, but to offer them as a general use for different project could cause confusion.

[HenrikOlsson]

I believe the USERCOMMAND stuff is much closer to what's needed but unfortunately you have to resort to assembly language to use it and there's zero documentation for it in the manual, what's available is what Darrel has posted.

When I write PBP code that I may use in multiple projects I try to use some sort of prefix in my variables. I have a MODBUS Engine and every variable and constant (and usually subroutines) that "belongs" to it is named like MB_Address, MB_Function etc. In my PID "library" all the variables are named PID_Kp, PID_Status, PID_Error etc, I have code that accesses external memory device, when I wrote that I settled on prefexing variables with XEE_ so that I can replace the actual routines accessing the memory device without changing the main program.

It's "workable" but it's FAR from proper function calls, where you can say Average=CalculateAverage(3,10,20,30). For a user to use that library routine, all he has to know is what parameters to pass and what it returns. Trying to do the same in PBP would force the user to lookup the names of the various variables used internally in the CalculateAverage subroutine, load them with values "manually", GOSUB the routine and then, possibly, copy the result from routines "outputvariable" to his own variable, ie Result.

Avg_NumberOfVaules = 3
Avg_Value_1 = 10
Avg_Value_2 = 20
Avg_Value_3 = 30
GOSUB Avg
Average = Avg_Output

This also means that since all variables are global and "in scope" all the time nothing is stopping/helping the user from messing about with variables INSIDE the CalculateAverage subroutine that he really should not need to worry about or have to care about. There are tradeoffs with everything of course.

Writing re-usable code in PBP is hard when you're doing it for yourself, it's even harder if you're trying to do it for the benefit of others.

Local variables and proper function calls has been a requested feature but Melabs says it's never going to happen because PBP isn't written with that in mind from the get-go. I've said that it was totally fine with the 16F84 and its 68bytes of RAM, having the overhead of a software stack etc would be "bad". But now when devices have 500 times as much RAM it's getting hard to manage large projects when EVERYTHING is global. But again, it does have its upsides too of course.

/Henrik.

[pedja089]

I always use include name in front of variable allocated in that include. Eg for ADS1248 include, all variable start with ADS_.
And I create TempB1 var byte,TempB2,3... TempW1 var word..., TempL1 var long... variables in main file of project, and use them for intermediate calculation in all includes and main file. And there variables are newer used in interrupts.
Pin defines are always commented in include file, so I just copy them in main file and write appropriate port names.
Main project file:

 
    TRIS ADCON OSCCON etc register ...
   
'Temporally variables used everywhere
    TmpL1       VAR LONG
    TmpL2       VAR LONG 
    TmpB0       VAR BYTE
    TmpB1       VAR BYTE
    TmpB2       VAR BYTE
    TmpB3       VAR BYTE
    TmpW        VAR WORD
'Variables for project

'Defines for ADS
    SYMBOL ADS_DOUT = PORTE.2
    SYMBOL ADS_SclK = PORTE.3
    SYMBOL ADS_DIN = PORTE.4
    SYMBOL ADS_DRDY = PORTE.5
    SYMBOL ADS_CS = PORTE.6
    SYMBOL ADS_RESET = PORTE.7
    INCLUDE "ADS1248.pbp"

For calling functions I use this
AdsRegAdr=AdsIDAC0: AdsRegVal=%00000111: GOSUB ADS1248WriteRegister
GOSUB ADS1248ReadResult
IF ADS_Result.15=0 THEN..
So it isn't inconvenience, and looks like functions...

I done few includes that I used in multiple projects, and I don't see any major drawback comparing to C. There project are commercial, so I cant share my work.
Also I'm working on WEB server for PIC in my free time, and I had made DHCP just as include file, and to exclude or include just use #IF. That project should be published here when I finish it.

[picster]

I find that documenting my variables and keeping track of them (with multiple modular includes) is one of the most challenging things. I usually create a modular include (sub) if it performs a task/function that I think I'll use again - and just comment it to death - but the idea of having a variable naming convention with a prefix indicating the INCLUDE NAME is a really good idea.