Its me again, V0.8 worked fine for me for sure. Loaded 2 different programs into my Activity board and my C3. Both boards program both to memory and EEprom. One interesting thing I noticed one program does use term to disp temp and humidity reading. First time it loaded to ram just fine. When I reprogrammed to rom the button on toolbar failed with no prop found as it does in proptool when the term is active. When I went into the debug pull down to burn it worked great. Did I miss how to stop term?
Dont have a quickstart to try and didnt try your new loader. Not sure now if I have a delay in my program or not, will check on that.
First time it loaded to ram just fine. When I reprogrammed to rom the button on toolbar failed with no prop found as it does in proptool when the term is active. When I went into the debug pull down to burn it worked great. Did I miss how to stop term?
Hmm. It should stop the terminal first.I suspect that the reset routine is still not flushing the port correctly. I remember seeing this on the propeller tool also. I'll make another p1load for you to try with this.
I just loaded v0.8 onto my Mac to run under Parallels.
I have a RevA QuickStart and a DNA board connected. I've been hopping back and forth loading and running the 2 boards and haven;t broken it yet or had a QS load failure yet (but those come and go at random).
Great. Here is a version for testing load of programs printing to the terminal without a delay.
Unzip the program to some folder and choose it for testing in Spin Properties.
Everyone please test by removing waitcnt before print to terminal when you can and report results. Please also test with RevA Quickstart if possible.
Jazzed,
Not running on Windows, but I did "hg pull" & "hg update loader" on Mac OS X and rebuilt. Did a "make" in the new /loader directory to build p1load binary. Set Properties/Loader to that binary. Mod'ed the "Hello Spin2" code to remove the waitcnt.
Ran "Debug" on Activity Board, Propeller DNA and QuickStart Rev A...
Got good results almost every time test was run. Did see an occasional mis-displaying "Hello Spin2" completely (see the screenshot).
For a second test, I plugged-in two of the boards at a time and did various unplug-replug tests in-between Debug runs. The app would hang momentarily when I unplugged a board, as you had seen this weekend, but always came back after about 5-7 seconds.
This version (if my updated code is the same as your compiled Win code) is looking good!
It captures serial input and echos it for a short time while serial input is available.
That's the best I can do under the circumstances. Apparently it is not reliable enough to keep. So we're back to a delay before printing while the IDE loader takes over the port.
The built-in loader is reliable for some people, but fails miserably for others. So, that is gone. I'm done with the P8x32a Propeller load protocol. Hopefully the next loader isn't so bad. Determinism sucks in this case at least.
It captures serial input and echos it for a short time while serial input is available.
That's the best I can do under the circumstances. Apparently it is not reliable enough to keep. So we're back to a delay before printing while the IDE loader takes over the port.
The built-in loader is reliable for some people, but fails miserably for others. So, that is gone. I'm done with the P8x32a Propeller load protocol. Hopefully the next loader isn't so bad. Determinism sucks in this case at least.
Do you want a loader library that uses the code in p1load so you can just link it with PropellerIDE? I still think that's the best solution to this. Then you don't have to close the serial port and run the risk of losing data. It's why propeller-load -t and p1load -t work.
Do you want a loader library that uses the code in p1load so you can just link it with PropellerIDE? I still think that's the best solution to this. Then you don't have to close the serial port and run the risk of losing data. It's why propeller-load -t and p1load -t work.
There seems to be too much interference in the background with Qt. Turning off some background threads helps, but it doesn't solve all issues.
I think that p1load needs more testing with Quickstart RevA boards. I saw some failures yesterday.
RE: V0.9
It seems like everything is back to normal, things are working as expected. The only explanation that I need is, what is to be expected when you choose 'Debug' from the Debug menu? All I get is blank terminal window, not sure what you can do with that, and yes I have a spin file opened.
Doe your spin program create output to the serial port? Do you have the Propeller Serial Terminal object in it and do you send anything to it?
"Debug" in this case is just a simple terminal your program CAN send output to or get input from it is not any sort of debugging tool giving you breakpoints, variable watches, or anything. You need to put some I/O in your program.
Yes, yes and yes. I am using my standard viewRTC.spin program, which uses the terminal screen for UI. What I was expecting, when I used the 'Debug' command, from the menu, was for the program to be run in the debug terminal. After further checking, I noticed that 'F8' works, which is the Debug command, but when selected from the menu, it does not work as expected.
OK, from your original post, I didn't know F8 worked and "Debug" on the menu didn't.
Sorry, I can't test v0.9 right now (or anything else Windows). I don't know if I've eve used the menu items, I usually just click on the blue terminal icon on the ribbon bar. That has always worked fine.
I never use the function key equivalents, so I did not try that item until later, otherwise I would have included that information, in my original post. Other than that, it looks like Propeller IDE is starting to take shape and will be a good replacement for the Propeller Tool.
Now, the next item, when will the Linux version be available for testing?
If you close the terminal window each time, do you get the same results?
This all works for me of course in Linux VMs, Windows VMs, and my desktop.
There are some Mac issues left to tackle though.
As far as Linux goes, this is all checked in to the "loader" branch.
That is do $ "hg pull" then $ "hg update loader"
Then rebuild all in Qt.
Then with linux console terminal cd loader and do $ make
Run program from Qt, choose openspin, p1load from the loader folder and a spin folder.
Etc....
Dennis, I pushed a change for Mac. Can you retest?
Dennis, I pushed a change for Mac. Can you retest?
As Curly of the Three Stooges would say "Why, Certainly!" or more accurately, "Why, Soitenly, yuk, yuk!"
Pulled & updated "loader", ran make in /loader, rebuilt PropellerIDE
Ran multiple tests with Activity Board, QS & Propeller DNA, individually
Ran multiple tests with 2 boards plugged-in, switching DEBUG sessions between the boards
Ran multiple unplug, replug-in sessions, with DEBUG runs in-between
These tests all succeeded.
I still get a hang of the app for about 7 seconds when I unplug a board, just "sometimes". This appears to be specific to my MacBook Pro, possibly a driver or configuration issue. But, it has not solidly hung-up the computer, as I had witnessed a few weeks ago (good!).
Well, here is a new problem, I think. I tried to re-test the debug screen:
1. Hit the blue screen, and it worked as expected.
2. Hit the F8 key, and got the "Blue Screen of Death", which is a first, since I have been running Windows 7.
3. Restart the computer.
4. Re-tested the blue screen, and now it shows "loader error", consistently.
When I get a chance I will uninstall and reinstall V0.9 and see if I can get that "Blue Screen of Death" again. I hope it was just a fluke.
As Curly of the Three Stooges would say "Why, Certainly!" or more accurately, "Why, Soitenly, yuk, yuk!"
Pulled & updated "loader", ran make in /loader, rebuilt PropellerIDE
Ran multiple tests with Activity Board, QS & Propeller DNA, individually
Ran multiple tests with 2 boards plugged-in, switching DEBUG sessions between the boards
Ran multiple unplug, replug-in sessions, with DEBUG runs in-between
These tests all succeeded.
I still get a hang of the app for about 7 seconds when I unplug a board, just "sometimes". This appears to be specific to my MacBook Pro, possibly a driver or configuration issue. But, it has not solidly hung-up the computer, as I had witnessed a few weeks ago (good!).
dgately
I think I can try it on my Mac Mini this afternoon and see if it stalls - if I turn off my phone and ignore my work email and instant messaging. (Sounds good on a Friday afternoon!!)
Well, here is a new problem, I think. I tried to re-test the debug screen:
1. Hit the blue screen, and it worked as expected.
2. Hit the F8 key, and got the "Blue Screen of Death", which is a first, since I have been running Windows 7.
3. Restart the computer.
4. Re-tested the blue screen, and now it shows "loader error", consistently.
When I get a chance I will uninstall and reinstall V0.9 and see if I can get that "Blue Screen of Death" again. I hope it was just a fluke.
Hate to be bearer of bad news but this v0.9 does not load consistently on my Activity board or C3. Testing same files with proptool no problems. Also the terminal does not auto start. First time I run it manualy I get expected text. Second time nothing.
Hate to be bearer of bad news but this v0.9 does not load consistently on my Activity board or C3. Testing same files with proptool no problems. Also the terminal does not auto start. First time I run it manualy I get expected text. Second time nothing.
How can I help?
What happens if you change the loader to propeller-load.exe ?
So, I re-installed v0.9 and:
1. Debug menu item, worked as expected.
2. Blue terminal, worked as expected.
3. F8, loader error.
4. Blue terminal, worked as expected.
5. Debug menu item, loader error.
6. F8, worked as expected.
7. Blue terminal, "PropellerIDE.exe has stopped working". I guess that is better than the "Blue Screen of Death".
Since the problem with Propeller IDE seems to be centered around the Loader, are you using qt-serial for the serial port stuff? Maybe their is a bug with QT5 and the serial lib? After all, it seems like SimpleIDE has never had those kind of problems, but it was compiled with QT4, correct? Maybe you should try compiling Propeller IDE with QT4 and see if you get the same problems?
Change the loader to propeller-load.exe and repeat. Using this method may cause output to be missed.
The loader is not compiled with Qt ... propeller-load.exe is exactly the same as what is used in SimpleIDE.
The p1load program is not compiled with Qt either.
So, I re-installed v0.9 and:
1. Debug menu item, worked as expected.
2. Blue terminal, worked as expected.
3. F8, loader error.
4. Blue terminal, worked as expected.
5. Debug menu item, loader error.
6. F8, worked as expected.
7. Blue terminal, "PropellerIDE.exe has stopped working". I guess that is better than the "Blue Screen of Death".
Since the problem with Propeller IDE seems to be centered around the Loader, are you using qt-serial for the serial port stuff? Maybe their is a bug with QT5 and the serial lib? After all, it seems like SimpleIDE has never had those kind of problems, but it was compiled with QT4, correct? Maybe you should try compiling Propeller IDE with QT4 and see if you get the same problems?
Change the loader to propeller-load.exe and repeat.
Not sure what you mean there. In my properties window it already is showing propeller-load.exe, but its path is from C:/Program Files(x86)/PropellerIDE. What I did do is use the propeller-load.exe that I got from SimpleIDE, now with that one I get everything working as expected. The debug stuff works all the time, as expected. What the heck is the difference between the propeller-load.exe that you are using now, and the one from SimpleIDE? Maybe I got some really weird stuff going on with my computer.
Not sure what you mean there. In my properties window it already is showing propeller-load.exe, but its path is from C:/Program Files(x86)/PropellerIDE. What I did do is use the propeller-load.exe that I got from SimpleIDE, now with that one I get everything working as expected. The debug stuff works all the time, as expected. What the heck is the difference between the propeller-load.exe that you are using now, and the one from SimpleIDE? Maybe I got some really weird stuff going on with my computer.
The propeller-load.exe that I have from SimpleIDE is 132KB. The propeller-load.exe that is in the C:/Program Files(x86)/PropellerIDE is 134KB. So I see a slight difference, meaning they are different in size.
Can you please change the loader to Program Files/PropellerIDE /p1load.exe and retest?
I misread your original post and that was the first thing that I did. So, at this point I am using the other p1load.exe and the SimpleIDE propeller-load.exe. I just did a quick test and it seems to be working as expected.
Comments
Its me again, V0.8 worked fine for me for sure. Loaded 2 different programs into my Activity board and my C3. Both boards program both to memory and EEprom. One interesting thing I noticed one program does use term to disp temp and humidity reading. First time it loaded to ram just fine. When I reprogrammed to rom the button on toolbar failed with no prop found as it does in proptool when the term is active. When I went into the debug pull down to burn it worked great. Did I miss how to stop term?
Dont have a quickstart to try and didnt try your new loader. Not sure now if I have a delay in my program or not, will check on that.
Nice work!!
Thanks.
So there are two possible failures:
1. The terminal misses the output.
2. The program complain about load failure.
Which one did you see?
Also do you ever see failure 2?
If you see failure 1, if you repeat the load, does it always miss the output or just once in a while?
Thanks for testing!
I have a RevA QuickStart and a DNA board connected. I've been hopping back and forth loading and running the 2 boards and haven;t broken it yet or had a QS load failure yet (but those come and go at random).
I'll keep playing, trying to break it.
It's looking pretty slick!
EDIT: Haven't tried p1loadcat yet. It's up next!
Jazzed,
Not running on Windows, but I did "hg pull" & "hg update loader" on Mac OS X and rebuilt. Did a "make" in the new /loader directory to build p1load binary. Set Properties/Loader to that binary. Mod'ed the "Hello Spin2" code to remove the waitcnt.
Ran "Debug" on Activity Board, Propeller DNA and QuickStart Rev A...
Got good results almost every time test was run. Did see an occasional mis-displaying "Hello Spin2" completely (see the screenshot).
For a second test, I plugged-in two of the boards at a time and did various unplug-replug tests in-between Debug runs. The app would hang momentarily when I unplugged a board, as you had seen this weekend, but always came back after about 5-7 seconds.
This version (if my updated code is the same as your compiled Win code) is looking good!
dgately
Sorry for the delay in response. My real job got in the way! I never saw #2 and #1 failed every time on reload using p1loadcat.
Bob
That's the best I can do under the circumstances. Apparently it is not reliable enough to keep. So we're back to a delay before printing while the IDE loader takes over the port.
The built-in loader is reliable for some people, but fails miserably for others. So, that is gone. I'm done with the P8x32a Propeller load protocol. Hopefully the next loader isn't so bad. Determinism sucks in this case at least.
I think that p1load needs more testing with Quickstart RevA boards. I saw some failures yesterday.
Actually, I notice that Radio Shack has them on sale for $19.95 if anyone wants to pick them up cheap.
Please give Windows version V0.9 a try. https://drive.google.com/file/d/0BzcfH7bdVTbtNUhLZk9lMEJqWVU/edit?usp=sharing
It seems like everything is back to normal, things are working as expected. The only explanation that I need is, what is to be expected when you choose 'Debug' from the Debug menu? All I get is blank terminal window, not sure what you can do with that, and yes I have a spin file opened.
Ray
"Debug" in this case is just a simple terminal your program CAN send output to or get input from it is not any sort of debugging tool giving you breakpoints, variable watches, or anything. You need to put some I/O in your program.
Ray
Sorry, I can't test v0.9 right now (or anything else Windows). I don't know if I've eve used the menu items, I usually just click on the blue terminal icon on the ribbon bar. That has always worked fine.
Now, the next item, when will the Linux version be available for testing?
Ray
Help me out here. Which of the following actions consistently work for you every time you do it (say 4 times each) ?
1. F8 - Loads program, shows terminal window, displays output.
2. Menu -> Debug -> Debug - Loads program, shows terminal window, displays output.
3. Toolbar Debug button - Loads program, shows terminal window, displays output.
If you close the terminal window each time, do you get the same results?
This all works for me of course in Linux VMs, Windows VMs, and my desktop.
There are some Mac issues left to tackle though.
As far as Linux goes, this is all checked in to the "loader" branch.
That is do $ "hg pull" then $ "hg update loader"
Then rebuild all in Qt.
Then with linux console terminal cd loader and do $ make
Run program from Qt, choose openspin, p1load from the loader folder and a spin folder.
Etc....
Dennis, I pushed a change for Mac. Can you retest?
As Curly of the Three Stooges would say "Why, Certainly!" or more accurately, "Why, Soitenly, yuk, yuk!"
Pulled & updated "loader", ran make in /loader, rebuilt PropellerIDE
Ran multiple tests with Activity Board, QS & Propeller DNA, individually
Ran multiple tests with 2 boards plugged-in, switching DEBUG sessions between the boards
Ran multiple unplug, replug-in sessions, with DEBUG runs in-between
These tests all succeeded.
I still get a hang of the app for about 7 seconds when I unplug a board, just "sometimes". This appears to be specific to my MacBook Pro, possibly a driver or configuration issue. But, it has not solidly hung-up the computer, as I had witnessed a few weeks ago (good!).
dgately
1. Hit the blue screen, and it worked as expected.
2. Hit the F8 key, and got the "Blue Screen of Death", which is a first, since I have been running Windows 7.
3. Restart the computer.
4. Re-tested the blue screen, and now it shows "loader error", consistently.
When I get a chance I will uninstall and reinstall V0.9 and see if I can get that "Blue Screen of Death" again. I hope it was just a fluke.
Ray
I think I can try it on my Mac Mini this afternoon and see if it stalls - if I turn off my phone and ignore my work email and instant messaging. (Sounds good on a Friday afternoon!!)
Just friggin' great. If this is not resolved, I'm cancelling the project.
How can I help?
What happens if you change the loader to propeller-load.exe ?
1. Debug menu item, worked as expected.
2. Blue terminal, worked as expected.
3. F8, loader error.
4. Blue terminal, worked as expected.
5. Debug menu item, loader error.
6. F8, worked as expected.
7. Blue terminal, "PropellerIDE.exe has stopped working". I guess that is better than the "Blue Screen of Death".
Since the problem with Propeller IDE seems to be centered around the Loader, are you using qt-serial for the serial port stuff? Maybe their is a bug with QT5 and the serial lib? After all, it seems like SimpleIDE has never had those kind of problems, but it was compiled with QT4, correct? Maybe you should try compiling Propeller IDE with QT4 and see if you get the same problems?
Ray
Change the loader to propeller-load.exe and repeat. Using this method may cause output to be missed.
The loader is not compiled with Qt ... propeller-load.exe is exactly the same as what is used in SimpleIDE.
The p1load program is not compiled with Qt either.
Ray
I have no idea why the same program would behave differently. Is it the same size? Maybe I have a bad copy on my system?
Can you please change the loader to Program Files/PropellerIDE /p1load.exe and retest?
I misread your original post and that was the first thing that I did. So, at this point I am using the other p1load.exe and the SimpleIDE propeller-load.exe. I just did a quick test and it seems to be working as expected.
Ray