Ray, you must put a 1 second delay at the beginning of your program otherwise the output will be missed. I'm sorry that is not built-in to the interpreter.
DEF makes constants. You can't change constants in your program.
Ray, you must put a 1 second delay at the beginning of your program otherwise the output will be missed. I'm sorry that is not built-in to the interpreter.
DEF makes constants. You can't change constants in your program.
I don't think that the delay should be in the interpreter since it isn't necessary for a program written to flash or a program run directly with xbcom or xbload. It is only an artifact of the IDE.
Steve: How do I build a "release" of xbasic including the IDE? It seems like the version that is in the current xbasic IDE release must be older than what is in Google Code. I know at least that the elimination of the Halt message that I mentioned earlier is not included. How do I do a full release so Ray can be using the same code I'm using since example works fine for me and apparently not for him.
I don't think that the delay should be in the interpreter since it isn't necessary for a program written to flash or a program run directly with xbcom or xbload. It is only an artifact of the IDE.
Just how many people besides you will use the command line?
You can post a new compiler here, and it can be replaced in the user's program files area.
I found the problem, it is with my Data Memory setting. I am using the DNA-RTC board and my configuration was set to:
Code Memory HUB
Data Memory RAM
External Flash Size 1M
External RAM Size 1M
For a simple do loop it was working fine, when I started to use the 'until' part, it was running into problems. Once I set the configuration to:
Code Memory HUB
Data Memory HUB
External Flash Size
External RAM Size
Then the 'until' started to work. So, the question is, why doesn't the 'do loop' with an 'until' not work in Data Memory RAM? So, even in xbasic we have some restrictions as to what runs in Data Memory HUB, and what runs in Data Memory RAM.
I found the problem, it is with my Data Memory setting. I am using the DNA-RTC board and my configuration was set to:
Code Memory HUB
Data Memory RAM
External Flash Size 1M
External RAM Size 1M
For a simple do loop it was working fine, when I started to use the 'until' part, it was running into problems. Once I set the configuration to:
Code Memory HUB
Data Memory HUB
External Flash Size
External RAM Size
Then the 'until' started to work. So, the question is, why doesn't the 'do loop' with an 'until' not work in Data Memory RAM? So, even in xbasic we have some restrictions as to what runs in Data Memory HUB, and what runs in Data Memory RAM.
Ray
Is there a way to set the board type? The xbasic loader would have to know to load the DNA cache driver in order to make use of any SPI SRAM that might be on the DNA board. Also, I'm not sure the DNA board even existed when xbasic was originally written so it may not have been tested on that board.
I found the problem, it is with my Data Memory setting. I am using the DNA-RTC board and my configuration was set to:
Code Memory HUB
Data Memory RAM
External Flash Size 1M
External RAM Size 1M
For a simple do loop it was working fine, when I started to use the 'until' part, it was running into problems. Once I set the configuration to:
Code Memory HUB
Data Memory HUB
External Flash Size
External RAM Size
Then the 'until' started to work. So, the question is, why doesn't the 'do loop' with an 'until' not work in Data Memory RAM? So, even in xbasic we have some restrictions as to what runs in Data Memory HUB, and what runs in Data Memory RAM.
Just how many people besides you will use the command line?
What about booting from EEPROM? Will you want the delay there? Maybe I need to add an ifdef feature so you can add a delay at the beginning of your main program that gets removed when not built in debug mode.
Edit: Thinking more, I guess the xbasic compiler could automatically add a delay at the start of the main function if a DEBUG flag was set. Then the xbasic IDE could always set that flag and the user wouldn't have to insert the delay manually.
Below is a little more elaborate program, by my standards. Now that I have switched to HUB - HUB, on the DNA-RTC board, this seems to run without any problems. I guess now I will have to switch over to my C3 board and see how these programs run in HUB - RAM setup.
Ray
REM ==========
REM hello2.bas
REM ==========
/* Include items */
include "print.bas"
include "propeller.bas"
include "extra.bas"
/* Assignments */
DEF Rled = 27 // Assign pin
DEF Gled = 26 // Assign pin
/* Start */
waitMS(300) // Wait for debug screen
print "Hello2, World!"
print "Turn on red LED"
high(Rled)
waitMS(500)
print "Turn on green LED"
high(Gled)
print "Resting... "
wait(5) // Wait 5 seconds
print "Turn off green LED"
low(Gled)
waitMS(500)
print "Turn off red LED"
low(Rled)
print "Ending program, GoodBye"
LET x = 1
DO
x=x+1
waitMS(1000)
IF x >= 10 THEN
GOTO gbye
ELSE
high(Gled)
END IF
LOOP
gbye:
low(Gled)
print "Now we are done."
END
What about booting from EEPROM? Will you want the delay there? Maybe I need to add an ifdef feature so you can add a delay at the beginning of your main program that gets removed when not built in debug mode.
Edit: Thinking more, I guess the xbasic compiler could automatically add a delay at the start of the main function if a DEBUG flag was set. Then the xbasic IDE could always set that flag and the user wouldn't have to insert the delay manually.
A DEBUG flag sounds good.
It already takes Propeller an epoch to boot from EEPROM - one more second wouldn't hurt
It already takes Propeller an epoch to boot from EEPROM - one more second wouldn't hurt
There is already a -d option to xbcom but it dumps all kinds of Smile that no one but me would want to look at. Maybe I'll put that output on an ifdef and repurpose -d to insert the startup delay. I'll let you know when I have that done. Then you can make the xbasic IDE always set that flag. If you don't have time for that maybe I'll dive in and look at the IDE. I'm sure it isn't a big job.
I just modified xbasic to accept a -d option to indicate that a one second delay should be inserted before starting the user program. The delay is actually handled by the loader (serial_helper) so it has no impact on the user's code. Now I guess I need to figure out how to build a Windows version of xbasic...
I just modified xbasic to accept a -d option to indicate that a one second delay should be inserted before starting the user program. The delay is actually handled by the loader (serial_helper) so it has no impact on the user's code. Now I guess I need to figure out how to build a Windows version of xbasic...
I have some IDE diffs outstanding against the repository. I'll resolve those and add the -d option to the run command(s).
Thanks! I'm trying to boot my WinXP virtual machine but it's hung installing an update. It's been at 40% for an hour at least. If this ever finishes I'll build a Windows version of the compiler.
I just ran me hello2.bas program on my C3 board with the memory configuration set at FLASH - RAM -1M- 1M, and the little program is working as expected. I gues my next qustion will not go over very well but, is the use of cognew/coginit set in stone? It still seems like having it work similar to the way it is used in Spin might not scare the Smile out of the new users. I was thinking something along the lines of:
pstack = 25
cognew(@blinker,@bstack)
defcog blinker
/* Some code */
end defcog
What would something along those lines entail, besides a complete rewrite of the compiler? It seems like with the byte array setup, it will definitely discourage people from using xBasic, IMHO. I could be missing the big picture on this item.
I noticed xBasic has some peek and poke commands, this could be very dangerous in the hands of some new users if I remember correctly as to how those commands are used. On the C3, with a memory location map, could you poke things into the upper 32KB of the EEPROM? Or would there be better way of doing something like that?
It will have the -d enhancement David mentioned for starting IDE based programs. That is, a startup delay is not required.
It also has what this community considers an improvement: I.E. Set Project is no longer required. Whatever editor tab you click on will be compiled. The only gotchas are that the file must have at least one line of code not in a def function block to compile correctly, and save as will not automatically set the file to compile.
I just tried installing the latest version -19, and I get an error, "... mingwm10.dll is missing ...". Should I reinstall -018, and then install the new version on top of the old version. What I did do was uninstall -018 then I did a new install of -019.
I just tried installing the latest version -19, and I get an error, "... mingwm10.dll is missing ...". Should I reinstall -018, and then install the new version on top of the old version. What I did do was uninstall -018 then I did a new install of -019.
Ray
Oops. Download the attachment and un-zip mingwm10.dll to the Program Files (x86)\xBasic IDE\bin folder.
I just ran me hello2.bas program on my C3 board with the memory configuration set at FLASH - RAM -1M- 1M, and the little program is working as expected. I gues my next qustion will not go over very well but, is the use of cognew/coginit set in stone? It still seems like having it work similar to the way it is used in Spin might not scare the Smile out of the new users. I was thinking something along the lines of:
pstack = 25
cognew(@blinker,@bstack)
defcog blinker
/* Some code */
end defcog
What would something along those lines entail, besides a complete rewrite of the compiler? It seems like with the byte array setup, it will definitely discourage people from using xBasic, IMHO. I could be missing the big picture on this item.
Allowing multiple COGs to run xbasic code at the same time wouldn't be too difficult for hub-based code and data. It becomes more difficult if you move code and/or data to external memory since you now have to share the cache driver that interfaces to external memory with all of the COGs running xbasic code. This is a similar problem to what we just solved in propgcc. Our solution there was to allocate a separate cache for each COG running XMM C code and sharing a single external memory driver. The same approach could be done with xbasic. It's easiest if you only allow code in external memory. Allowing data in external memory opens up a huge can of worms related to cache coherency. Anyway, either is doable but I'm not sure I'll have time to do this anytime soon. Sorry!
I noticed xBasic has some peek and poke commands, this could be very dangerous in the hands of some new users if I remember correctly as to how those commands are used. On the C3, with a memory location map, could you poke things into the upper 32KB of the EEPROM? Or would there be better way of doing something like that?
Ray
Yes, PEEK and POKE are dangerous. Also, they only work for poking stuff into hub memory or external data memory. They don't work for writing to EEPROM.
It will have the -d enhancement David mentioned for starting IDE based programs. That is, a startup delay is not required.
It also has what this community considers an improvement: I.E. Set Project is no longer required. Whatever editor tab you click on will be compiled. The only gotchas are that the file must have at least one line of code not in a def function block to compile correctly, and save as will not automatically set the file to compile.
Simple xbasic project (thanks to your last change):
include "print.bas"
include "propeller.bas"
print "Hello, World!"
Easy for almost anyone to swallow.
As for complicated xbasic projects, sample\GameBaby is a good one. I don't expect many folks do dive in and look, but that demos the power xbasic can wield without a project.
Complicated xbasic GameBaby project:
rem =================================================
rem include files
rem
include "GbLCD.bas"
include "GbI2C.bas"
include "GbGUI.bas"
include "lastcog.bas"
include "GbBattery.bas"
include "print.bas"
include "propeller.bas"
include "string.bas"
rem =================================================
rem main program code here
rem don't mix variables inside of code blocks.
rem =================================================
def startup
dim x,y,m,n
dim buttons
REM ---------------------------------------------
REM send user startup message and show our cogid
REM
print "Starting Gamebaby... ";
cog = cogid
print "COGID "; cog
REM ---------------------------------------------
REM startup the LCD and clear screen to background color.
REM
GbLCD_start
GbLCD_clear(GbLCD_BLUE)
REM ---------------------------------------------
REM startup the I2C devices including the button monitor.
REM
GbI2C_start
REM ---------------------------------------------
REM show last available cog number
REM
print "LastCog "; lastcog
REM ---------------------------------------------
REM Make a panel
REM
GbGUI_panel_parms(GbLCD_WHITEST_GRAY,3,15,GbLCD_MAXX-8,GbLCD_MAXY-21,0)
REM ---------------------------------------------
REM Make a title and show battery
REM
GbLCD_setBgColor(GbLCD_BLUE)
GbGUI_textColor(GbLCD_YELLOW)
//GbGUI_Label("GameBaby",5,4)
GbGUI_3Dbutton("OK",GbLCD_MAXX-40,GbLCD_MAXY-35)
do
GbBattery_show(GbLCD_MAXX-20,3,GbLCD_YELLOW, GbLCD_BLUE)
waitcnt(clkfreq/4+cnt)
GbLCD_setBgColor(GbLCD_BLUE)
GbLCD_setFgColor(GbLCD_YELLOW)
GbLCD_printXY(" GameBaby! ",0,0)
x = 4 //GbLCD_getx
y = 2 //GbLCD_gety
buttons = GbButtons_buttons
if oldbut <> buttons then
oldbut = buttons
GbLCD_setTextXY(x,y)
GbLCD_bin(buttons,9)
end if
//GbBattery_showVoltage
GbLCD_setTextXY(28,32)
for n = 0 to 4
GbLCD_hex(GbI2C_accel_readReg(n),2)
next n
GbLCD_setTextXY(28,33)
for n = 0 to 8
GbLCD_hex(GbI2C_ee_readByte(n),2)
next n
GbLCD_setTextXY(28,34)
GbI2C_rtc_readRegs
for n = 0 to 4
GbLCD_hex(GbI2C_rtc_getReg(n),2)
next n
waitcnt(clkfreq/10+cnt)
loop
end def
rem =================================================
rem call startup here
rem =================================================
startup
rem =================================================
rem end of file
rem =================================================
Dave Jenson, your GameBaby is sitting next to my mouse. There are several things I need to ship this week.
It seems to me that the idea of just compiling whatever file is open in the editor as if it were the main program is good only for doing demos. You can open up lots of main program files and run them each in turn by clicking on their filename in the file list to make them the open file and then press "run". However, this is never the way I work and isn't the way anyone else I know works. Normally I'm working on one program and often that program consists of multiple files. To get that program working I have to edit and fix bugs in all of the files in that set that makes up the program. I don't want to continually select the file containing the main function every time I want to test my edits. I want to press "run" whever I am and have the IDE know which file contains the main program. This is true when I'm programming in Spin, C, or even xbasic. Yes, in Spin and xbasic the main file can sort of be considered to define the project but that isn't always the file that is open in the editor when I am working. I might be trying to fix a bug in one of the other files.
Anyway, the way Spin works seems like a way to cater to demos and maybe lectures in a classroom rather than the way people do real programming projects. This is a bad tradeoff in my opinion.
It seems to me that the idea of just compiling whatever file is open in the editor as if it were the main program is good only for doing demos. ...
Isn't it common to support both ?
A full project Build, needs to know a project, but often there is also a Compile Current File type of command
If that is stand-alone main pgm, with all includes, then that will also be the same as build.
Some IDEs also have a 3rd choice of batch Build, where the IDE calls a batch file and now users have full command line control over how much or little build is done, as well as any pre-post-process actions.
I certainly haven't used every IDE out there but I remember a feature in Visual Studio that would make a project out of the currently open file. You still needed a project to build anything but the IDE was willing to create one for you.
The IDE -20 has some quirks. Since the set project button was removed, now when you create a new file, you can save the file but you cannot set it so it will run. What I do is save the file, then close the file, when you open the file again it has been set, so now you can run it.
I decided to dig out my QuickStart Board and work with that for a while. Below is a program to sweep through the available LEDs on that board. It works for a forward sweep, but for some reason I cannot get it too do a backward sweep using the FOR command.
For the next test I guess I need some advise from the experts, how to I create an xBasic command to access the button(s) on the QuikStart (QS) board? I looked at the Spin example code, that is located in the download section of the Parallax store, and the code for the button contains a COG start, so I am not sure how easy that would be to translate to xBasic.
Again a reminder for new users when you are using xBasic you have to make sure that the board configuration is the correct one. Since this version of the IDE does not have a QS selection, you will have to set it to HUB - HUB. Also in the code below I use "extra.bas" which you can cut/paste from an earlier post.
Ray
REM ==========
REM testQS1.bas
REM ==========
/* Include items */
include "print.bas"
include "propeller.bas"
include "extra.bas"
/* Assignments */
/* Start */
/* Step forward */
time = 250
FOR pin = 16 TO 23
led(pin,time)
NEXT pin
/* Step backward? */
waitMS(250)
FOR pin = 23 TO 16 STEP (-1)
led(pin,time)
NEXT pin
END
/* Control QS LED */
/* pin = 16 - 23 */
/* time is in miliseconds. */
def led(pin,time)
high(pin)
waitMS(time)
low(pin)
end def
Currently, reading the buttons on the QuickStart will require making a PASM blob out of the driver code. I'm afraid I don't have time to do that today because I'm back to my normal work week. Unfortuately, I also have meetings for the next three evenings so I may not be able to get to this until the end of the week. As has been mentioned by Steve, there are examples of this in the samples directory of the xbasic tree. The TV driver is there along with some others I think. You could try your hand at doing something similar for the QuickStart buttons and I'll try to help you out along the way. Sorry I can't just do it for you right now!!
Comments
DEF makes constants. You can't change constants in your program.
XBasic-Manual-revised.pdf
Just how many people besides you will use the command line?
You can post a new compiler here, and it can be replaced in the user's program files area.
Code Memory HUB
Data Memory RAM
External Flash Size 1M
External RAM Size 1M
For a simple do loop it was working fine, when I started to use the 'until' part, it was running into problems. Once I set the configuration to:
Code Memory HUB
Data Memory HUB
External Flash Size
External RAM Size
Then the 'until' started to work. So, the question is, why doesn't the 'do loop' with an 'until' not work in Data Memory RAM? So, even in xbasic we have some restrictions as to what runs in Data Memory HUB, and what runs in Data Memory RAM.
Ray
Yes, just use HUB. There are only a few external memory drivers in the current package, and none of them support the DNA board.
Edit: Thinking more, I guess the xbasic compiler could automatically add a delay at the start of the main function if a DEBUG flag was set. Then the xbasic IDE could always set that flag and the user wouldn't have to insert the delay manually.
Ray
A DEBUG flag sounds good.
It already takes Propeller an epoch to boot from EEPROM - one more second wouldn't hurt
I have some IDE diffs outstanding against the repository. I'll resolve those and add the -d option to the run command(s).
I noticed xBasic has some peek and poke commands, this could be very dangerous in the hands of some new users if I remember correctly as to how those commands are used. On the C3, with a memory location map, could you poke things into the upper 32KB of the EEPROM? Or would there be better way of doing something like that?
Ray
It will have the -d enhancement David mentioned for starting IDE based programs. That is, a startup delay is not required.
It also has what this community considers an improvement: I.E. Set Project is no longer required. Whatever editor tab you click on will be compiled. The only gotchas are that the file must have at least one line of code not in a def function block to compile correctly, and save as will not automatically set the file to compile.
I did notice that the link to the IDE site appears to be broken using Explorer, The link is OK using Chrome !
I have used MS xbasic in the past.
@Ray
I do not remember any version of Basic, which does not include PEEK and POKE.
Ron
Ray
Oops. Download the attachment and un-zip mingwm10.dll to the Program Files (x86)\xBasic IDE\bin folder.
I'll fix the package.
A Windows Ate My ComputerTM tested version 20 is now posted here: http://www.microcsource.com/xbasic/xBasicIDE.zip
Yes, PEEK and POKE are dangerous. Also, they only work for poking stuff into hub memory or external data memory. They don't work for writing to EEPROM.
Complicated xbasic GameBaby project:
rem ================================================= rem include files rem include "GbLCD.bas" include "GbI2C.bas" include "GbGUI.bas" include "lastcog.bas" include "GbBattery.bas" include "print.bas" include "propeller.bas" include "string.bas" rem ================================================= rem main program code here rem don't mix variables inside of code blocks. rem ================================================= def startup dim x,y,m,n dim buttons REM --------------------------------------------- REM send user startup message and show our cogid REM print "Starting Gamebaby... "; cog = cogid print "COGID "; cog REM --------------------------------------------- REM startup the LCD and clear screen to background color. REM GbLCD_start GbLCD_clear(GbLCD_BLUE) REM --------------------------------------------- REM startup the I2C devices including the button monitor. REM GbI2C_start REM --------------------------------------------- REM show last available cog number REM print "LastCog "; lastcog REM --------------------------------------------- REM Make a panel REM GbGUI_panel_parms(GbLCD_WHITEST_GRAY,3,15,GbLCD_MAXX-8,GbLCD_MAXY-21,0) REM --------------------------------------------- REM Make a title and show battery REM GbLCD_setBgColor(GbLCD_BLUE) GbGUI_textColor(GbLCD_YELLOW) //GbGUI_Label("GameBaby",5,4) GbGUI_3Dbutton("OK",GbLCD_MAXX-40,GbLCD_MAXY-35) do GbBattery_show(GbLCD_MAXX-20,3,GbLCD_YELLOW, GbLCD_BLUE) waitcnt(clkfreq/4+cnt) GbLCD_setBgColor(GbLCD_BLUE) GbLCD_setFgColor(GbLCD_YELLOW) GbLCD_printXY(" GameBaby! ",0,0) x = 4 //GbLCD_getx y = 2 //GbLCD_gety buttons = GbButtons_buttons if oldbut <> buttons then oldbut = buttons GbLCD_setTextXY(x,y) GbLCD_bin(buttons,9) end if //GbBattery_showVoltage GbLCD_setTextXY(28,32) for n = 0 to 4 GbLCD_hex(GbI2C_accel_readReg(n),2) next n GbLCD_setTextXY(28,33) for n = 0 to 8 GbLCD_hex(GbI2C_ee_readByte(n),2) next n GbLCD_setTextXY(28,34) GbI2C_rtc_readRegs for n = 0 to 4 GbLCD_hex(GbI2C_rtc_getReg(n),2) next n waitcnt(clkfreq/10+cnt) loop end def rem ================================================= rem call startup here rem ================================================= startup rem ================================================= rem end of file rem =================================================Anyway, the way Spin works seems like a way to cater to demos and maybe lectures in a classroom rather than the way people do real programming projects. This is a bad tradeoff in my opinion.
Isn't it common to support both ?
A full project Build, needs to know a project, but often there is also a Compile Current File type of command
If that is stand-alone main pgm, with all includes, then that will also be the same as build.
Some IDEs also have a 3rd choice of batch Build, where the IDE calls a batch file and now users have full command line control over how much or little build is done, as well as any pre-post-process actions.
I decided to dig out my QuickStart Board and work with that for a while. Below is a program to sweep through the available LEDs on that board. It works for a forward sweep, but for some reason I cannot get it too do a backward sweep using the FOR command.
For the next test I guess I need some advise from the experts, how to I create an xBasic command to access the button(s) on the QuikStart (QS) board? I looked at the Spin example code, that is located in the download section of the Parallax store, and the code for the button contains a COG start, so I am not sure how easy that would be to translate to xBasic.
Again a reminder for new users when you are using xBasic you have to make sure that the board configuration is the correct one. Since this version of the IDE does not have a QS selection, you will have to set it to HUB - HUB. Also in the code below I use "extra.bas" which you can cut/paste from an earlier post.
Ray
REM ========== REM testQS1.bas REM ========== /* Include items */ include "print.bas" include "propeller.bas" include "extra.bas" /* Assignments */ /* Start */ /* Step forward */ time = 250 FOR pin = 16 TO 23 led(pin,time) NEXT pin /* Step backward? */ waitMS(250) FOR pin = 23 TO 16 STEP (-1) led(pin,time) NEXT pin END /* Control QS LED */ /* pin = 16 - 23 */ /* time is in miliseconds. */ def led(pin,time) high(pin) waitMS(time) low(pin) end def