|
Post by Carl Gundel on Dec 6, 2019 21:44:04 GMT -5
|
|
|
Post by sarossell on Dec 7, 2019 13:38:02 GMT -5
Ooh! I don't know what you have in mind for control of the Raspberry Pi GPIO ports, but native commands would be awesome. Most other implementations use the WiringPi access library written in C (http://wiringpi.com/), but the programmer recently stopped development (August 6, 2019). It would be great if LB 5 had its own set of native commands that felt more like the kind of BASIC we all love. There are alternatives to WiringPi, but it sort of became the de facto solution. You can already do GPIO in Liberty BASIC on the Pi because Raspian has a file system interface to access it. Any software that can read and write files can do GPIO on the Pi. Certainly, with Linux, everything is a file. And that's pretty cool. I had read the thread on the forum before regarding interfacing with the Pi and was greatly encouraged to see the ease at which Mr. Iverson demonstrated the essential digital LED function. At it's most basic level, the Raspberry Pi GPIO is a simple interface. And to be honest, we're primarily concerned with the Liberty Basic universe here, so at first glance, dedicating native commands to the GPIO seems..."off topic". A person could get knee-deep into libraries for just about any aspect of a computer's functionality. And there's a reason why Gordon Henderson's WiringPi library became so popular in the Raspberry Pi universe. There are functions for pin modes, i2c, analog, pwm...I mean, there's a lot; (http://wiringpi.com/reference/core-functions/). Beyond the core functions, there are SIX additional libraries! So, I'm not suggesting LB become or replace WiringPi - although, if that did happen, it would be A-MAZING!. And realistically, if someone's that excited about it, they can write their own functions or DLLs. We're all about the BASIC up in here. I do humbly suggest however that the Raspberry Pi is not just "yet another Linux machine". In fact, it's actually a very sophisticated, computer controlled, GPIO interface which just happens to be running a version of Linux. In spite of that fact, there isn't a single language - including the RasPi crowd's favorite poster child; Python - that includes native commands for GPIO. So there's certainly no precedent for Liberty Basic to have to do so. But how friggin' cool would it be if it did?! A company in the UK came out with a whole computer based on a Raspberry Pi with a keyboard, mouse and even an experimenter's breadboard built in called the Fuze (https://www.fuzebasic.com/bin/FUZE_BASIC_Reference_GuideV3.pdf). It came with it's own version of BASIC installed which included commands for the GPIO that was a re-branded version of yet another Gordon Henderson product; RTB BASIC (http://project-downloads.drogon.net/rtb/rtb.pdf) pages 71 and 72. This BASIC was able to distill the GPIO commands down to a very usable 7 constants and 9 commands to cover ALL of the various GPIO functions. A simple blinking LED program looks like this: // Blink program pinMode (0, pinOutput) cycle digitalWrite (0, 1) // Pin 0 On wait (0.5) digitalWrite (0, 0) // Pin 0 Off wait (0.5) repeat end Liberty Basic could easily do the same with something like: ' Blink program open "myLED" for GPIO as #myPi #myPi, "!pinMode (0, pinOutput)" do #myPi, "!digitalWrite (0, 1)" ' Pin 0 On call pause 500 #myPi, "!digitalWrite (0, 0)" ' Pin 0 Off call pause 500 n = n + 1 loop until n = 10
sub pause mil t=time$("milliseconds") while time$("milliseconds") - t < mil wend end sub end Yes, I'll admit it, since 1981 I've wanted a computer with a GPIO interface running BASIC with built-in commands like 'GPIO read analog pin8' or maybe 'Open "electric_train_set_controller" for GPIO as #heckYeah". A guy can dream, right? I love the fact that you've chosen a cross-platform architecture with LB 5. It can't be easy having to deal with the unique requirements of each operating system. Attempting to accommodate the Pi could quickly become a "stylebits" scenario; a really popular group of commands of no value whatsoever to the Mac and Linux crowd. I don't envy the challenges you face. Regardless, I'm just thrilled to see Liberty Basic taking its show on the Mac and Linux roads. I hope they quickly see what the PC folks have known for so very long; Liberty Basic Rocks! Jus' sayin' :@)
|
|
|
Post by Carl Gundel on Dec 7, 2019 16:49:13 GMT -5
So, I'm not suggesting LB become or replace WiringPi - although, if that did happen, it would be A-MAZING!. And realistically, if someone's that excited about it, they can write their own functions or DLLs. We're all about the BASIC up in here. I do humbly suggest however that the Raspberry Pi is not just "yet another Linux machine". In fact, it's actually a very sophisticated, computer controlled, GPIO interface which just happens to be running a version of Linux. In spite of that fact, there isn't a single language - including the RasPi crowd's favorite poster child; Python - that includes native commands for GPIO. So there's certainly no precedent for Liberty Basic to have to do so. But how friggin' cool would it be if it did?! I would be happy to produce a Raspberry Pi specific version of LB, but I'm not sure that I should.
|
|
|
Post by sarossell on Dec 7, 2019 21:10:21 GMT -5
So, I'm not suggesting LB become or replace WiringPi - although, if that did happen, it would be A-MAZING!. And realistically, if someone's that excited about it, they can write their own functions or DLLs. We're all about the BASIC up in here. I do humbly suggest however that the Raspberry Pi is not just "yet another Linux machine". In fact, it's actually a very sophisticated, computer controlled, GPIO interface which just happens to be running a version of Linux. In spite of that fact, there isn't a single language - including the RasPi crowd's favorite poster child; Python - that includes native commands for GPIO. So there's certainly no precedent for Liberty Basic to have to do so. But how friggin' cool would it be if it did?! I would be happy to produce a Raspberry Pi specific version of LB, but I'm not sure that I should. I'd have to defer to your experience and wisdom on that note. Of course, I would happily enjoy having Liberty Basic native on all platforms. I am confused by your statement though. Would there be some advantage to having a specific RasPi version as opposed to the cross-platform image approach? Wouldn't a "specific" version just lead to potential upgrade lags or even code forks?
|
|
|
Post by Chris Iverson on Dec 7, 2019 21:40:11 GMT -5
I would be happy to produce a Raspberry Pi specific version of LB, but I'm not sure that I should. I'd have to defer to your experience and wisdom on that note. Of course, I would happily enjoy having Liberty Basic native on all platforms. I am confused by your statement though. Would there be some advantage to having a specific RasPi version as opposed to the cross-platform image approach? Wouldn't a "specific" version just lead to potential upgrade lags or even code forks? The problem is that the functionality you seek, while it would be very highly regarded, would basically require/necessitate a Pi-specific version of LB, as all of those features do not exist on other platforms. So if those commands are to be included, writing a universal language becomes impossible. I suppose he could just make those commands into dummy commands that do nothing or give a runtime error on other platforms, but that's still uselessly expanding the scope of LB on other platforms, though it does have the benefit of a unified codebase. You mention it as functionality comparable to STYLEBITS in LB4, which is a Windows-only command out of pure necessity (it's a bridge to give access to a Windows-specific feature), but what you seem to have missed is that LB5 will NOT have STYLEBITS commands, BECAUSE it's Windows only. Instead, my understanding is he intends to expand the commands available to widgets to allow a substitute for most of what we used STYLEBITS for, that will work cross-platform. There's also the problem that LB5 would likely need to depend on a native library like WiringPi in the first place as a backend for those features.
|
|
|
Post by sarossell on Dec 7, 2019 22:16:21 GMT -5
I'd have to defer to your experience and wisdom on that note. Of course, I would happily enjoy having Liberty Basic native on all platforms. I am confused by your statement though. Would there be some advantage to having a specific RasPi version as opposed to the cross-platform image approach? Wouldn't a "specific" version just lead to potential upgrade lags or even code forks? The problem is that the functionality you seek, while it would be very highly regarded, would basically require/necessitate a Pi-specific version of LB, as all of those features do not exist on other platforms. So if those commands are to be included, writing a universal language becomes impossible. I suppose he could just make those commands into dummy commands that do nothing or give a runtime error on other platforms, but that's still uselessly expanding the scope of LB on other platforms, though it does have the benefit of a unified codebase. You mention it as functionality comparable to STYLEBITS in LB4, which is a Windows-only command out of pure necessity (it's a bridge to give access to a Windows-specific feature), but what you seem to have missed is that LB5 will NOT have STYLEBITS commands, BECAUSE it's Windows only. Instead, my understanding is he intends to expand the commands available to widgets to allow a substitute for most of what we used STYLEBITS for, that will work cross-platform. There's also the problem that LB5 would likely need to depend on a native library like WiringPi in the first place as a backend for those features. I agree. GPIO is a unique feature specific to the RasPi. It doesn't really make sense to include it in the cross-platform code. But it also seems to not make sense to create a specific native version for the RasPi that might find itself lagging in future upgrades. It may be that the best solution is to simply rely on DLLs to manage the heavy lifting. But therein lies the conundrum; LB is decidedly moving toward a cross-platform architecture, but Macs don't use DLLs, yet the extensive commands to use them are included. Macs and Linux don't use Stylebits either, but since that's a function of display and GUI design, it may more easily be replaced. The question becomes, where do you draw the line? We already have to have a decision tree to determine Platform in order to know how to manage files on either unix or windows systems. Regarding the STYLEBITS issue, I fear I must not have made my point clear. I brought it up as an example of a situation where, like the GPIO commands, the STYLEBITS are useful only to one platform and therefore problematic at best. I fully grasp the point that LB5 must approach the functionality of STYLEBITS in a different manner in order to facilitate cross-platform compatibility. As for requiring a native library like WiringPi as a backend, I'm 82% confident that all functions can be managed by simple file management similar to the manner in which you controlled the LED in your demonstration. It's just cumbersome to have to do it that way. And sadly, WiringPi was deprecated by the developer earlier this year. I'm not sure if that's a good thing or not. Is it good enough as it is to function like Latin in a modern English world? Or is it blind like Latin in a world where its vocabulary lacks the ability to describe "ear pods". In the end, sure, if I had my preference, I'd love to see LB 5 embrace the RasPi GPIO and include native commands for all of it's various functions. If I can ignore DLLs while programming for the Mac, the Mac programmers could forgive me for having a few RasPi GPIO commands they have no use for. Certainly, it comes as no surprise that adding multiple platforms to the code base would inevitably demand the code base accommodate the unique proclivities of the platforms. If it's going to be a "jack of all trades", it's going to need the tools to do all of the jobs. It's sure to be a slippery slope. Regardless, as I've said before, I don't envy Carl's challenges with this project. And I fully respect his choices. There are already well over 300 commands in Liberty Basic. The original Dartmouth BASIC had only fifteen!
|
|
|
Post by Carl Gundel on Dec 8, 2019 22:26:41 GMT -5
It won't be possible to make each platform completely portable. I am going to add the ability to call external libraries for example, and doubtless there will be some other things. On the other hand it will be possible to write solid cross platform apps without using any of that stuff.
|
|
|
Post by sarossell on Dec 8, 2019 23:07:03 GMT -5
It won't be possible to make each platform completely portable. I am going to add the ability to call external libraries for example, and doubtless there will be some other things. On the other hand it will be possible to write solid cross platform apps without using any of that stuff. I don't understand what you mean by "portable", but I do like the sound of being able to write cross platform apps.
I'm very curious to see how Mac apps might be deployed; vm calling an .im calling a runtime app calling a tkn calling....whoops, dlls and slls? in an .app package? Dare I ask if there will be a full compiler?
It's always intrigued me as to how LB "compiles" the code when it runs. I just assumed it ran like a TKN as normal, but out of sight, like in a ramdisk or something.
|
|
|
Post by Carl Gundel on Dec 9, 2019 7:41:10 GMT -5
It won't be possible to make each platform completely portable. I am going to add the ability to call external libraries for example, and doubtless there will be some other things. On the other hand it will be possible to write solid cross platform apps without using any of that stuff. I don't understand what you mean by "portable", but I do like the sound of being able to write cross platform apps.
I'm very curious to see how Mac apps might be deployed; vm calling an .im calling a runtime app calling a tkn calling....whoops, dlls and slls? in an .app package? Dare I ask if there will be a full compiler?
It's always intrigued me as to how LB "compiles" the code when it runs. I just assumed it ran like a TKN as normal, but out of sight, like in a ramdisk or something.
Portable means that you write BASIC code which runs on Windows, on the Mac, on Linux etc. If you stay away from OS specific features you have written portable code. Nothing magic there. ;-) A real compiler meaning one that produces native binaries for each platform? No, but I’ve not even hinted at this as a possibility. The BASIC is converted into an object oriented form that is executed by the Smalltalk VM. Think of this as being similar to the way people use the Java VM to run various languages.
|
|
|
Post by sarossell on Dec 9, 2019 9:03:05 GMT -5
I don't understand what you mean by "portable", but I do like the sound of being able to write cross platform apps.
I'm very curious to see how Mac apps might be deployed; vm calling an .im calling a runtime app calling a tkn calling....whoops, dlls and slls? in an .app package? Dare I ask if there will be a full compiler?
It's always intrigued me as to how LB "compiles" the code when it runs. I just assumed it ran like a TKN as normal, but out of sight, like in a ramdisk or something.
Portable means that you write BASIC code which runs on Windows, on the Mac, on Linux etc. If you stay away from OS specific features you have written portable code. Nothing magic there. ;-) A real compiler meaning one that produces native binaries for each platform? No, but I’ve not even hinted at this as a possibility. The BASIC is converted into an object oriented form that is executed by the Smalltalk VM. Think of this as being similar to the way people use the Java VM to run various languages. Ah, very cool. Thanks. It all sounds very exciting!
|
|
|
Post by Rod on Dec 9, 2019 14:42:09 GMT -5
Programming the pins of the Arduino and the PI are a little different but there appears to be big issues for us (Liberty Programmers). Yes the PI is file based but I don't think you are going to get much out of the pins on that basis.
When we played with the Arduino, members contributed a Sketch which bridged the two OSs. Using that bridge we could send messages to command the Arduino to alter the pin status, the PWM of the pin slewing servos or indeed pinging ultrasonic distance measure. In all cases the Arduino managed and paced and timed the writing and reading of the pins, to the microsecond.
So we were sending messages slowly over the serial link that the Arduino Sketch grabbed and actioned instantly.
I think this is the function of the wiringpi.dll. But you can't access it simply over the serial port.
The pin control desired is exacting. For ultrasonic distance measurement it is microsecond accuracy for servo movement it is microsecond 0 - 2000. Indeed a crawler will need six servos timed to perfection, you can only do that autonomously, for audio similary. We cant get to those speeds over a serial link.
So we will need a bridge/host kinda like the Sketch that members built for the Arduino.
The PI is a full blown computer, time sharing processing cycles, so it introduces Windows style variable processing delays.
Its all going to be fun!
|
|