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?
Are you using OSX or Linux?
Brad,
My OS is Linux, the propeller is detected automatically when I use F7. I've tried both setting the port by hand and using the auto function.
I think I may have narrowed the bug down for you:
My prop is on ttyUSB2 and bst is set to use such, however, on the "bst Binary Download" dialog when I click 'EEPROM' the box that pops up with the progress bar states that it is using ttyUSB1 (the error message that appears next states that it can't find the prop on ttyUSB2), looks like a value isn't getting passed or retrieved correctly for the port to use in this case?
I downloaded the latest yesterday and was using that.(0.18.4)
I did what you said: Geometry=0,0,1096,1077,270,224,902
The error pain goes away as expected when I fix the error and F10.
Thanks,
Doug
If you edit that line (use vi or gedit or something like that)
Geometry=0,0,1096,1077,270,224,150
that should solve the problem. I'll try and figure out what may have caused that to happen and make sure
there is some sanity checking in the next version.
A window pane adjuster would be great, so I could drag it wide open in the case where I have lots of errors, and drag it back to normal when it is out of hand like it was.
If you don't like windows so much(neither do I), why didn't you name the settings file .bstrc instead of .bst.ini?
The fact that you can select different ports for multiple props is great, it's just that in the CONFIGURE PORTS dialog there is nothing that basically says APPLY or OK. If I find a suitable port I can TEST ok but whatever I do after that I have to click CLOSE WINDOW and then none of the settings are applied. This perhaps is the most frustrating part of using what otherwise is a truly excellent IDE (still is). Keep up the good work, now that we are hooked on BST, you're our dealer and we need you.
hinv said...
A window pane adjuster would be great, so I could drag it wide open in the case where I have lots of errors, and drag it back to normal when it is out of hand like it was.
If you don't like windows so much(neither do I), why didn't you name the settings file .bstrc instead of .bst.ini?
Doug
There is a window pane adjuster (technically called a splitter), which is why I'm puzzled you could not get it to resize. Just click and drag the bar between the editor and the error box..
I kept it to .ini as it uses the old Windows .ini format. It's the same on OSX and Linux. On Win32 I shoved all the settings in the registry as it was just as easy.
The fact that you can select different ports for multiple props is great, it's just that in the CONFIGURE PORTS dialog there is nothing that basically says APPLY or OK. If I find a suitable port I can TEST ok but whatever I do after that I have to click CLOSE WINDOW and then none of the settings are applied. This perhaps is the most frustrating part of using what otherwise is a truly excellent IDE (still is). Keep up the good work, now that we are hooked on BST, you're our dealer and we need you.
*Peter*
That is most odd. When I back out of the config dialog (I did it that way so the UI experience is the same across all OS) it sets the port correctly. Whatever port is in the port name box at the bottom is the one that is supposed to stick when you close the box. I'll have a look to see if I broke something.
I've been using the latest version of your bstc and the wonderful list file it generates. I noticed a few odd things:
1. Assigned return symbols always get translated to the "Result" symbol.
'For example
PUB get : rc
rc := 1 ' rc becomes Result
This one I guess I can fix relatively easily. There is _always_ a result variable assigned to any method, so the list file simply picks the first one for the symbol table (which is always Result). Of course it does not affect the generated code.
jazzed said...
2. A "repeat" statement with no follow-on code appears to translate into a non functional reference only repeat of the previous statement.
'For example
PUB main | rc
rc++
repeat ' this statement never actually gets run
This one produces correct code, and also lists it properly in the list file, it simply omits the repeat source line. I'll look into that, but I can see the correct code generated in the list file and I can guarantee it works.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Thanks Brad.
Yes, item 2 functions correctly, but I was expecting to see a source list line generated for the repeat statement. A spin debugger relying on the source list will never point to the "empty" repeat without an ugly hack. Item 1 is cosmetic, but could easily confuse the user of a symbolic spin debugger especially when no hover balloon value pops up. The bstc and propeller tool generated binaries are identical.
jazzed said...
Thanks Brad.
Yes, item 2 functions correctly, but I was expecting to see a source list line generated for the repeat statement. A spin debugger relying on the source list will never point to the "empty" repeat without an ugly hack.
It is an awkward one really as when you look into the bytecode, the code generated for the repeat statement actually occurs *after* the code it's repeating.
That particular repeat construct is a simple jump. I'm not actually sure of the best way to handle it from that perspective.
Also, if you are looking at using the listing for stepping a debugger you may find "challenges" surrounding the way it generates output for case constructs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Don't feel bad Brad. Homespun "case" is also challenging, but I have something that *works* for both (in the case anyway). FWIW, I've found BSTC listing output is harder to parse, but the spin source lines make it much easier to use without guess-work ... I gave up on homespun in January for lack of source line numbers. The only reason I've revived this project is to allow creating and debugging loadable "virtual spin" methods ... still being developed.
jazzed said...
FWIW, I've found BSTC listing output is harder to parse, but the spin source lines make it much easier to use without guess-work ...
When I looked at it (admittedly a while ago now) homespun seemed to use a syntax similar to the one hippy developed while he was reverse engineering the spin bytecodes (prior to the release of the interpreter).
Prior to writing the compiler I wrote a spin bytecode disassembler to help me figure out how the parallax compiler did what it did. I used a combination of naming from the interpreter source ("drop anchor" for example) and what seemed to make sense to me. It's probably harder for a machine to parse, but I find it much more readable when I'm reading a disassembled file. I simply plugged the disassembler into the compiler to generate the list file on the fly.
I'd be happy to make changes if it would help.
Admittedly I use the list file window in bst all the time. It really helps when you are optimising spin code for size/speed to understand precisely what bytecode is being used for what and being able to see how many bytes each construct takes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
@Brad: Finally got around to compiling ZiCog on the TriBlade - it worked straight off - very nice indeed, thankyou
@Brad & @Jeff: FONTS I am using Vista. The fonts did not work correctly (put spaces between characters so not doing UTF16 correctly). There was no Parallax.ttf in the font directory. I was using PropTool 1.2 so I downloaded PropTool 1.2.6 and installed it. Now I have Parallax.ttf in my font directory. So I ran bst and voila - I have the fonts working correctly
The code is quite a bit larger than homespun024's output (4290/2664/1234 vs 3260/2664/2264) so I presume I should now turn on some of the compiler options to shrink unused code?? I cannot compile under PropTool, so no comparisons available.
Now for the problem... I cannot locate the prop. PropTool works ok, PropTerminal works ok, but bst refuses to find the prop. I have downloaded the binary from bst to my board and that is great. Any ideas??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Now I have Parallax.ttf in my font directory. So I ran bst and voila - I have the fonts working correctly
That one is in the release notes. For some reason the earlier versions of the Propeller Tool installed the font in such a fashion as it was only accessible to the Propeller Tool under Vista.
Cluso99 said...
The code is quite a bit larger than homespun024's output (4290/2664/1234 vs 3260/2664/2264) so I presume I should now turn on some of the compiler options to shrink unused code?? I cannot compile under PropTool, so no comparisons available.
That is most odd. Aside from STRING( ) allocation and the LSB on floating point, bst and homespun generate pretty much identical code provided the optimisations in bst are turned off.
If you can give me a code archive including homespun and a defined way to reproduce the binaries I can do a bindiff on them and find out what I'm doing wrong. I didn't think homespun did anything to optimise the code or remove unused portions, but then I've not looked at it since about version 17.
Cluso99 said...
Now for the problem... I cannot locate the prop. PropTool works ok, PropTerminal works ok, but bst refuses to find the prop. I have downloaded the binary from bst to my board and that is great. Any ideas??
Not sure really. I did briefly test on Vista prior to the last release. I gather the Propeller Tool detects the prop ok then?
Are you using a standard Prop Plug?
Have you tried to manually set the prop port? (IDE Preferences -> Port allocation)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Brad, that was quick.
I saw the things to do about the fonts but thought I would post what I found
I will email the code to you.
PropTool finds and detects the prop ok, as does PropTerminal. bst finds the com port (com13) but does not find the prop. The test gives a message no prop found. I am using the PropPlug circuit that I built on the TriBlade pcb. Yes I tried to set the port manually but no go. :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
First - when using your tool to compile the attached file, BST gives me an error at line 1, column 1 that says "Expected End of Line, Unary Operator or Math Operator". Using the Parallax tool I found the problem to be in score_char where I wrote:
Second - I find myself having to disconnect the serial terminal manually before programming the Propeller. If I fail to do so the tool will say it can't find the Propeller. Even when I do, it takes two tries before it finds it. I see the serial terminal disconnecting automatically when I attempt to update the program but it's not working out for me. I'm running version 0.18.4 on Ubuntu 9.04. I'm not overly familiar with how the USB ports work on Ubuntu and I see many other items named with usb in /dev besides the /dev/ttyUSB0 being used by the tool. Should I choose one of them, and if so - how do I choose which one?
First - when using your tool to compile the attached file, BST gives me an error at line 1, column 1 that says "Expected End of Line, Unary Operator or Math Operator". Using the Parallax tool I found the problem to be in score_char where I wrote:
Thanks for the example. It makes it dead easy to reproduce here. I'll get that sorted as soon as I can. There are a few of those little bugs lurking around in there still. At least it didn't crash [noparse]:)[/noparse]
Greg Norton said...
Second - I find myself having to disconnect the serial terminal manually before programming the Propeller. If I fail to do so the tool will say it can't find the Propeller. Even when I do, it takes two tries before it finds it. I see the serial terminal disconnecting automatically when I attempt to update the program but it's not working out for me. I'm running version 0.18.4 on Ubuntu 9.04. I'm not overly familiar with how the USB ports work on Ubuntu and I see many other items named with usb in /dev besides the /dev/ttyUSB0 being used by the tool. Should I choose one of them, and if so - how do I choose which one?
No. /dev/ttyUSBx is your Propeller port. I'm not quite sure why it's doing what it's doing, and I certainly can't reproduce it here.
Can you try something for me?
Before you try to download the propeller, while the serial terminal is connected, can you reset the prop from the serial terminal? I think it's in the connect menu.
Then leave the terminal connected and try to download the prop.
The other thing is, does your program spew a lot of data into the serial terminal continuously? Ale picked up a problem a while ago where the prop would not be detected properly if the prop was sending a lot of data fast, right up to the point it was reset. This was an issue with the way I cleared the serial buffer and I thought I had it nailed.
I've made some changes to the way the serial port handler works recently, so if none of that has any result I'll see if I can get it cleaned up enough to release a -pre and see if that solves the problem.
All my testing is on Ubuntu 8.04 here, and the Linpus distro that comes on the Acer Aspire One. I doubt anything has changed in the TTY layer between the 2.6.24 kernel in 8.04 and the 2.6.27 kernel in 9.04, but I'll compile one up to test anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Thanks for the suggestion. Resetting the propeller from the serial terminal window allows the programming to proceed normally on the first try. This is much better.
Here is some additional info I noticed during testing. If I don't do a reset from the terminal window, the program apparently starts to download (I see the window with the circular dots momentarily), and then my prop resets and the old program already stored in EEPROM begins again. This is accompanied by the window that says it can't find the prop. Hope this helps, let me know if you want me to try anything else. The amount of output to the serial terminal didn't seem to affect the results, I tried it both ways.
In version 0.18.3 or earlier the list of extensions to show was "*.spin" and so on. It had also a "*.*" that of course showed all files. The new "all" by 0.18.4 does not show all files. I'm using bst to edit some M68K assembly files so it is very handy to have them in the list, could you revert to show them all ?
Thanks !
ps: The serial terminal works pefectly, I forgot to say.
Brad: I have just realised I have 2 versions of bst on my pc. One is 0.18.4 which has the 0.15.3 compiler and works fine. The other is 0.18pre6 which has 0.015pre5 compiler and fails to compile. It is something to do with the #defines passing into child objects. BTW I am on Vista :-(
I have just posted the code that does this on the TriBlade thread if you want to check it out.
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Brad: I have just realised I have 2 versions of bst on my pc. One is 0.18.4 which has the 0.15.3 compiler and works fine. The other is 0.18pre6 which has 0.015pre5 compiler and fails to compile. It is something to do with the #defines passing into child objects. BTW I am on Vista :-(
Which one fails to compile? 0.18.4 is the latest released version. 0.18-pre6 is an old pre-release version.
I've just got my hands on a Vista machine today so I can try and track down the bug you have where it's not detecting the propeller. I'm not holding out a lot of hope, but we'll see if I can make it play up. I wonder if its related to you using a really high port number (COM13?). I'm not sure how I can reproduce that here.
@Ale, Sure I'll make that change for the next fix-release for you.
@Greg Norton, I'm stumped. I can't reproduce that failure. Can you try using bstc or bstl for me from the command line to see if you get the same behaviour (not detecting consecutively?). I'm not quite sure where to go next with debugging it. I'll have a think about it. If you can reproduce it with bstc or bstl I might be able to send you some small test programs as I try out various things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Thanks Brad. I will delete the old version 0.18pre6. When I get my hardware I will retry the serial as maybe I was using the pre6. I will also give bstl a try.
PS: I wish I was on XP, but that is what came with this laptop. My other laptop isn't allowed near development stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
In another thread it was asked to use some align method for HUB memory. The following statement does not compile, it gives an operator missing error. It seems the @ or @@@ operators cannot be used more than once:
I can't reproduce this with 0.15.3 (which is the latest compiler on the web site.
Pub DUMMY
DAT
data long $FAFEFB[noparse][[/noparse]23]
byte $DE,$AD,$BE
label1 long 0[noparse][[/noparse](((@label1 + 31) >> 5) << 5) - @label1]
label2 long 0[noparse][[/noparse](((@label2 + 31) >> 5) << 5) - @@@label2]
label3 long 0[noparse][[/noparse](((@@@label3 + 31) >> 5) << 5) - @@@label3]
byte $55,$AA
bstc.linux -ls test.spin
|===========================================================================|
Object DAT Blocks
|===========================================================================|
0018(0000) FB FE FA 00 | data long $FAFEFB[noparse][[/noparse]23]
0074(0017) DE | byte $DE,$AD,$BE
0075(0017) AD |
0076(0017) BE |
0078(0018) 00 00 00 00 | label1 long 0[noparse][[/noparse](((@label1 + 31) >> 5) << 5) - @label1]
00D8(0030) 00 00 00 00 | label2 long 0[noparse][[/noparse](((@label2 + 31) >> 5) << 5) - @@@label2]
00F8(0038) 00 00 00 00 | label3 long 0[noparse][[/noparse](((@@@label3 + 31) >> 5) << 5) - @@@label3]
0118(0040) 55 | byte $55,$AA
0119(0040) AA |
|===========================================================================|
Can you attach a file that won't compile for me?
I've tried all sorts of combinations of your original source lines, plus the ones I've listed above to allow me to compile them all together. I'm stumped.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
if you add two longs before that last statement it does not give error anymore.
For certain alignments your equation is flawed.
Lets say @a32 is $131C which makes @@@a32 equal to $132C if its in the top object
$131C + 31 == $133B
$133B >> 5 == $99
$99 << 5 == $1320
$1320 - $132C == -$C which means you are trying to allocate about 4 Gig of ram. The poor little propeller is going to burst a seam!
As for the hang. There was a bug earlier where the compiler would spin for very long periods of time trying to allocate erroneous amounts of memory, but I thought I had that fixed by the 0.18 bst release. It certainly comes back instantly here and tells me the object exceeds 32k. I'll look into it a bit further and see when I fixed that bug and if there might be another one hiding somewhere.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Comments
Brad,
My OS is Linux, the propeller is detected automatically when I use F7. I've tried both setting the port by hand and using the auto function.
I think I may have narrowed the bug down for you:
My prop is on ttyUSB2 and bst is set to use such, however, on the "bst Binary Download" dialog when I click 'EEPROM' the box that pops up with the progress bar states that it is using ttyUSB1 (the error message that appears next states that it can't find the prop on ttyUSB2), looks like a value isn't getting passed or retrieved correctly for the port to use in this case?
Russ.
I downloaded the latest yesterday and was using that.(0.18.4)
I did what you said: Geometry=0,0,1096,1077,270,224,902
The error pain goes away as expected when I fix the error and F10.
Thanks,
Doug
If you edit that line (use vi or gedit or something like that)
Geometry=0,0,1096,1077,270,224,150
that should solve the problem. I'll try and figure out what may have caused that to happen and make sure
there is some sanity checking in the next version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
If you don't like windows so much(neither do I), why didn't you name the settings file .bstrc instead of .bst.ini?
Doug
The fact that you can select different ports for multiple props is great, it's just that in the CONFIGURE PORTS dialog there is nothing that basically says APPLY or OK. If I find a suitable port I can TEST ok but whatever I do after that I have to click CLOSE WINDOW and then none of the settings are applied. This perhaps is the most frustrating part of using what otherwise is a truly excellent IDE (still is). Keep up the good work, now that we are hooked on BST, you're our dealer and we need you.
*Peter*
There is a window pane adjuster (technically called a splitter), which is why I'm puzzled you could not get it to resize. Just click and drag the bar between the editor and the error box..
I kept it to .ini as it uses the old Windows .ini format. It's the same on OSX and Linux. On Win32 I shoved all the settings in the registry as it was just as easy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
That is most odd. When I back out of the config dialog (I did it that way so the UI experience is the same across all OS) it sets the port correctly. Whatever port is in the port name box at the bottom is the one that is supposed to stick when you close the box. I'll have a look to see if I broke something.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
I've been using the latest version of your bstc and the wonderful list file it generates. I noticed a few odd things:
1. Assigned return symbols always get translated to the "Result" symbol.
2. A "repeat" statement with no follow-on code appears to translate into a non functional reference only repeat of the previous statement.
Any ideas on what could be done on these examples?
I would share the example publicly, but I would like to keep it secret for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This one produces correct code, and also lists it properly in the list file, it simply omits the repeat source line. I'll look into that, but I can see the correct code generated in the list file and I can guarantee it works.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Yes, item 2 functions correctly, but I was expecting to see a source list line generated for the repeat statement. A spin debugger relying on the source list will never point to the "empty" repeat without an ugly hack. Item 1 is cosmetic, but could easily confuse the user of a symbolic spin debugger especially when no hover balloon value pops up. The bstc and propeller tool generated binaries are identical.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 8/1/2009 3:20:35 PM GMT
It is an awkward one really as when you look into the bytecode, the code generated for the repeat statement actually occurs *after* the code it's repeating.
That particular repeat construct is a simple jump. I'm not actually sure of the best way to handle it from that perspective.
Also, if you are looking at using the listing for stepping a debugger you may find "challenges" surrounding the way it generates output for case constructs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
When I looked at it (admittedly a while ago now) homespun seemed to use a syntax similar to the one hippy developed while he was reverse engineering the spin bytecodes (prior to the release of the interpreter).
Prior to writing the compiler I wrote a spin bytecode disassembler to help me figure out how the parallax compiler did what it did. I used a combination of naming from the interpreter source ("drop anchor" for example) and what seemed to make sense to me. It's probably harder for a machine to parse, but I find it much more readable when I'm reading a disassembled file. I simply plugged the disassembler into the compiler to generate the list file on the fly.
I'd be happy to make changes if it would help.
Admittedly I use the list file window in bst all the time. It really helps when you are optimising spin code for size/speed to understand precisely what bytecode is being used for what and being able to see how many bytes each construct takes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
@Brad & @Jeff: FONTS I am using Vista. The fonts did not work correctly (put spaces between characters so not doing UTF16 correctly). There was no Parallax.ttf in the font directory. I was using PropTool 1.2 so I downloaded PropTool 1.2.6 and installed it. Now I have Parallax.ttf in my font directory. So I ran bst and voila - I have the fonts working correctly
The code is quite a bit larger than homespun024's output (4290/2664/1234 vs 3260/2664/2264) so I presume I should now turn on some of the compiler options to shrink unused code?? I cannot compile under PropTool, so no comparisons available.
Now for the problem... I cannot locate the prop. PropTool works ok, PropTerminal works ok, but bst refuses to find the prop. I have downloaded the binary from bst to my board and that is great. Any ideas??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
That one is in the release notes. For some reason the earlier versions of the Propeller Tool installed the font in such a fashion as it was only accessible to the Propeller Tool under Vista.
That is most odd. Aside from STRING( ) allocation and the LSB on floating point, bst and homespun generate pretty much identical code provided the optimisations in bst are turned off.
If you can give me a code archive including homespun and a defined way to reproduce the binaries I can do a bindiff on them and find out what I'm doing wrong. I didn't think homespun did anything to optimise the code or remove unused portions, but then I've not looked at it since about version 17.
Not sure really. I did briefly test on Vista prior to the last release. I gather the Propeller Tool detects the prop ok then?
Are you using a standard Prop Plug?
Have you tried to manually set the prop port? (IDE Preferences -> Port allocation)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I saw the things to do about the fonts but thought I would post what I found
I will email the code to you.
PropTool finds and detects the prop ok, as does PropTerminal. bst finds the com port (com13) but does not find the prop. The test gives a message no prop found. I am using the PropPlug circuit that I built on the TriBlade pcb. Yes I tried to set the port manually but no go. :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I have two things I would like to ask about.
First - when using your tool to compile the attached file, BST gives me an error at line 1, column 1 that says "Expected End of Line, Unary Operator or Math Operator". Using the Parallax tool I found the problem to be in score_char where I wrote:
rather than
Second - I find myself having to disconnect the serial terminal manually before programming the Propeller. If I fail to do so the tool will say it can't find the Propeller. Even when I do, it takes two tries before it finds it. I see the serial terminal disconnecting automatically when I attempt to update the program but it's not working out for me. I'm running version 0.18.4 on Ubuntu 9.04. I'm not overly familiar with how the USB ports work on Ubuntu and I see many other items named with usb in /dev besides the /dev/ttyUSB0 being used by the tool. Should I choose one of them, and if so - how do I choose which one?
Many thanks for such a great tool!
Greg
Thanks for the example. It makes it dead easy to reproduce here. I'll get that sorted as soon as I can. There are a few of those little bugs lurking around in there still. At least it didn't crash [noparse]:)[/noparse]
No. /dev/ttyUSBx is your Propeller port. I'm not quite sure why it's doing what it's doing, and I certainly can't reproduce it here.
Can you try something for me?
Before you try to download the propeller, while the serial terminal is connected, can you reset the prop from the serial terminal? I think it's in the connect menu.
Then leave the terminal connected and try to download the prop.
The other thing is, does your program spew a lot of data into the serial terminal continuously? Ale picked up a problem a while ago where the prop would not be detected properly if the prop was sending a lot of data fast, right up to the point it was reset. This was an issue with the way I cleared the serial buffer and I thought I had it nailed.
I've made some changes to the way the serial port handler works recently, so if none of that has any result I'll see if I can get it cleaned up enough to release a -pre and see if that solves the problem.
All my testing is on Ubuntu 8.04 here, and the Linpus distro that comes on the Acer Aspire One. I doubt anything has changed in the TTY layer between the 2.6.24 kernel in 8.04 and the 2.6.27 kernel in 9.04, but I'll compile one up to test anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Thanks for the suggestion. Resetting the propeller from the serial terminal window allows the programming to proceed normally on the first try. This is much better.
Here is some additional info I noticed during testing. If I don't do a reset from the terminal window, the program apparently starts to download (I see the window with the circular dots momentarily), and then my prop resets and the old program already stored in EEPROM begins again. This is accompanied by the window that says it can't find the prop. Hope this helps, let me know if you want me to try anything else. The amount of output to the serial terminal didn't seem to affect the results, I tried it both ways.
Greg
In version 0.18.3 or earlier the list of extensions to show was "*.spin" and so on. It had also a "*.*" that of course showed all files. The new "all" by 0.18.4 does not show all files. I'm using bst to edit some M68K assembly files so it is very handy to have them in the list, could you revert to show them all ?
Thanks !
ps: The serial terminal works pefectly, I forgot to say.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 have just posted the code that does this on the TriBlade thread if you want to check it out.
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Which one fails to compile? 0.18.4 is the latest released version. 0.18-pre6 is an old pre-release version.
I've just got my hands on a Vista machine today so I can try and track down the bug you have where it's not detecting the propeller. I'm not holding out a lot of hope, but we'll see if I can make it play up. I wonder if its related to you using a really high port number (COM13?). I'm not sure how I can reproduce that here.
@Ale, Sure I'll make that change for the next fix-release for you.
@Greg Norton, I'm stumped. I can't reproduce that failure. Can you try using bstc or bstl for me from the command line to see if you get the same behaviour (not detecting consecutively?). I'm not quite sure where to go next with debugging it. I'll have a think about it. If you can reproduce it with bstc or bstl I might be able to send you some small test programs as I try out various things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
PS: I wish I was on XP, but that is what came with this laptop. My other laptop isn't allowed near development stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
This one hangs the compiler (I did not test the other way round first @@@ and then @):
And this does not compile, too:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Pub DUMMY DAT data long $FAFEFB[noparse][[/noparse]23] byte $DE,$AD,$BE label1 long 0[noparse][[/noparse](((@label1 + 31) >> 5) << 5) - @label1] label2 long 0[noparse][[/noparse](((@label2 + 31) >> 5) << 5) - @@@label2] label3 long 0[noparse][[/noparse](((@@@label3 + 31) >> 5) << 5) - @@@label3] byte $55,$AAbstc.linux -ls test.spin
Can you attach a file that won't compile for me?
I've tried all sorts of combinations of your original source lines, plus the ones I've listed above to allow me to compile them all together. I'm stumped.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
this code definitely hangs bst: After a while an error shows: size of object exceeds available memory and the bst process 100% of cpu:
if you add two longs before that last statement it does not give error anymore.
(Note: I used it at the end of some large object, the lcdterminal.spi I published in the wiki, download it here)
I'll see what syntax did I use at home (may be I did a syntax error, that would be shameful!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 certain alignments your equation is flawed.
Lets say @a32 is $131C which makes @@@a32 equal to $132C if its in the top object
$131C + 31 == $133B
$133B >> 5 == $99
$99 << 5 == $1320
$1320 - $132C == -$C which means you are trying to allocate about 4 Gig of ram. The poor little propeller is going to burst a seam!
If you add your 2 longs in there
@a32 = $1324 : @@@a32 = $1334
$1324+31 == $1343
$1343 >> 5 == $9A
$9A << 5 == $1340
$1340 - $1334 == $C
As for the hang. There was a bug earlier where the compiler would spin for very long periods of time trying to allocate erroneous amounts of memory, but I thought I had that fixed by the 0.18 bst release. It certainly comes back instantly here and tells me the object exceeds 32k. I'll look into it a bit further and see when I fixed that bug and if there might be another one hiding somewhere.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Post Edited (BradC) : 8/26/2009 8:31:10 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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