Attached is the copy of Gridrunner that is failing here..
Ok, I have to add _demo to the object name for the sound driver in the main Gridrunner object for it to compile, otherwise it just errors out unable to find the sound driver.
Do you have a copy of NS_sound_drv_052_22khz_16bit lurking in your searchpath somewhere or ..
.. are you renaming the dummy driver ? or ..
.. are you editing the main object to add _dummy to the object name?
I've tried a straight compile(F8) and also loading a prop (ctrl+F10).
Which files do you have open in the IDE when you try it? (I tried it with just BAM_GridRunner_16.spin and then with all the files)
Odd that the ctest works for you (not bad, just odd) seeing as sometimes you have detection problems in the IDE. I'll keep looking at that.
The file I'm using is still tagged "dummy" as in the dummy (me) who didn't check the code
to make sure that it was set to load that from the code.
Strangely when the file isn't found it doesn't just stop with an file not found message after
searching the compiler paths. I even removed the ton of stuff (1.5gig) that was in a folder
off the one BST is loaded in. Memory goes straight up, CPU up, and swap until I finally force
a kill on the application. Could the compiler be searching somewhere it isn't being told to
to find the missing file?
Yes, I always save before compiling unless there is an auto-save...
It's not your tool in particular, pretty much any tool I'm using...
So here is a new request, auto-save before compile...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
BradC said...
Ubuntu? Grab the font from the link in the Wiki and put it in
~/.fonts
I'll have to warn you, I am still learning Linux. Could you explain where "~/.fonts" is ? I extracted your executable right onto my desktop. So if you mean to say put in in a subfolder of the folder that contains the executable,.... I really have to learn some Linux skills so I can navigate and organize my stuff better!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian
uController.com - home of SpinStudio - the modular Development system for the Propeller
PropNIC - Add ethernet ability to your Propeller! PropJoy - Plug in a joystick and play some games!
I was wondering if some of the detection problems that people have seen could be due to serial activity. For example take the lab HelloFullDuplexSerial.spin from the PE-Lab-Objects-v1.1 file. If you compile and download to RAM, can you then compile and download to RAM again with 100% repeatability? What if you compile and program and load EEPROM?
Since I'm running on OS X I did make one minor adjustment to this example which was to add a linefeed to the debug string. Also I'm trying this on a demo board.
I just did a quick experiment and got 3 out of 28 runs with problems.
Also I have the FTDI Serial Drivers (FTDIUSBSerialDriver_v2_2_10.dmg) from http://www.ftdichip.com/Drivers/VCP.htm installed if this makes any difference. I assume that everyone running OS X has done this. Is this a good assumption?
ale@orgpc043:~/prg/projects/parallax$ cd /
ale@orgpc043:/$ cd ~
ale@orgpc043:~$ pwd
/home/ale
ale@orgpc043:~$
As you see I was already in /home/ale/parallax and changed to root (/). Then I changed to home (~). As you guessed my user is ale.
To answer your question: ~/.fonts is a directory in your home directory, a hidden directory because it starts with a dot.
ale@orgpc043:~$ cd .fonts
bash: cd: .fonts: No such file or directory
ale@orgpc043:~$ mkdir .fonts
ale@orgpc043:~$ cd .fonts
ale@orgpc043:~/.fonts$ pwd
/home/ale/.fonts
ale@orgpc043:~/.fonts$
I created it (mkdir) because it did not exist.
If you ever used Norton Commander, I recommend you install the mc-4.6 package (using synaptic), is everything nc was but better in every regard, and it is called mc: the Midnight Commander !
J. A. Streich said...
All I get is a seg fault on a new Eee PC. No error, no core dump.
Would you be interested in downloading/running a debug build or two? They are usually about 20M and unzip to about 45M.
PM me if you are interested anyway and I'll see about getting some knocked out for you.
Oldbitcollector said...
Could the compiler be searching somewhere it isn't being told to
to find the missing file?
OBC
Shouldn't be. It searches in the directory the file is in, then it searches in the searchpaths.
Unless you have something like / in your searchpath it should not do that.
Care to pm me the contents of your ~/.bst.ini so I can have a look?
I just did a quick experiment and got 3 out of 28 runs with problems.
Also I have the FTDI Serial Drivers (FTDIUSBSerialDriver_v2_2_10.dmg) from http://www.ftdichip.com/Drivers/VCP.htm installed if this makes any difference. I assume that everyone running OS X has done this. Is this a good assumption?
-Keith
My problem with OSX is syscalls are incredibly expensive. By this I mean doing an open on a serial port in linux takes about .01 Milliseconds.
On OSX it can take anywhere between 5 and 20 milliseconds. This makes it very hard to accurately time the delays required to detect the propeller in a flexible manner.
When I get home next week and have access to my Mac hardware again, I'll look at what I can do to increase the reliability of detection.
I had to install the OSX VCP drivers to make it work on my macs.. so you are pretty much in the same boat as everyone else I believe.
BradC said...
My problem with OSX is syscalls are incredibly expensive. By this I mean doing an open on a serial port in linux takes about .01 Milliseconds.
On OSX it can take anywhere between 5 and 20 milliseconds. This makes it very hard to accurately time the delays required to detect the propeller in a flexible manner.
I didn't notice this before when I was loading programs that weren't transmitting serial data, so I thought that it might be related to the use of the serial port. But I also didn't conduct as many runs.
If you can build an OS X version of the "test" program that connects and disconnects in a loop I could try that and report more meaningful statistics.
If you can build an OS X version of the "test" program that connects and disconnects in a loop I could try that and report more meaningful statistics.
FYI - I'm running on an Intel based Macbook.
Good thinking. I've attached an Intel only version compiled for OSX.
Now, I'm away from my macs and I can't even test to see if it runs, so don't be too disappointed if it does not even run. I've compiled it but I can't test it.
The first time I first loaded SingingDemoSeven.spin into eeprom before running ctest, and ctest did not report any problems.
$ ./ctest.intel
Found a USB Serial Device
0 Failures
The next time I loaded the unmodified HelloFullDuplexSerial.spin from PE-Lab-Objects-v1.1 into RAM before running ctest, and I think that it failed every iteration after this.
$ ./ctest.intel
Found a USB Serial Device
1 Failures
2 Failures
...
115 Failures
116 Failures
117 Failures
118 Failures
119 Failures
It stopped printing the failures at this point, and did not print out the iteration count before terminating.
After terminating the propeller was apparently reset since it started singing and a subsequent test worked well, although I did not allow it to run to completion.
So I think that it's worth looking into the usage of the serial port pins by the propeller. I'm not sure about everything that's going on behind the scenes, and what can be done.
A very minor IDE detail. If you have a modified file, and try to quit the IDE will bring up a dialog box asking you is you want to save changes, discard, or cancel. The cancel button does not about the quit, instead the dialog is redisplayed. This is for BST Version 0.04, compiler version 0.05.
The attached gives me "List Index (1) out of bounds"
It's a stripped copy of Graphics Demo to act as a simple Etch'aSketch when the mouse button is pressed.
The attached gives me "List Index (1) out of bounds"
It's a stripped copy of Graphics Demo to act as a simple Etch'aSketch when the mouse button is pressed.
OBC
Cheers OBC. Fixed in the next version [noparse]:)[/noparse]
<edit> Should have said the crash was in the circular object reference detection.
You have a file called mouse.spin and it's looking for a sub-object mouse.
Oldbitcollector said...
Heh.. Told you I can break anything.. [noparse]:)[/noparse]
Curious how the syntax highlighting is coming along?
OBC
It's a long way off at the moment. I've started the syntax tokeniser, but got distracted with bug fixes, search/replace, serial debug terminal and a whole host of little niggling things.
I'm trying to find out why the menu shortcut keys are not working on Linux at the moment. Unfortunately it's a bug in the tools I'm using, so I'm kinda head down in there trying to get that sorted. They work perfectly for OSX and Win32.. (well, except the Mac ones are still mapped to Linux keystrokes, but I am working on making them Mac native).
I could very quickly put some generic syntax highlighting in place, but I decided if the Parallax highlighter is so good then I was not going to do it unless I did it right.
I personally wish that you would concentrate on bstc and leave the MacOSX IDE sit for a while... maybe someone will jump in and finish it.
I would like to see more robust reporting back from the compiler...[noparse]:)[/noparse]
What does the compiler not report that you might require?
I'm certainly not adverse to making additions to the compiler provided it mostly retains compatibility with the Parallax compiler.
Whilst I do maintain and enhance the compiler, I wanted an IDE along the lines of Propeller Tool so that ..
A) it was literally a point & click solution, no scripting no deps, no configuration or farting about with other tools. Just download and go. it was a close match to the existing Parallax interface to make it easy for newbies to follow the documentations
C) I can use it myself for all my development. I _like_ the proptool interface.
D) I can have the same interface whether I'm on Linux, Mac or Windows (or solaris & bsd at some point in the future)
I don't _want_ to have to download other tools and configure things with scripts. I want perfection out of the box.
It's not for everybody, but I'm enjoying writing it, and I enjoy using it (and if something niggles me I fix it).
If others find it handy, that's a nice bonus [noparse]:)[/noparse]
The next version is still a couple of days away, but it's got a load of annoyances fixed and a few extra features.
If you build it... they will come. It sounds like a herculean task.
As to reporting... I don't want to slow you down, but if you run into a brick wall, you might want to consider including a verbose report option in the compiler, which can report the equivalent of the contents of each panel on the Parallax IDE....
I have a feeling that you already have, but I just don't know how to use it.
I am glad you are enjoying the process. We are enjoying too[noparse]:)[/noparse]
If you build it... they will come. It sounds like a herculean task.
It's keeping me a bit busy..
When I can figure out how to get paid for doing this stuff full time I'll be doing cartwheels [noparse]:)[/noparse]
rjo_ said...
As to reporting... I don't want to slow you down, but if you run into a brick wall, you might want to consider including a verbose report option in the compiler, which can report the equivalent of the contents of each panel on the Parallax IDE....
I'm not entirely sure what you mean here. Which panels are we talking about? What information do you really want to see from the command line compiler?
I'd figured that errors, warnings and information (which are not quite finished) are probably all that you get from compilers generally, so it's all I did.
After I posted the comment about reporting... I wished I hadn't. Basically, I would like to have access to all information... memory map...statistics etc that are available out of the Prop Tool... but on a demand basis (compiler option) from bstc, in raw form that I parse myself.
That's asking for a lot... and I don't want you to say "no."
So, one or two things at a time sounds more reasonable.
When I compile to EEPROM in bstc... I get back a nice summary of the process... including that a USB port was found.
Knowing which driver is being used would be useful. if there is a way to find this through the Mac terminal without having to put it into the code for bstc, that would be even better.
As to making money ... you already are, but it is not in the form of cash that we all prefer. One of the reasons our economy is in the drink is that too few people know the difference between money, cash and capital... or where it comes from.
You are making lots of money these days... it is just a matter of turning it into cash.
One of the guys over at the Propeller outpost of mibbit got all over me for suggesting that you get to the point of charging for your product as soon as possible... many are students others have too many other things they have to pay for... kids, cars, first wives... There should always be a way for students and a back door that our friends can use to steal from you... it is a tradition. At the same time, you need to get over the "for free" phase of software development as fast as you can. IF you want everyone to have your stuff and you really don't want to charge for it... then you need to start a web page and charge an advertising fee...who knows, there might be some fairly wealthy guys willing to help you out by paying an outrageous amount in exchange for a link on your site. I'm not one of them... so if you build a website and they don't come... it was just a thought.
I would also like a place to put my scripting mods got bstc in such a way that it contributes to your well being... so, if you start a site...leave open the possibility of user input.
I was hoping that some other users might try some experiments loading different kinds of programs to see if they could duplicate my results. Here's a simple example. Take HelloFullDuplex.spin for example.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
Debug: "FullDuplexSerial"
PUB TestMessages
''Send test messages and to Parallax Serial Terminal.
Debug.start(31, 30, 0, 57600)
repeat
Debug.str(string("This is a test message!", 13))
waitcnt(clkfreq + cnt)
If I change the following line, it impacts my ability to download:
Debug.start(31, 30, 0, 57600)
All I need to do is change the pin numbers to avoid the use of pins 30 and 31.
If I compile and download with bstc, then I can get zero failures when the pins are changed to 0 and 1, and roughly 10% failures when the pins are left as 30 and 31. I simple pipe the output of bstc into a logfile, and then grep for failures after the fact. I give a 2 second gap between compiles to let the propeller program execute for a while. If I remove the delay then the failure rate decreases.
KeithE said...
I
All I need to do is change the pin numbers to avoid the use of pins 30 and 31.
If I compile and download with bstc, then I can get zero failures when the pins are changed to 0 and 1, and roughly 10% failures when the pins are left as 30 and 31. I simple pipe the output of bstc into a logfile, and then grep for failures after the fact. I give a 2 second gap between compiles to let the propeller program execute for a while. If I remove the delay then the failure rate decreases.
Whoooo. Thanks KeithE, that has given me the leg up I needed to track the problem down. Hopefully the next version of bst & bstc should see significantly improved detection.
@evanh, you were very close with the flush bit.. Will keep you posted.
Comments
Attached is the copy of Gridrunner that is failing here..
Also, ran ctest and got 0 Failures. I will run it a couple more times to confirm.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Ok, I have to add _demo to the object name for the sound driver in the main Gridrunner object for it to compile, otherwise it just errors out unable to find the sound driver.
Do you have a copy of NS_sound_drv_052_22khz_16bit lurking in your searchpath somewhere or ..
.. are you renaming the dummy driver ? or ..
.. are you editing the main object to add _dummy to the object name?
I've tried a straight compile(F8) and also loading a prop (ctrl+F10).
Which files do you have open in the IDE when you try it? (I tried it with just BAM_GridRunner_16.spin and then with all the files)
Odd that the ctest works for you (not bad, just odd) seeing as sometimes you have detection problems in the IDE. I'll keep looking at that.
Thanks for the feedback. The bug hunting begins!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
The file I'm using is still tagged "dummy" as in the dummy (me) who didn't check the code
to make sure that it was set to load that from the code.
Strangely when the file isn't found it doesn't just stop with an file not found message after
searching the compiler paths. I even removed the ton of stuff (1.5gig) that was in a folder
off the one BST is loaded in. Memory goes straight up, CPU up, and swap until I finally force
a kill on the application. Could the compiler be searching somewhere it isn't being told to
to find the missing file?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Post Edited (Oldbitcollector) : 10/14/2008 1:59:18 AM GMT
It's not your tool in particular, pretty much any tool I'm using...
So here is a new request, auto-save before compile...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse
I'll have to warn you, I am still learning Linux. Could you explain where "~/.fonts" is ? I extracted your executable right onto my desktop. So if you mean to say put in in a subfolder of the folder that contains the executable,.... I really have to learn some Linux skills so I can navigate and organize my stuff better!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian
uController.com - home of SpinStudio - the modular Development system for the Propeller
PropNIC - Add ethernet ability to your Propeller! PropJoy - Plug in a joystick and play some games!
SD card Adapter - mass storage for the masses Audio/Video adapter add composite video and sound to your Proto Board
Since I'm running on OS X I did make one minor adjustment to this example which was to add a linefeed to the debug string. Also I'm trying this on a demo board.
I just did a quick experiment and got 3 out of 28 runs with problems.
Also I have the FTDI Serial Drivers (FTDIUSBSerialDriver_v2_2_10.dmg) from http://www.ftdichip.com/Drivers/VCP.htm installed if this makes any difference. I assume that everyone running OS X has done this. Is this a good assumption?
-Keith
'~' means always your home directory.
You can simplay type:
cd ~
and it will change to your home. Look:
ale@orgpc043:~/prg/projects/parallax$ cd /
ale@orgpc043:/$ cd ~
ale@orgpc043:~$ pwd
/home/ale
ale@orgpc043:~$
As you see I was already in /home/ale/parallax and changed to root (/). Then I changed to home (~). As you guessed my user is ale.
To answer your question: ~/.fonts is a directory in your home directory, a hidden directory because it starts with a dot.
ale@orgpc043:~$ cd .fonts
bash: cd: .fonts: No such file or directory
ale@orgpc043:~$ mkdir .fonts
ale@orgpc043:~$ cd .fonts
ale@orgpc043:~/.fonts$ pwd
/home/ale/.fonts
ale@orgpc043:~/.fonts$
I created it (mkdir) because it did not exist.
If you ever used Norton Commander, I recommend you install the mc-4.6 package (using synaptic), is everything nc was but better in every regard, and it is called mc: the Midnight Commander !
Post Edited (Ale) : 10/14/2008 7:02:39 AM GMT
Case sensitive too.
Would you be interested in downloading/running a debug build or two? They are usually about 20M and unzip to about 45M.
PM me if you are interested anyway and I'll see about getting some knocked out for you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Shouldn't be. It searches in the directory the file is in, then it searches in the searchpaths.
Unless you have something like / in your searchpath it should not do that.
Care to pm me the contents of your ~/.bst.ini so I can have a look?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
My problem with OSX is syscalls are incredibly expensive. By this I mean doing an open on a serial port in linux takes about .01 Milliseconds.
On OSX it can take anywhere between 5 and 20 milliseconds. This makes it very hard to accurately time the delays required to detect the propeller in a flexible manner.
When I get home next week and have access to my Mac hardware again, I'll look at what I can do to increase the reliability of detection.
I had to install the OSX VCP drivers to make it work on my macs.. so you are pretty much in the same boat as everyone else I believe.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I didn't notice this before when I was loading programs that weren't transmitting serial data, so I thought that it might be related to the use of the serial port. But I also didn't conduct as many runs.
If you can build an OS X version of the "test" program that connects and disconnects in a loop I could try that and report more meaningful statistics.
FYI - I'm running on an Intel based Macbook.
Good thinking. I've attached an Intel only version compiled for OSX.
Now, I'm away from my macs and I can't even test to see if it runs, so don't be too disappointed if it does not even run. I've compiled it but I can't test it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
The first time I first loaded SingingDemoSeven.spin into eeprom before running ctest, and ctest did not report any problems.
$ ./ctest.intel
Found a USB Serial Device
0 Failures
The next time I loaded the unmodified HelloFullDuplexSerial.spin from PE-Lab-Objects-v1.1 into RAM before running ctest, and I think that it failed every iteration after this.
$ ./ctest.intel
Found a USB Serial Device
1 Failures
2 Failures
...
115 Failures
116 Failures
117 Failures
118 Failures
119 Failures
It stopped printing the failures at this point, and did not print out the iteration count before terminating.
After terminating the propeller was apparently reset since it started singing and a subsequent test worked well, although I did not allow it to run to completion.
So I think that it's worth looking into the usage of the serial port pins by the propeller. I'm not sure about everything that's going on behind the scenes, and what can be done.
A very minor IDE detail. If you have a modified file, and try to quit the IDE will bring up a dialog box asking you is you want to save changes, discard, or cancel. The cancel button does not about the quit, instead the dialog is redisplayed. This is for BST Version 0.04, compiler version 0.05.
-Keith
your instructions were clear, concise and best of all.....It worked.
my font problem is fixed, it's so much more usable now. This is a great tool!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian
uController.com - home of SpinStudio - the modular Development system for the Propeller
PropNIC - Add ethernet ability to your Propeller! PropJoy - Plug in a joystick and play some games!
SD card Adapter - mass storage for the masses Audio/Video adapter add composite video and sound to your Proto Board
The attached gives me "List Index (1) out of bounds"
It's a stripped copy of Graphics Demo to act as a simple Etch'aSketch when the mouse button is pressed.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Cheers OBC. Fixed in the next version [noparse]:)[/noparse]
<edit> Should have said the crash was in the circular object reference detection.
You have a file called mouse.spin and it's looking for a sub-object mouse.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (BradC) : 10/15/2008 11:49:53 PM GMT
Curious how the syntax highlighting is coming along?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
It's a long way off at the moment. I've started the syntax tokeniser, but got distracted with bug fixes, search/replace, serial debug terminal and a whole host of little niggling things.
I'm trying to find out why the menu shortcut keys are not working on Linux at the moment. Unfortunately it's a bug in the tools I'm using, so I'm kinda head down in there trying to get that sorted. They work perfectly for OSX and Win32.. (well, except the Mac ones are still mapped to Linux keystrokes, but I am working on making them Mac native).
I could very quickly put some generic syntax highlighting in place, but I decided if the Parallax highlighter is so good then I was not going to do it unless I did it right.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I put together a scriptable prototype MacOSX user interface for bstc...
What is interesting is that when I call bstc out of this interface, there are no failures to detect the Prop...
I am not doing anything to make this happen... it just does[noparse]:)[/noparse]
I tried to include the project... which started out as the TextEditPlus 2 example in ApplesScript Studio, but it is over the size max for the forum.
If there is any interest, I will break the project into pieces and post it. It is really simple...no need to beat your head against the wall.
I personally wish that you would concentrate on bstc and leave the MacOSX IDE sit for a while... maybe someone will jump in and finish it.
I would like to see more robust reporting back from the compiler...[noparse]:)[/noparse]
Love your work.
Rich
there are four files in this sample... they all have to be in the same directory.
What does the compiler not report that you might require?
I'm certainly not adverse to making additions to the compiler provided it mostly retains compatibility with the Parallax compiler.
Whilst I do maintain and enhance the compiler, I wanted an IDE along the lines of Propeller Tool so that ..
A) it was literally a point & click solution, no scripting no deps, no configuration or farting about with other tools. Just download and go.
C) I can use it myself for all my development. I _like_ the proptool interface.
D) I can have the same interface whether I'm on Linux, Mac or Windows (or solaris & bsd at some point in the future)
I don't _want_ to have to download other tools and configure things with scripts. I want perfection out of the box.
It's not for everybody, but I'm enjoying writing it, and I enjoy using it (and if something niggles me I fix it).
If others find it handy, that's a nice bonus [noparse]:)[/noparse]
The next version is still a couple of days away, but it's got a load of annoyances fixed and a few extra features.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
If you build it... they will come. It sounds like a herculean task.
As to reporting... I don't want to slow you down, but if you run into a brick wall, you might want to consider including a verbose report option in the compiler, which can report the equivalent of the contents of each panel on the Parallax IDE....
I have a feeling that you already have, but I just don't know how to use it.
I am glad you are enjoying the process. We are enjoying too[noparse]:)[/noparse]
Rich
It's keeping me a bit busy..
When I can figure out how to get paid for doing this stuff full time I'll be doing cartwheels [noparse]:)[/noparse]
I'm not entirely sure what you mean here. Which panels are we talking about? What information do you really want to see from the command line compiler?
I'd figured that errors, warnings and information (which are not quite finished) are probably all that you get from compilers generally, so it's all I did.
Happy to add features to my todo list though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
That's asking for a lot... and I don't want you to say "no."
So, one or two things at a time sounds more reasonable.
When I compile to EEPROM in bstc... I get back a nice summary of the process... including that a USB port was found.
Knowing which driver is being used would be useful. if there is a way to find this through the Mac terminal without having to put it into the code for bstc, that would be even better.
As to making money ... you already are, but it is not in the form of cash that we all prefer. One of the reasons our economy is in the drink is that too few people know the difference between money, cash and capital... or where it comes from.
You are making lots of money these days... it is just a matter of turning it into cash.
One of the guys over at the Propeller outpost of mibbit got all over me for suggesting that you get to the point of charging for your product as soon as possible... many are students others have too many other things they have to pay for... kids, cars, first wives... There should always be a way for students and a back door that our friends can use to steal from you... it is a tradition. At the same time, you need to get over the "for free" phase of software development as fast as you can. IF you want everyone to have your stuff and you really don't want to charge for it... then you need to start a web page and charge an advertising fee...who knows, there might be some fairly wealthy guys willing to help you out by paying an outrageous amount in exchange for a link on your site. I'm not one of them... so if you build a website and they don't come... it was just a thought.
I would also like a place to put my scripting mods got bstc in such a way that it contributes to your well being... so, if you start a site...leave open the possibility of user input.
Regards,
Rich
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ Debug: "FullDuplexSerial" PUB TestMessages ''Send test messages and to Parallax Serial Terminal. Debug.start(31, 30, 0, 57600) repeat Debug.str(string("This is a test message!", 13)) waitcnt(clkfreq + cnt)If I change the following line, it impacts my ability to download:
All I need to do is change the pin numbers to avoid the use of pins 30 and 31.
If I compile and download with bstc, then I can get zero failures when the pins are changed to 0 and 1, and roughly 10% failures when the pins are left as 30 and 31. I simple pipe the output of bstc into a logfile, and then grep for failures after the fact. I give a 2 second gap between compiles to let the propeller program execute for a while. If I remove the delay then the failure rate decreases.
The basic command that I use is:
./bstc.osx -L PropTool-Spin-1 PE-Lab-Objects-v1.1/HelloFullDuplexSerial.spin -p0
The failures that I see are reported as follows:
"No Propeller detected on port /dev/tty.usbserial-A40023Ki"
I think that I've seen higher failure rates when using the IDE, and suspect that it was due to longer delays between downloads.
Whoooo. Thanks KeithE, that has given me the leg up I needed to track the problem down. Hopefully the next version of bst & bstc should see significantly improved detection.
@evanh, you were very close with the flush bit.. Will keep you posted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!