Attached is an updated compiler to fix the C3 and SSF external memory compile issue.
Please copy the xbcom-qt.exe from the .zip to your xBasic IDE\bin directory.
Attached is an updated compiler to fix the C3 and SSF external memory compile issue.
Please copy the xbcom-qt.exe from the .zip to your xBasic IDE\bin directory.
I am still having problems trying to figure out how to use cognew. Whatever I try it keeps popping up errors, like '.. has to be within main code area ...' I am using my interpretation of that error msg, to me that error message makes no sense. I think the error messages still need some work.
I have discovered a very serious limitation with xbasic, as it pertains to the way I want to use xbasic. Since the config file designates what pins will be used for port communications, this basically locks you into one functional serial port. If you decide to use, lets say p0, and p1 for comms I assume the program will still use p31 and p30 as the programming port. So, lets say that you want to use an RS-232 module, BlueTooth module, and possibly p31 an p30 as comm ports, all at the same time, then you are SOL. Of course I am not completely familiar as to how xbasic works, so their may be an explanation for this.
The other curiosity I have is, since xbasic basically uses 'libs' like propeller.bas, and print.bas, do the complete contents of those files become part of the new program, or does the compiler only use that what is being used within your program? I know that now we access to more expanded memory, but still ...
I guess this all leads to the question, will xbasic be an alternate way of programming the Propeller having the same power as Spin? What is the future of xbasic?
I am still having problems trying to figure out how to use cognew. Whatever I try it keeps popping up errors, like '.. has to be within main code area ...' I am using my interpretation of that error msg, to me that error message makes no sense. I think the error messages still need some work.
Your COG image has to be in hub memory. That should be the only requirement. You can ensure this by using an array definition like this:
dim my_cog_code() in "hub" = { ... }
I have discovered a very serious limitation with xbasic, as it pertains to the way I want to use xbasic. Since the config file designates what pins will be used for port communications, this basically locks you into one functional serial port. If you decide to use, lets say p0, and p1 for comms I assume the program will still use p31 and p30 as the programming port. So, lets say that you want to use an RS-232 module, BlueTooth module, and possibly p31 an p30 as comm ports, all at the same time, then you are SOL. Of course I am not completely familiar as to how xbasic works, so their may be an explanation for this.
You can load a copy of the FullDuplexSerial driver into a COG and use that to manage your second serial port. I guess there should be an example showing how to do that.
The other curiosity I have is, since xbasic basically uses 'libs' like propeller.bas, and print.bas, do the complete contents of those files become part of the new program, or does the compiler only use that what is being used within your program? I know that now we access to more expanded memory, but still ...
Only the functions you actually use will be included in the resulting program. This also applies to functions you define yourself in your main program file. If you define a function but never reference it either directly or indirectly from your main code it will not be part of the compiled program.
I guess this all leads to the question, will xbasic be an alternate way of programming the Propeller having the same power as Spin? What is the future of xbasic?
xbasic will always be different from Spin. There is no point in duplicating something that is already available and works well. However, I will continue to improve xbasic as my time permits.
I am still having problems trying to figure out how to use cognew. Whatever I try it keeps popping up errors, like '.. has to be within main code area ...' I am using my interpretation of that error msg, to me that error message makes no sense. I think the error messages still need some work.
I have discovered a very serious limitation with xbasic, as it pertains to the way I want to use xbasic. Since the config file designates what pins will be used for port communications, this basically locks you into one functional serial port. If you decide to use, lets say p0, and p1 for comms I assume the program will still use p31 and p30 as the programming port. ...
Ray, Can you please post an example of what your are trying to do with cognew?
The board type configuration is only designed for the program loader.
Another GUI plug-in concept would be for specifying user device hardware pins.
I want to use some of the def's that are in my tools.bas to start a new cog that turns on/off an LED. I just want to get a feel for what it takes to create a newcog that will run specific commands.
Ray
rem test1.bas
include "propeller.bas"
include "print.bas"
include "tools.bas"
count1=40
cognew(@LED1,@count1)
rem Main
do
print "This is the Main"
waitMS(2000)
loop
rem Start a new cog that just turns on/off an LED
dim LED1() in "hub" = { do high(18) waitMS(500) low(18) waitMS(500) loop }
end
I want to use some of the def's that are in my tools.bas to start a new cog that turns on/off an LED. I just want to get a feel for what it takes to create a newcog that will run specific commands.
Ray
rem test1.bas
include "propeller.bas"
include "print.bas"
include "tools.bas"
count1=40
cognew(@LED1,@count1)
rem Main
do
print "This is the Main"
waitMS(2000)
loop
rem Start a new cog that just turns on/off an LED
dim LED1() in "hub" = { do high(18) waitMS(500) low(18) waitMS(500) loop }
end
I'm afraid that you can only load PASM drivers with coginit. It isn't (at least currently) possible to run xbasic code in another COG.
Funny how I never realized that. The loader always uses P30/31 ?
No, I think the loader will use whatever pins you define in the board configuration. I have never tested anything other than 31/30 and 115200 baud though.
Ray, I guess the xBasic program model should have been described better up front.
The xBasic program model is and likely always will be: "Main thread in xBasic and drivers in PASM."
The advantage is to provide large code and data for programs without hitting the HUB memory limit.
The business side of the program can be very big. The strategy aims for simplicity.
Propeller parallelism is achieved with PASM and is intended to be hidden from the BASIC user. Unfortunately, today the number of available generic PASM drivers is limited. Tools for generating PASM drivers are not integrated in the IDE. There is one argument that says adding all this to the IDE would make things unnecessarily complex. PASM programmers probably have enough software ability to live without an integrated feature. Still, an advanced mode for driver development could and may eventually be defined.
As you've gathered and David has pointed out, xBasic does not allow this feature. The problem with starting multiple xBasic functions from external memory is a performance issue. Propeller is just too small to go beyond the model bounds we have in xBasic today.
Regarding your code ... just for clarification ....
dim LED1() in "hub" = { do high(18) waitMS(500) low(18) waitMS(500) loop }
I'm not sure if this should have compiled in the first place. The right way is in the code block below.
dim LED1() in "hub" = { do high(18) waitMS(500) low(18) waitMS(500) loop }
I'm not sure if this should have compiled in the first place.
You're correct that this code should not compile successfully. The only thing allowed between { and } is integer valued initializers. I think he defined this using dim so he could pass it to the coginit function thinking it would run that code in a separate COG. That is a perfectly reasonable thing to want to do but it is unfortunately not supported by xbasic.
The example that I provided did not compile, I just wanted to illustrate what I was trying to do. So, now I do not know where I am at with xbasic, do I like it or do I hate it.
Hopefully we all found some of the more obvious bugs for you, and I guess it is time to see where xbasic goes from here, in terms of drivers and other working programs. I will probably give xbasic a shot with my C3 board, but I do not see how xbasic would help me out with the mini project that I am working on.
Hopefully we all found some of the more obvious bugs for you, and I guess it is time to see where xbasic goes from here, in terms of drivers and other working programs. I will probably give xbasic a shot with my C3 board, but I do not see how xbasic would help me out with the mini project that I am working on.
xbasic was never meant to replace Spin. It was supposed to be an easy-to-use language for people familiar with Basic. While it could be extended to do all of the things you've mentioned, it's not clear that would make much sense. If you need that level of complexity, why not just use Spin or even one of the available C compilers?
Anyway, thanks for your help in tracking down bugs!
Ray, I'm thinking of how to start SPIN code in a COG by using your dim ... in "hub" idea.
Changes to the xBasic compiler would not be necessary, but a converter tool will be required.
I'll have to write a program to create an xBasic array that contains Spin code.
I can't guarantee anything, but it at least deserves some attention.
Interesting discussions! I didn't realize it was single cog use either. However it fun to play with esp for the C3. Looking forward to see where this goes. I think this has potential!
Interesting discussions! I didn't realize it was single cog use either. However it fun to play with esp for the C3. Looking forward to see where this goes. I think this has potential!
It's not exactly single COG use. You can load PASM drivers into other COGs and talk to them through mailboxes. The problem is running xbasic code in other COGs. That would be possible as long as the code is in hub memory but sharing the external memory between COGs would be very inefficient.
It's not exactly single COG use. You can load PASM drivers into other COGs and talk to them through mailboxes. The problem is running xbasic code in other COGs. That would be possible as long as the code is in hub memory but sharing the external memory between COGs would be very inefficient.
Can't it not be possible to provide one process from HUB and other from External MEM --> that can give 2 usable Processes at last.
Actually, xbasic *could* allow up to seven COGs running code from the hub and one from external memory. Do you think that would make it significantly more useful? What other features are missing that would make xbasic a useful Propeller language?
For my mini project I am using Spin, but I have a great fear that either I will run out of cog memory or hub memory or both. My mini could grow to a maxi project, but I think I would be limited as to what I can really do with it because of the memory limitations of Spin. As for the other languages that were mentioned, I will not use a command line program, to bad ICC never got the support it deserved.
I will still keep looking into xbasic, but not from a perspective that I will be using it for my mini project. Once you get some more drivers in the works, I will make some time to test them. Maybe xbasic will grow into a beast, before anybody has a chance to figure out what is going on.
As for the other languages that were mentioned, I will not use a command line program, to bad ICC never got the support it deserved.
Why is that? It seems to me that programming is all about learning new things. Why not try learning how to use command line tools? You can still use a GUI editor. The requirement that every new tool have an IDE makes it much harder to build tools and probably means less get built. It also means that the world is flooded with not-very-good IDEs because people refuse to use the command line. Give it a try!
Actually, xbasic *could* allow up to seven COGs running code from the hub and one from external memory. Do you think that would make it significantly more useful? What other features are missing that would make xbasic a useful Propeller language?
@David Betz, yes, back in the day, I remember when I had my PC running UNIX ver V, and creating new commands by using a script file, or basically using a script file to do whatever. Those were some exciting times, but that was then, and today I do not feel that I need to relive those days, give me the easy route, I have been there and done that. I want the easy button, I deserve it. Now back to our regular program ...
That 7 COG runing programs ---> Talk we Basic code else PASM code?
We can run xBasic COG (HUB or External) + 7 COGs of PASM now.
The questions are:
Will having 1 COG xBasic (HUB or External) + 7 COGs of xBasic (HUB) be worth the extra effort?
Will many more users adopt xBasic because of that feature or does it not matter?
I guess in many ways Spin sets the "bar" for a Propeller language so that's why it might be expected.
In my opinion it is NOT only SPIN that set that "bar" -- It is nature of Propellers design with 8 COG's (Cores).
I will NOT hijack Yours Thread so maybe we can open another thread that we can discussion usable PROGRAMING's MODELS both for xBasic and "C" that can/are usable on Propeller.
As I see it "Beginners" maybe can accept "Single core" solution with 7 others COG's as Drivers ---> BUT I'm are sure that more advanced ones Wait much more from Propeller.
We can run xBasic COG (HUB or External) + 7 COGs of PASM now.
The questions are:
Will having 1 COG xBasic (HUB or External) + 7 COGs of xBasic (HUB) be worth the extra effort?
Will many more users adopt xBasic because of that feature or does it not matter?
I guess in many ways Spin sets the "bar" for a Propeller language so that's why it might be expected.
Comments
Great. Thanks!
We've found an issue, but don't know what to make of it yet.
It seems to only come up with external memory modes.
Will have more info later.
Thanks a ton for your help!
In console mode
It doesnt know C3 ?
see you soon
xbcom-qt -b hub -p com4 -I "C:\xBasic IDE\include" -I "C:\xBasic IDE\samples\TvDemo" "C:\xBasic IDE\samples\TvDemo\tvdemo.bas"
Replace hub with C3 and it fails. Chasing a read problem now.
Please copy the xbcom-qt.exe from the .zip to your xBasic IDE\bin directory.
--Steve
Works !
I tested on my TV PAL ":)
good !
I have discovered a very serious limitation with xbasic, as it pertains to the way I want to use xbasic. Since the config file designates what pins will be used for port communications, this basically locks you into one functional serial port. If you decide to use, lets say p0, and p1 for comms I assume the program will still use p31 and p30 as the programming port. So, lets say that you want to use an RS-232 module, BlueTooth module, and possibly p31 an p30 as comm ports, all at the same time, then you are SOL. Of course I am not completely familiar as to how xbasic works, so their may be an explanation for this.
The other curiosity I have is, since xbasic basically uses 'libs' like propeller.bas, and print.bas, do the complete contents of those files become part of the new program, or does the compiler only use that what is being used within your program? I know that now we access to more expanded memory, but still ...
I guess this all leads to the question, will xbasic be an alternate way of programming the Propeller having the same power as Spin? What is the future of xbasic?
Ray
Your COG image has to be in hub memory. That should be the only requirement. You can ensure this by using an array definition like this:
dim my_cog_code() in "hub" = { ... }You can load a copy of the FullDuplexSerial driver into a COG and use that to manage your second serial port. I guess there should be an example showing how to do that.
Only the functions you actually use will be included in the resulting program. This also applies to functions you define yourself in your main program file. If you define a function but never reference it either directly or indirectly from your main code it will not be part of the compiled program.
xbasic will always be different from Spin. There is no point in duplicating something that is already available and works well. However, I will continue to improve xbasic as my time permits.
Ray, Can you please post an example of what your are trying to do with cognew?
The board type configuration is only designed for the program loader.
Another GUI plug-in concept would be for specifying user device hardware pins.
Well, that's not entirely true. The tx/rx pin settings are also used for the serial debug link used by PRINT and INPUT after the program has started.
Ray
rem test1.bas include "propeller.bas" include "print.bas" include "tools.bas" count1=40 cognew(@LED1,@count1) rem Main do print "This is the Main" waitMS(2000) loop rem Start a new cog that just turns on/off an LED dim LED1() in "hub" = { do high(18) waitMS(500) low(18) waitMS(500) loop } endI'm afraid that you can only load PASM drivers with coginit. It isn't (at least currently) possible to run xbasic code in another COG.
No, I think the loader will use whatever pins you define in the board configuration. I have never tested anything other than 31/30 and 115200 baud though.
The xBasic program model is and likely always will be: "Main thread in xBasic and drivers in PASM."
The advantage is to provide large code and data for programs without hitting the HUB memory limit.
The business side of the program can be very big. The strategy aims for simplicity.
Propeller parallelism is achieved with PASM and is intended to be hidden from the BASIC user. Unfortunately, today the number of available generic PASM drivers is limited. Tools for generating PASM drivers are not integrated in the IDE. There is one argument that says adding all this to the IDE would make things unnecessarily complex. PASM programmers probably have enough software ability to live without an integrated feature. Still, an advanced mode for driver development could and may eventually be defined.
As you've gathered and David has pointed out, xBasic does not allow this feature. The problem with starting multiple xBasic functions from external memory is a performance issue. Propeller is just too small to go beyond the model bounds we have in xBasic today.
Regarding your code ... just for clarification ....
dim LED1() in "hub" = { do high(18) waitMS(500) low(18) waitMS(500) loop }I'm not sure if this should have compiled in the first place. The right way is in the code block below.The keyword "dim" is used to declare variables.
The keyword "def" is used to define functions and constants .
def LED1 do high(18) waitMS(500) low(18) waitMS(500) loop end defYou're correct that this code should not compile successfully. The only thing allowed between { and } is integer valued initializers. I think he defined this using dim so he could pass it to the coginit function thinking it would run that code in a separate COG. That is a perfectly reasonable thing to want to do but it is unfortunately not supported by xbasic.
Hopefully we all found some of the more obvious bugs for you, and I guess it is time to see where xbasic goes from here, in terms of drivers and other working programs. I will probably give xbasic a shot with my C3 board, but I do not see how xbasic would help me out with the mini project that I am working on.
Ray
xbasic was never meant to replace Spin. It was supposed to be an easy-to-use language for people familiar with Basic. While it could be extended to do all of the things you've mentioned, it's not clear that would make much sense. If you need that level of complexity, why not just use Spin or even one of the available C compilers?
Anyway, thanks for your help in tracking down bugs!
Changes to the xBasic compiler would not be necessary, but a converter tool will be required.
I'll have to write a program to create an xBasic array that contains Spin code.
I can't guarantee anything, but it at least deserves some attention.
It's not exactly single COG use. You can load PASM drivers into other COGs and talk to them through mailboxes. The problem is running xbasic code in other COGs. That would be possible as long as the code is in hub memory but sharing the external memory between COGs would be very inefficient.
Can't it not be possible to provide one process from HUB and other from External MEM --> that can give 2 usable Processes at last.
Actually, xbasic *could* allow up to seven COGs running code from the hub and one from external memory. Do you think that would make it significantly more useful? What other features are missing that would make xbasic a useful Propeller language?
Thanks,
David
I will still keep looking into xbasic, but not from a perspective that I will be using it for my mini project. Once you get some more drivers in the works, I will make some time to test them. Maybe xbasic will grow into a beast, before anybody has a chance to figure out what is going on.
Ray
Why is that? It seems to me that programming is all about learning new things. Why not try learning how to use command line tools? You can still use a GUI editor. The requirement that every new tool have an IDE makes it much harder to build tools and probably means less get built. It also means that the world is flooded with not-very-good IDEs because people refuse to use the command line. Give it a try!
That 7 COG runing programs ---> Talk we Basic code else PASM code?
Got it is there some examples of using mailbox some place?
Ray
We can run xBasic COG (HUB or External) + 7 COGs of PASM now.
The questions are:
Will having 1 COG xBasic (HUB or External) + 7 COGs of xBasic (HUB) be worth the extra effort?
Will many more users adopt xBasic because of that feature or does it not matter?
I guess in many ways Spin sets the "bar" for a Propeller language so that's why it might be expected.
In my opinion it is NOT only SPIN that set that "bar" -- It is nature of Propellers design with 8 COG's (Cores).
I will NOT hijack Yours Thread so maybe we can open another thread that we can discussion usable PROGRAMING's MODELS both for xBasic and "C" that can/are usable on Propeller.
As I see it "Beginners" maybe can accept "Single core" solution with 7 others COG's as Drivers ---> BUT I'm are sure that more advanced ones Wait much more from Propeller.