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