If you select in the same line from left to right it works. But if you select several lines either with the keys or with the mouse it behaves as if nothing was selected. 3 lines is ok. 4 lines like nothing is selected. Disconcerting.
For me, I can select any number of lines from right to left, if there are only spaces between the cursor and the left margin it will delete all the spaces up to the margin from where the cursor is when I hit the del/backspace key.
Howdy - I'm trying to use BST on a Mac G4 Powerbook. The tool seems to have loaded nicely, but doesn't see the Prop Demo board... guess I need a USB configurator like under Win. If so, where can I find one?
Thanks,
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
WNed said...
Howdy - I'm trying to use BST on a Mac G4 Powerbook. The tool seems to have loaded nicely, but doesn't see the Prop Demo board... guess I need a USB configurator like under Win. If so, where can I find one?
BradC said...
The aim is download, click and go. No futzing about required.
Dude, you Da Man!
Thanks for getting back to me so quickly with the FTDI driver info. All I've ever used my Powerbook for, until now, is writing and editing movies... I am no OS X guru. And yet, I was able to install and begin using BST almost immediately!
I'm sure you had fun doing it, but Thanks for all the work.
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
If there is space to the left of the selection till the first column backspace will erase only the space.
If there are no spaces then backspace will erase the selection.
I have not been following this tread but now that I am thinking about installing Ubuntix Linux I am interested in how this is coming along. Is there a download of this software? What page is it on if there is?
Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
If it's not Parallax then don't even bother. :-) ·
Mini-Din/PS2 connectors are for sale! 5 for $1! PM me if you wish to make an order. Cheap·shipping unless specified!··········150 left!!··
@Microcontrolled - The link to the package is in the very first post, but is not really noticeable.
BradC said...
up-to-date binaries for everything available here
www.fnarfbargle.com/bst/
Right before the "Changes" section.
That link will take you to a directory page. If you click on the "0184" link, you'll get a page that has the latest version of the actual binary images needed to install the tool. Right click on your desired version to download it.
The Linux driver to establish a serial port connection through USB can be found here: http://www.ftdichip.com/Drivers/VCP/Linux/ftdi_sio.tar.gz
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
WNed said...
@Microcontrolled - The link to the package is in the very first post, but is not really noticeable.
BradC said...
up-to-date binaries for everything available here
www.fnarfbargle.com/bst/
Right before the "Changes" section.
That link will take you to a directory page. If you click on the "0184" link, you'll get a page that has the latest version of the actual binary images needed to install the tool. Right click on your desired version to download it.
The Linux driver to establish a serial port connection through USB can be found here: http://www.ftdichip.com/Drivers/VCP/Linux/ftdi_sio.tar.gz
Ned
Thanks for pointing that out to him Ned. One tiny correction though. On almost any Linux distribution newer than 5 years old, the ftdi driver is built in as a supported kernel driver. There is no need to install third party device drivers on Linux to detect your prop plugs or demo boards. Most distributions will have hal or udev load the fdti driver for you automagically when you plug your USB connection in. You _may_ need to ensure you have permissions for the port, but again most do it for you.
I have to admit, I was really surprised that I had to perform the extra installation under OS X. Not at all surprised that the FTDI driver is built-in for Linux.
BTW, Brad, what's the going rate for your sig-space?
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
I found a bug. I had a compile error(caused by my syntax). It created a pane that was way too large to hold the error message and then the pane wasn't resizable.
I found a bug. I had a compile error(caused by my syntax). It created a pane that was way too large to hold the error message and then the pane wasn't resizable.
See snapshot.
Thanks,
Doug
2 Questions :
- Are you using 0.18.x ?
- Is this the first time the error box has popped up since upgrading from either 0.17 or 0.18-Prex ?
If you can reproduce it, can you hide the error box (view -> errors) then close bst and send me the contents of the
Geometry=
..line from .bst.ini? You must close bst to properly write the current values into the file.
This may not be a bug, think of it more as a question. Now I know indentation is important, but I didn't know that indenting something one space to the left would cause it to be skipped. In the following code I must've spent 30 minutes trying to figure out why only one character was being printed. When I simply moved the line indicated over by one space - it worked perfectly. If I delete just one space left of the "repeat strsize(@ver)" line, like shown below, it is ignored.
LCD.clear
LCD.Move(4,1)
LCD.str(@SB)
LCD.CR
waitcnt(clkfreq + cnt)
i:= 0
repeat strsize(@ver) '<<<<<<<<<<<<-------------------
repeat X from 16 to 4 + i
LCD.Move(X, 2)
LCD.Char(ver[noparse][[/noparse] i])
waitcnt(clkfreq/30 + cnt)
LCD.Char(" ")
i++
W9GFO said...
This may not be a bug, think of it more as a question. Now I know indentation is important, but I didn't know that indenting something one space to the left would cause it to be skipped. In the following code I must've spent 30 minutes trying to figure out why only one character was being printed. When I simply moved the line indicated over by one space - it worked perfectly. If I delete just one space left of the "repeat strsize(@ver)" line, like shown below, it is ignored.
LCD.clear
LCD.Move(4,1)
LCD.str(@SB)
LCD.CR
waitcnt(clkfreq + cnt)
i:= 0
repeat strsize(@ver) '<<<<<<<<<<<<-------------------
repeat X from 16 to 4 + i
LCD.Move(X, 2)
LCD.Char(ver[noparse][[/noparse] i])
waitcnt(clkfreq/30 + cnt)
LCD.Char(" ")
i++
I must be missing something. I don't get the problem. This is going to sound odd, but can you archive a copy that works, and archive a copy that fails and attach, PM or e-mail me both archives so I can compile and compare them locally and look at the list file outputs to see what is going on ?
I've a feeling I'm missing something, but I'm not sure what.
Are you saying if the 1st repeat (which is indented 1 space in your example above) is not indented at all (as in sitting in the first column) that the loop under it only executes once?
W9GFO said...
As shown, the loop under it only executes once.
If that is expected behavior then it is a small miracle that I have gone this long without making that mistake.
No, its not expected behaviour at all, and I can't reproduce it locally with any test case I can produce which is why I asked if I could have an archived copy of your source. I need to look at the compiled listing output and try and understand what is actually going on.
Look closer. When you have the repeat one space back you are including the waitcnt and the lcd.clear in your loop. It will print one char, then wait 6 seconds, clear the screen and then do the next one.
repeat strsize(@fun) ' <<<<<<<<<<<<<<<--------------------------
repeat X from 16 to 4 + i
LCD.Move(X, 2) ' lesser dramatic pause
LCD.Char(fun[i])
waitcnt(clkfreq/30 + cnt)
LCD.Char(" ")
i++
waitcnt(clkfreq*6 + CNT)
LCD.CLEAR
[/i]
These last seven posts are a perfect example of why using white space for delimiting blocks of code is such a bad idea.
1. W9GFO had a problem which he could not see.
2. BradC could not see the problem because the code indentation gets mangled in the forum.
3. iterate iterate...
I rest my case.[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
These last seven posts are a perfect example of why using white space for delimiting blocks of code is such a bad idea.
1. W9GFO had a problem which he could not see.
2. BradC could not see the problem because the code indentation gets mangled in the forum.
Not to be picky, but he did not actually post the whole code in the forum which is why I could not see the problem. The parts that were inadvertently included in the loop were excluded from the post [noparse];)[/noparse]
I really don't have a problem with whitespace delimiting code. It's a constraint and you work within it. I tell you what though, it was immediately obvious when I looked at the two list file outputs side by side that the loop was not where it should have been. That made me go back and have a look at the source file again, which is when it jumped out and hit me in the face.
I was actually looking for a compiler bug (there have been a few over the last 9 months), but thankfully it was a little simpler than that [noparse]:)[/noparse]
Has anyone come across a problem where they can successfully detect the propeller and compile and download a spin file to the prop, but attempting to download a binary or eeprom file produces a "We can't find a propeller..." error message?
It's the same download program. In one case a Spin program is compiled to a temporary binary file first. In the other case, the compilation is skipped.
Can you reproduce this? If so, what are the circumstances? Be as specific as possible.
It could be a broken cable. It could be a power supply problem. It could also be a very subtle bug.
It's much much better to avoid saying "Has anyone come across ..." and just state "I've had something odd/unexpected happen where I ... and I ... and this happened ...".
I can reproduce the problem with 100% success (or failure?), if I 'Compile and Load EEPROM' from a spin file everything functions as expected, however, if I 'Compile and save BINARY' or 'Compile and save EEPROM' then open the resultant file and select either 'Ram or EEPROM' from the 'bst Binary Download' dialog box I get the "We can't find a propeller..." error.
If the standard path for the bst tool when compiling a spin is to create a binary then download that to the prop, I'm thinking that hardware probably isn't at fault here.
Painless said...
Has anyone come across a problem where they can successfully detect the propeller and compile and download a spin file to the prop, but attempting to download a binary or eeprom file produces a "We can't find a propeller..." error message?
Is this a bug?
Most probably, yes.. I don't really download .binary or .eeprom files, so it's not a code path I test heavily.
Let me look into it and see if I can spot anything odd I might be doing with the ports.
If you can give me a reliable way to reproduce it in a step by step (ie. click here, then here, then load this, then press...) it would help a lot.
Painless said...
I can reproduce the problem with 100% success (or failure?), if I 'Compile and Load EEPROM' from a spin file everything functions as expected, however, if I 'Compile and save BINARY' or 'Compile and save EEPROM' then open the resultant file and select either 'Ram or EEPROM' from the 'bst Binary Download' dialog box I get the "We can't find a propeller..." error.
After reading your description above, it most certainly sounds like a bug. Mike is right in that the code to download is exactly the same in all cases, but the code path differs with binary downloads and there may be a bug with how the port gets detected/selected.
Is your propeller autodetected normally when you press F7?
Have you set the propeller port manually using the IDE preferences?
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
I just double checked, I am using 0.18.4.
Rich H
Well you are half right:
If you select in the same line from left to right it works. But if you select several lines either with the keys or with the mouse it behaves as if nothing was selected. 3 lines is ok. 4 lines like nothing is selected. Disconcerting.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
???
For me, I can select any number of lines from right to left, if there are only spaces between the cursor and the left margin it will delete all the spaces up to the margin from where the cursor is when I hit the del/backspace key.
Rich H
Post Edited (W9GFO) : 7/20/2009 8:55:47 PM GMT
Thanks,
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
www.ftdichip.com/Drivers/VCP.htm
www.ftdichip.com/Drivers/VCP/MacOSX/FTDIUSBSerialDriver_v2_1_10.dmg
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
Thanks for getting back to me so quickly with the FTDI driver info. All I've ever used my Powerbook for, until now, is writing and editing movies... I am no OS X guru. And yet, I was able to install and begin using BST almost immediately!
I'm sure you had fun doing it, but Thanks for all the work.
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
If there is space to the left of the selection till the first column backspace will erase only the space.
If there are no spaces then backspace will erase the selection.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
If it's not Parallax then don't even bother. :-)
·
Mini-Din/PS2 connectors are for sale! 5 for $1! PM me if you wish to make an order.
Cheap·shipping unless specified!··········150 left!!··
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
bst[noparse][[/noparse]c] misses this very fundamental error and causes incorrect code output. Be warned!
I've fixed it now, but please be aware of the bug.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
That link will take you to a directory page. If you click on the "0184" link, you'll get a page that has the latest version of the actual binary images needed to install the tool. Right click on your desired version to download it.
The Linux driver to establish a serial port connection through USB can be found here:
http://www.ftdichip.com/Drivers/VCP/Linux/ftdi_sio.tar.gz
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
Thanks for pointing that out to him Ned. One tiny correction though. On almost any Linux distribution newer than 5 years old, the ftdi driver is built in as a supported kernel driver. There is no need to install third party device drivers on Linux to detect your prop plugs or demo boards. Most distributions will have hal or udev load the fdti driver for you automagically when you plug your USB connection in. You _may_ need to ensure you have permissions for the port, but again most do it for you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
BTW, Brad, what's the going rate for your sig-space?
Ned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
I found a bug. I had a compile error(caused by my syntax). It created a pane that was way too large to hold the error message and then the pane wasn't resizable.
See snapshot.
Thanks,
Doug
2 Questions :
- Are you using 0.18.x ?
- Is this the first time the error box has popped up since upgrading from either 0.17 or 0.18-Prex ?
If you can reproduce it, can you hide the error box (view -> errors) then close bst and send me the contents of the
Geometry=
..line from .bst.ini? You must close bst to properly write the current values into the file.
The error box height is the last number. It defaults to 150 (which is a pretty good value) if you are upgrading from an earlier version of bst.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
LCD.clear LCD.Move(4,1) LCD.str(@SB) LCD.CR waitcnt(clkfreq + cnt) i:= 0 repeat strsize(@ver) '<<<<<<<<<<<<------------------- repeat X from 16 to 4 + i LCD.Move(X, 2) LCD.Char(ver[noparse][[/noparse] i]) waitcnt(clkfreq/30 + cnt) LCD.Char(" ") i++OS X 10.5.7 intel 0.18.4
Rich H
I must be missing something. I don't get the problem. This is going to sound odd, but can you archive a copy that works, and archive a copy that fails and attach, PM or e-mail me both archives so I can compile and compare them locally and look at the list file outputs to see what is going on ?
I've a feeling I'm missing something, but I'm not sure what.
Are you saying if the 1st repeat (which is indented 1 space in your example above) is not indented at all (as in sitting in the first column) that the loop under it only executes once?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
If that is expected behavior then it is a small miracle that I have gone this long without making that mistake.
Rich H
Post Edited (W9GFO) : 7/22/2009 9:33:27 AM GMT
No, its not expected behaviour at all, and I can't reproduce it locally with any test case I can produce which is why I asked if I could have an archived copy of your source. I need to look at the compiled listing output and try and understand what is actually going on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
Rich H
repeat strsize(@fun) ' <<<<<<<<<<<<<<<-------------------------- repeat X from 16 to 4 + i LCD.Move(X, 2) ' lesser dramatic pause LCD.Char(fun[i]) waitcnt(clkfreq/30 + cnt) LCD.Char(" ") i++ waitcnt(clkfreq*6 + CNT) LCD.CLEAR [/i]▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
Rich H
1. W9GFO had a problem which he could not see.
2. BradC could not see the problem because the code indentation gets mangled in the forum.
3. iterate iterate...
I rest my case.[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Not to be picky, but he did not actually post the whole code in the forum which is why I could not see the problem. The parts that were inadvertently included in the loop were excluded from the post [noparse];)[/noparse]
I really don't have a problem with whitespace delimiting code. It's a constraint and you work within it. I tell you what though, it was immediately obvious when I looked at the two list file outputs side by side that the loop was not where it should have been. That made me go back and have a look at the source file again, which is when it jumped out and hit me in the face.
I was actually looking for a compiler bug (there have been a few over the last 9 months), but thankfully it was a little simpler than that [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
Is this a bug?
Russ.
It's the same download program. In one case a Spin program is compiled to a temporary binary file first. In the other case, the compilation is skipped.
Can you reproduce this? If so, what are the circumstances? Be as specific as possible.
It could be a broken cable. It could be a power supply problem. It could also be a very subtle bug.
It's much much better to avoid saying "Has anyone come across ..." and just state "I've had something odd/unexpected happen where I ... and I ... and this happened ...".
If the standard path for the bst tool when compiling a spin is to create a binary then download that to the prop, I'm thinking that hardware probably isn't at fault here.
Russ.
Most probably, yes.. I don't really download .binary or .eeprom files, so it's not a code path I test heavily.
Let me look into it and see if I can spot anything odd I might be doing with the ports.
If you can give me a reliable way to reproduce it in a step by step (ie. click here, then here, then load this, then press...) it would help a lot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
Is your propeller autodetected normally when you press F7?
Have you set the propeller port manually using the IDE preferences?
Are you using OSX or Linux?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>