I don't mind adding IDE features, but I'm waiting for more xbasic users to show up before doing that.
Yes, I understand. I get the feeling like I am the only one driving this thread, so this thread just might go under just like it did before. So far I have noticed that the IDE works well enough to get some things accomplished, so I will try too think of some more examples I can put together. That way it gives me a chance to get a better exposure as to what can be done with xbasic. For quick and dirty this is a very good tool, but how would it work out for some serious stuff?
Yes, I understand. I get the feeling like I am the only one driving this thread, so this thread just might go under just like it did before. So far I have noticed that the IDE works well enough to get some things accomplished, so I will try too think of some more examples I can put together. That way it gives me a chance to get a better exposure as to what can be done with xbasic. For quick and dirty this is a very good tool, but how would it work out for some serious stuff?
. Since then I've become somewhat disillusioned with Basic and Forth since...
I think we have it there. If the creator of the language has moved on you are on your own. Unless you want to support the tool yourself or can grow a community around it.
It's a replay of MS BASIC for the Altair. I bet Bill Gate never actually used that for anything.
David, I'm not bashing on xBasic. As you have effectively said programming languages are more than just an implementation, there has to be some standard behind it that people can work to.
I too hope that Spin does not become fractured. It really could do with a formal specification.
Heater.
Yes, I saw that comment, I am not sure what to make of it at this time. I do realize that jazzed has already tried to make a go of xbasic, but it did not go. Like I said in my OP, I thought I would give it another chance, but I do not have the talent to push it any further.
Thinking about this further I am wondering how well SimpleIDE and PropGCC are really doing? Just like with xbasic, there is a big concern for drivers for all the modules that are available. I know that spin2cpp was developed to help with that, but how well is the use of spin2cpp really doing. And thinking about Spin being fractured, what the heck is going to happen when the new Spin2 comes out?
In the beginning we had Spin, and there were complaints about not having C. The logic was once C is available then the users will show up. Then OBEX was added, yes, then the users will show up. It seems like were always looking for users too show up, or at least participate in the threads too give some indication that there still is an interest. I better stop now before I get myself in to trouble.
I better stop now before I get myself in to trouble.
No, no, you raise some good points.
SimpleIDE and propgcc are doing just fine as far as I can tell. We are not talking about a one man language design/implementation here. C and GCC have standards and decades of momentum behind them.
I will be hard and say that Spin is a dead end. Don't get me wrong I think the Propeller and Spin are brilliant. But have no expectation that Spin is moving out of the Propeller world. Especially as it stands there is no formal Spin language specification and PASM is part of Spin and PASM is very Prop specific.
With the P2 Spin becomes less relevant as the P2 will be a good C/C++ engine.
I think we have it there. If the creator of the language has moved on you are on your own. Unless you want to support the tool yourself or can grow a community around it.
I never said that I wouldn't support xbasic. I just said that I'm frustrated that the name "Basic" seems to mean nothing. Anyone can call anything "Basic". I mostly moved on because the only person who was using xbasic stopped using it. In fact, I've just created another version of basic called ebasic that runs directly on the Propeller and uses a variant of the xbasic PASM VM so it runs a lot faster than interpreted Basics on the Propeller. I don't know if anyone will want to use that either but I have enjoyed writing it.
Heater.
Yes, I saw that comment, I am not sure what to make of it at this time. I do realize that jazzed has already tried to make a go of xbasic, but it did not go.
I'm not sure it's correct to say "it did not go". I think it's more that Parallax got Steve involved with SimpleIDE and he no longer had time to do the xbasic IDE. The code is all checked into Google Code so anyone could help improve it if they are interested.
HALT: STACK 00007BD8, STACK_TOP 00007FD8
PC OP FP SP TOS SP[0] SP[1] SP[2] SP[3]
00000069 00 00007FD8 00007FD8 00000000 00007FD8 00007FD8 00000000 00000069
I just checked in a change to xbasic to get rid of the "HALT" error after normal termination of a program. I'm not sure how Steve did the release that included the xbasic IDE so I haven't updated that. Maybe he will offer to help. :-)
Would a solution in the style of dr acula's cojects work here?
Many key objects are top notch pasm with a little bit of spin glue. Being able to adapt existing objects would help a lot.
some of them could also form a library. And a "coprocessor style" object could be atapted to anything...
About ebasic:
I like the idea of an interactive tool running on the prop. I think big part of Forth's interest is related to that. As far as I know memory requirements of ebasic are quite huge at the moment?
I already expressed the opinion that such a configuration with a wireless connection would offer a nice solution also for students with tablet.
I usually silently follow this kind of discussions because I'm sure my post would only add noise and distraction in very interesting discussion.
It looks sometimes an "I'm here" helps... so here I am.
Massimo
Would a solution in the style of dr acula's cojects work here?
Many key objects are top notch pasm with a little bit of spin glue. Being able to adapt existing objects would help a lot.
some of them could also form a library. And a "coprocessor style" object could be atapted to anything...
About ebasic:
I like the idea of an interactive tool running on the prop. I think big part of Forth's interest is related to that. As far as I know memory requirements of ebasic are quite huge at the moment?
I already expressed the opinion that such a configuration with a wireless connection would offer a nice solution also for students with tablet.
I usually silently follow this kind of discussions because I'm sure my post would only add noise and distraction in very interesting discussion.
It looks sometimes an "I'm here" helps... so here I am.
Massimo
ebasic3 (the one with the PASM VM) can run from hub memory compiled by PropGCC in CMM mode. However, this is by leaving out the SD filesystem support. To use that you'll need an external SPI flash chip or something like that. However, the Spinneret 2.0 will have a SPI flash chip so it should be a good platform for ebasic3. The C3 would also work well as would OBC's new Propeller Mini Computer as I understand it. He says it will support a SPI flash chip but I don't know any other details about it. A QuickStart could also be used with David Carrier's Propeller Memory Card although that also requires a Human Interface Board as it can not plug directly into the QuickStart. Rayman's RamPage2 should also work. But, if you just want to type programs and run them and don't care about saving them to an SD card, any Propeller board will work.
Thinking further about xbasic, a new user might be thinking, I have an Activity Board, so how can I use xbasic with the stuff that is available on the board? Servos, in order to use those I need a driver plus a COG, if I am going to use it with a bot. The SD card, how do you get a driver working for that. The XBee, that might be an easier one since there are some uart things available... etc. This sounds like Spin at the very beginning, drivers and who is going to make them. Now maybe a short cut would be, to have something like a spin2xbasic, but the resulting code might be very cumbersome to work with, if the COGs can only use arrays.
I remember a similar situation with PropBASIC, the question came up, what about the drivers, and the answer was, hopefully the community of users will provide that. I think shortly after that post PropBASIC took a dive and hasn't been seen since. I guess the thing to think about is, how would this driver issue be resolved for xbasic, a reliance on one person to create all of it? I still do not think that there is a good understanding as to what is really involved in the process of making drivers for xbasic and how they are to be used. I guess, something to think about, but who has the answers?
Thinking further about xbasic, a new user might be thinking, I have an Activity Board, so how can I use xbasic with the stuff that is available on the board? Servos, in order to use those I need a driver plus a COG, if I am going to use it with a bot. The SD card, how do you get a driver working for that. The XBee, that might be an easier one since there are some uart things available... etc. This sounds like Spin at the very beginning, drivers and who is going to make them. Now maybe a short cut would be, to have something like a spin2xbasic, but the resulting code might be very cumbersome to work with, if the COGs can only use arrays.
I remember a similar situation with PropBASIC, the question came up, what about the drivers, and the answer was, hopefully the community of users will provide that. I think shortly after that post PropBASIC took a dive and hasn't been seen since. I guess the thing to think about is, how would this driver issue be resolved for xbasic, a reliance on one person to create all of it? I still do not think that there is a good understanding as to what is really involved in the process of making drivers for xbasic and how they are to be used. I guess, something to think about, but who has the answers?
Ray
As Steve pointed out, there are some example xbasic drivers in the "samples" directory. Those could be used to understand how drivers are put together. However, as I mentioned earlier, you'll need spin2cpp or OpenSpin to assemble the PASM part of the driver into a blob that xbasic can use. xbasic comes with a bin2xbasic command line tool that will take a binary file and produce an initialized byte array that can be included in an xbasic program. I guess all of this would have to be knit together by the xbasic IDE before it would get used. Not many people here are willing to use command line tools.
Which brings us to a much discussed issue about reusable PASM code. Reusable across different high level languages that is. Well, it was much discussed a year or so ago,
You see, we have COGs. And we can starts COGs running blobs of PASM code. In principle any high level language should not need to know or care what is in those binary blobs. It only has to get them into memory somehow and point a COG at it. Rather like Windows or Linux loading firmware into your WIFI dongle or graphics card.
That "firmware" view of COG code would of course require some standardized an documented way for high level languages to interact with the blob when it is running in a COG.
RossH and others tried to initiate the adoption of some such standardization for blob loading and interaction. The "community" did not pick up in the idea.
Without such a standard we are doomed to requiring each language to implement all the usual objects in it's own way. That makes adoption much harder.
@Heater -- I remember that thread (though I can't find it now) -- at the risk of invoking the repost-gods, here is a document that was attached to it at some point.
@Heater -- I remember that thread (though I can't find it now) -- at the risk of invoking the repost-gods, here is a document that was attached to it at some point.
Has anyone ever written any drivers based on that specification?
If you want PASM drivers for xbasic, they need to only follow a simple set of rules. If you want library drivers for xbasic, written in xbasic, then that is very easy.
As for the rest: If it ain't simple, it will never fly.
If you want library drivers for xbasic, written in xbasic, then that is very easy.
OK, lets say I have a Sensirion sht11 module and I need to be able too use it with xbasic, so how easy would that be? Of course the best use of the sht11 would be if it ran in its own COG, and you could grab the latest temperature and humidity values from the running COG. I guess that would be a good exercise for testing the simplicity of creating a driver in xbasic.
Maybe using the COG would be a little harder to accomplish, so how about a Full Duplex Serial module that would be used to access the XBee or another Propeller chip. Of course you would want to use the standard (31,30,0,115200) approach.
What I am thinking at this point is to have some ready too access commands like high,low,wait, and things along those lines. Now lets say some new person buys a QuickStart board and he basically knows nothing about the Propeller, but he may have had some programming experience, like PBASIC, and in the command lineup there was also a 'button()' command, he could probably get something going in no time, that would be turning on an LED and other variations. And if the program development was maybe a half an hour or less, that would be a plus plus situation I think.
Doing some tests, the program below does not run, but I am not getting any errors when I compile. Not sure why this is not working, I used similar code that is in the documentation. I had the same problem when I was testing the IF THEN thing. A plain do loop works but when you add the until it does not run.
Ray
REM ==========
REM test3.bas
REM ==========
include "propeller.bas"
include "extra.bas"
LET x = 1
do
x=x+1
high(26)
waitMS(500)
low(26)
waitMS(500)
loop until x = 10
OK, lets say I have a Sensirion sht11 module and I need to be able too use it with xbasic, so how easy would that be? Of course the best use of the sht11 would be if it ran in its own COG, and you could grab the latest temperature and humidity values from the running COG. I guess that would be a good exercise for testing the simplicity of creating a driver in xbasic.
Maybe using the COG would be a little harder to accomplish, so how about a Full Duplex Serial module that would be used to access the XBee or another Propeller chip. Of course you would want to use the standard (31,30,0,115200) approach.
What I am thinking at this point is to have some ready too access commands like high,low,wait, and things along those lines. Now lets say some new person buys a QuickStart board and he basically knows nothing about the Propeller, but he may have had some programming experience, like PBASIC, and in the command lineup there was also a 'button()' command, he could probably get something going in no time, that would be turning on an LED and other variations. And if the program development was maybe a half an hour or less, that would be a plus plus situation I think.
Ray
The pin functions woudl be quite easy to add. They could either be done in Basic or using ASM and NATIVE. In fact, I started adding a bunch of the pbasic functions like pulsein and pulseout to ebasic a while back. More could certainly be added. If you make a list of the functions you'd like to see I'll look into adding them.
Doing some tests, the program below does not run, but I am not getting any errors when I compile. Not sure why this is not working, I used similar code that is in the documentation. I had the same problem when I was testing the IF THEN thing. A plain do loop works but when you add the until it does not run.
Ray
REM ==========
REM test3.bas
REM ==========
include "propeller.bas"
include "extra.bas"
LET x = 1
do
x=x+1
high(26)
waitMS(500)
low(26)
waitMS(500)
loop until x = 10
This looks okay. I'll try it later and let you know what is going wrong. Do you have an LED on pin 26?
Yes, I have an LED on pin 26. I also moved the high(),low(), and waitMS() into the extra.bas which is located in the include folder. When I remove the 'until x = 10' portion then the LED blinks as expected.
Since there is no 'break' command I was trying to implement the 'GOTO' to break out of the loop, I tried different things including using an 'if then' situation when I noticed nothing was working, but no errors were popping up.
Yes, I have an LED on pin 26. I also moved the high(),low(), and waitMS() into the extra.bas which is located in the include folder. When I remove the 'until x = 10' portion then the LED blinks as expected.
Since there is no 'break' command I was trying to implement the 'GOTO' to break out of the loop, I tried different things including using an 'if then' situation when I noticed nothing was working, but no errors were popping up.
Ray
You should be able to GOTO a label that is outside of the loop. If you post the code you were having trouble with I'll try that as well as your WHILE loop. Can you also post your "extra.bas" code?
I tried your WHILE loop and it worked as long as I made the change to your LOW function that we discussed earlier. Here is my code. I also broke out the pin number for the LED so it would be easier to change. I'm running this test on a C3 board.
test3.bas:
REM ==========
REM test3.bas
REM ==========
include "propeller.bas"
include "extra.bas"
DEF led = 15
LET x = 1
do
x=x+1
high(led)
waitMS(500)
low(led)
waitMS(500)
loop until x = 10
extra.bas:
REM high
def high(pin)
dira = dira | (1 << pin) // Set up direction
outa = outa | (1 << pin) // Set up condition
end def
REM low
def low(pin)
dira = dira | (1 << pin) // Set up direction
outa = outa & ~(1 << pin) // Set up direction
end def
REM waitMS
def waitMS(time)
waitcnt(((80000000 / 1000) * time) + cnt)
end def
I am running the latest xbasicIDE and not the command line version. There are more problems.
when I have:
DEF x = 1
print x
I get a 1 on the screen. When I change it to:
DEF x=1
x=x+1
print x
I get an lvalue error.
When I have:
LET x=1
print x
Nothing shows on the screen.
LET x=1
x=x+1
print x
lvalue error.
I tried a straight forward:
LET x=1
do
x=x+1
IF x = 10 THEN
GOTO gbye
END IF
loop
gbye:
print "GoodBye"
With that code I just get a blank screen, not sure if I even got an lvalue error.
It seems like some critical items are not working correctly. I will try the 'FOR' loop but I think you have to set it up using a 'LET', which will probably fail, or something like 'for LET x=1' which also might fail.
Ray
Below is my extra.bas
REM =========
REM extra.bas
REM =========
REM wait()
/* Wait, time in seconds. */
def wait(time)
waitcnt((80000000 * time) + cnt)
end def
REM waitMS()
/* Wait, time in miliseconds. */
def waitMS(time)
waitcnt(((80000000 / 1000) * time) + cnt)
end def
REM high()
/* Make pin high. */
def high(pin)
dira = dira | (1 << pin) // Set up direction
outa = outa | (1 << pin) // Set up value
end def
REM low()
/* Make pin low. */
def low(pin)
dira = dira | (1 << pin) // Set up direction
outa = outa & ~(1 << pin) // Set up value
end def
Comments
Yes. There should be an example in "samples\TvDemo"
I don't mind adding IDE features, but I'm waiting for more xbasic users to show up before doing that.
And for my next example...
Ray
Tallyho!
As David said: I think we have it there. If the creator of the language has moved on you are on your own. Unless you want to support the tool yourself or can grow a community around it.
It's a replay of MS BASIC for the Altair. I bet Bill Gate never actually used that for anything.
David, I'm not bashing on xBasic. As you have effectively said programming languages are more than just an implementation, there has to be some standard behind it that people can work to.
I too hope that Spin does not become fractured. It really could do with a formal specification.
Yes, I saw that comment, I am not sure what to make of it at this time. I do realize that jazzed has already tried to make a go of xbasic, but it did not go. Like I said in my OP, I thought I would give it another chance, but I do not have the talent to push it any further.
Thinking about this further I am wondering how well SimpleIDE and PropGCC are really doing? Just like with xbasic, there is a big concern for drivers for all the modules that are available. I know that spin2cpp was developed to help with that, but how well is the use of spin2cpp really doing. And thinking about Spin being fractured, what the heck is going to happen when the new Spin2 comes out?
In the beginning we had Spin, and there were complaints about not having C. The logic was once C is available then the users will show up. Then OBEX was added, yes, then the users will show up. It seems like were always looking for users too show up, or at least participate in the threads too give some indication that there still is an interest. I better stop now before I get myself in to trouble.
Ray
SimpleIDE and propgcc are doing just fine as far as I can tell. We are not talking about a one man language design/implementation here. C and GCC have standards and decades of momentum behind them.
I will be hard and say that Spin is a dead end. Don't get me wrong I think the Propeller and Spin are brilliant. But have no expectation that Spin is moving out of the Propeller world. Especially as it stands there is no formal Spin language specification and PASM is part of Spin and PASM is very Prop specific.
With the P2 Spin becomes less relevant as the P2 will be a good C/C++ engine.
This thread is about xbasic.
I'll get my coat.
Many key objects are top notch pasm with a little bit of spin glue. Being able to adapt existing objects would help a lot.
some of them could also form a library. And a "coprocessor style" object could be atapted to anything...
About ebasic:
I like the idea of an interactive tool running on the prop. I think big part of Forth's interest is related to that. As far as I know memory requirements of ebasic are quite huge at the moment?
I already expressed the opinion that such a configuration with a wireless connection would offer a nice solution also for students with tablet.
I usually silently follow this kind of discussions because I'm sure my post would only add noise and distraction in very interesting discussion.
It looks sometimes an "I'm here" helps... so here I am.
Massimo
I remember a similar situation with PropBASIC, the question came up, what about the drivers, and the answer was, hopefully the community of users will provide that. I think shortly after that post PropBASIC took a dive and hasn't been seen since. I guess the thing to think about is, how would this driver issue be resolved for xbasic, a reliance on one person to create all of it? I still do not think that there is a good understanding as to what is really involved in the process of making drivers for xbasic and how they are to be used. I guess, something to think about, but who has the answers?
Ray
Which brings us to a much discussed issue about reusable PASM code. Reusable across different high level languages that is. Well, it was much discussed a year or so ago,
You see, we have COGs. And we can starts COGs running blobs of PASM code. In principle any high level language should not need to know or care what is in those binary blobs. It only has to get them into memory somehow and point a COG at it. Rather like Windows or Linux loading firmware into your WIFI dongle or graphics card.
That "firmware" view of COG code would of course require some standardized an documented way for high level languages to interact with the blob when it is running in a COG.
RossH and others tried to initiate the adoption of some such standardization for blob loading and interaction. The "community" did not pick up in the idea.
Without such a standard we are doomed to requiring each language to implement all the usual objects in it's own way. That makes adoption much harder.
If you want PASM drivers for xbasic, they need to only follow a simple set of rules. If you want library drivers for xbasic, written in xbasic, then that is very easy.
As for the rest: If it ain't simple, it will never fly.
Maybe using the COG would be a little harder to accomplish, so how about a Full Duplex Serial module that would be used to access the XBee or another Propeller chip. Of course you would want to use the standard (31,30,0,115200) approach.
What I am thinking at this point is to have some ready too access commands like high,low,wait, and things along those lines. Now lets say some new person buys a QuickStart board and he basically knows nothing about the Propeller, but he may have had some programming experience, like PBASIC, and in the command lineup there was also a 'button()' command, he could probably get something going in no time, that would be turning on an LED and other variations. And if the program development was maybe a half an hour or less, that would be a plus plus situation I think.
Ray
Ray
REM ========== REM test3.bas REM ========== include "propeller.bas" include "extra.bas" LET x = 1 do x=x+1 high(26) waitMS(500) low(26) waitMS(500) loop until x = 10This looks okay. I'll try it later and let you know what is going wrong. Do you have an LED on pin 26?
Since there is no 'break' command I was trying to implement the 'GOTO' to break out of the loop, I tried different things including using an 'if then' situation when I noticed nothing was working, but no errors were popping up.
Ray
I tried your WHILE loop and it worked as long as I made the change to your LOW function that we discussed earlier. Here is my code. I also broke out the pin number for the LED so it would be easier to change. I'm running this test on a C3 board.
test3.bas:
REM ========== REM test3.bas REM ========== include "propeller.bas" include "extra.bas" DEF led = 15 LET x = 1 do x=x+1 high(led) waitMS(500) low(led) waitMS(500) loop until x = 10extra.bas:
when I have: I get a 1 on the screen. When I change it to: I get an lvalue error.
When I have: Nothing shows on the screen. lvalue error.
I tried a straight forward:
LET x=1 do x=x+1 IF x = 10 THEN GOTO gbye END IF loop gbye: print "GoodBye"With that code I just get a blank screen, not sure if I even got an lvalue error.It seems like some critical items are not working correctly. I will try the 'FOR' loop but I think you have to set it up using a 'LET', which will probably fail, or something like 'for LET x=1' which also might fail.
Ray
Below is my extra.bas