It looks like his build environment is missing gcc and/or g++.
You need to build openspin and get installed in a path that give the system access to the openspin.exe command.
He can't do that cause again...his build environment is missing gcc and/or g++.
No idea why the parallax build instructions aren't clearly laid out in steps for each platform on the readme... they usualy put it here..
But.. by the make file... you need..
CC=gcc
CXX=g++
ends up as...
CC=i686-w64-mingw32-gcc
CXX=i686-w64-mingw32-g++
Do you have/did you install ----> https://mingw-w64.org/doku.php/download/win-builds
I won't have winOS so i can't tell if this is what or only what you need but this installer contains the following tools for windows..
The README file does mention that you need openspin installed and also MinGW if you want to build the Windows version under Linux. I don't ever build under Windows so I haven't figured out what tools are required for that although MinGW might work and maybe Cygwin as well.
Anyone test any of the 2018 changes to proploader with ParallaxESP?
I can't get a download to go, even from command line.
The last commit in 2017 is fine.
More info in the issue. https://github.com/parallaxinc/PropLoader/issues/46
Sorry about this problem. I need to look into it but I'm not sure I'm going to have time for a few weeks. I'll try to squeeze it in. Thanks for reporting it!
Sorry about this problem. I need to look into it but I'm not sure I'm going to have time for a few weeks. I'll try to squeeze it in. Thanks for reporting it!
Not a big deal, its noted, thanks for all the work!
I've spent some time trying to track down this problem and I think there are multiple things going on. First, my ActivityBoard WX failure seems to be due to me using a prototype version of the AB WX. I have a number of production boards but Rev A and Rev C and they all seem to work fine for both serial and wifi loading and EEPROM programming as does an old-style ActivityBoard. The only failure I've had is on the prototype board.
Clock Loop: So that leaves me with what is causing your problem. It seems unrelated to the failures I was seeing. One possibility might be that you were trying to use the RCFAST clock mode and that is unlikely to work at 115200 baud. There could also be a problem with the value of the pull-up resistor on P29. The circuit I found suggested a 2.2k ohm pull-up but I think you were using a 20k resistor. Could that be the cause of the EEPROM programming failures?
I have a 2k pullup on that pin now and it doesn't help.
The eeprom failures were not JUST eeprom, even if I just loaded to ram and ran.
I have verified this condition again, and currently have reverted to the working c4205c0 commit.
I also have a fresh today, lean install of debian9, and was able to add things to the instruction to use 9.6 stretch.
So my only worry was that I was using a version that might be part of the problem.
Now that I am at stretch, I see the same exact scenario..
Curious, the issue seemed to just... change... when repeatedly running a new git on the two different versions.
Current commit. And c4205c0, as the working commit.
Download each one, once, and copy it elsewhere to make and work with it, and even rename it, because the version lies.
Due to the version not changing, keeping track of what .. is what is what is what is what.... ya,,, you get it.
Strictly in simpleide, on linux, used in the location of a board file, it does things?
So then this situation is related to simpleide? .. only?
So then this situation is related to simpleide? .. only?
Are you saying you only see this problem when proploader is invoked by SimpleIDE? I never use SimpleIDE so I guess I wouldn't have seen that although I don't see why proploader would behave any differently if given the same arguments. I'm afraid I can't really help any further. I can't duplicate this problem. Maybe you can post your schematic?
I am actually thinking the same thing. Perhaps I need to look at the WX activity board and see how the WX module is wired compared to mine.
I also can't get RTS to work when programming, only CTS will work properly.
I'll go over the schematic of the Wx activity board.
I looked at it and the only thing that makes me think on why you can get away with fast speeds is because the WX board has buffer logic between the Parallax-ESP and the propeller chip.
From my experience with various 8266 boards, some do better than others, I would imagine that buffer logic would help with much faster speeds.
Then the WX dosen't really need to PUSH or PULL logic pins. The transitions must be speedy compared to a pull up or down bias resistor on the same wx outputs.
And the 8266 is a power sucker! I have a 4700uF cap within 1 inch of it, i no longer doubt this chips ability to NEED JUICE!
And its wifi is much zippier... So I would imagine if it dosen't have to push/pull hard, it has less drain from the wifi.
If I had realized this earlier with my own esp devices, i might have saved time, and just used some kinda buffer logic to assist the 8266.
Perhaps that makes the logic transitions smoother, or faster, I don't know.
I can try using the DTS line for the propeller reset to see if that changes anything.
As I learn QT5 and the simpleIDE code, eventually I might see where the proploader commands are being coded, and just remove RCFAST.
I noticed the scl AND sda lines of the eeprom on the wxactivity board are pulled high with 10.5k 1$% resistors. I only pull the SDA high with 10k. I will try both.
I appreciate your help!
I can invoke the same problem on the command line if I still use RCFAST.
But the RCFAST mode barks about not having a board file if run somewhere other than the simpleide/bin folder.
So its like the problem is directly related to the board file.
You must have made the code use fast speeds since 2017's commit, and clearly buffer logic is the key to faster propeller<---BufferLogic--->esp speeds.
I tried setting very slow speeds in the PropellerESP configuration page, and no setting seemed to help or make a difference.
I will take a picture of the setup I am using asap. And post.
You must have really sped up the proploader load code, does it really load on those activity boards at 460800?
Im not that spoiled, I just figure 115200 is excellent.
I have tried a few different things and when using simpleide with a parallaxesp, the last proploader commit in 2017 works fine.
The latest one 2018 dosen't work in any test i try.
Even when I set the ParallaxESP module to 921600, it still loads the program fine, with the commit in 2017.
CTS and DTR are the only pins that I can get to reset the propeller, with the commit in 2017.
The 2018 commit DOES reset those same lines when trying to program the propeller but still fails to download.
So if others see issues in linux with simpleide 1.1.2 try using the last proploader commit in 2017.
I even tried setting boen to high and low. Meh, perhaps it doesn't like the kinda bread on my board.
Can you please try these two command lines with the latest proploader? Please get SimpleIDE out of the loop.
proploader myprog.binary -r
Or this:
proploader -D loader=rom myprog.binary -r
Just append "-e" if you want to also program the EEPROM. You can also add "-i mymodule" if you want to specify either the DNS name or the IP address of your module.
I had to copy the 2018 commit to my /usr/bin folder to get it away from simpleide.
Then I did.
:~/Desktop/Spin/ParallaxWx$ proploader -D loader=rom ParallaxWx.binary -r
Opening file 'ParallaxWx.binary'
Downloading file to port 123.123.123.123
ERROR: Download failed
:~/Desktop/Spin/ParallaxWx$ proploader ParallaxWx.binary -r
Opening file 'ParallaxWx.binary'
Downloading file to port 123.123.123.123
3284 bytes sent
Verifying RAM
Download successful!
So its related to the commands that simple ide sends, or that the proploader program is in the simpleide/bin folder.
I attached the spin file I am using.
THIS WILL WRITE TO YOUR EEPROM IF YOU RUN IT.
It has the side file also.
It doesn't do anything special but talk to the eeprom and send data to the ParallaxESP telnet port.
The image shows the putty -telnet output.
Actually, I realized after I posted that that loader=rom will not work with the WX module. It will only work with serial downloads. Sorry.
So I guess you're saying that when invoked from the command line proploader works fine unless you specify the loader=run option that I incorrectly suggested. Is that right?
Okay, so the problem is the new loader's handling of "-b rcfast". I can look into that. Did you ever change the board type in SimpleIDE to use the ActivityBoard ("-b activityboard") instead of rcfast?
But the c compiler lets me change it.
So is this a simpleide bug?
The board type has never worked for me in spin, even in older versions of simpleide that I download from parallax.
I just figured it was supposed to be dimmed out for spin files.
I have been playing with the speed settings for the ParallaxWx and the data communication rates, and when I tell my program to use 921_600, it works.
Thats cool that I can send 921_600 telnet data from the prop wireless.
I wouldn't have tried that if the loader didn't work, but it did work at 921_600 with the 2007_proploader.
So I tried to change my propeller program debug output to 921_600, and the ParallaxWx settings.
And it shows smooth. So that is nice having a much faster data connection to work with.
But the c compiler lets me change it.
So is this a simpleide bug?
The board type has never worked for me in spin, even in older versions of simpleide that I download from parallax.
I just figured it was supposed to be dimmed out for spin files.
I would say that it's a bug that the board type doesn't work for Spin code. However, it is also a proploader bug that it doesn't work with "-b rcfast". I intend to fix that.
Actually, in thinking about it we will never be able to support "-b rcfast" for wifi loading because the fast loader won't work with RCFAST and the slow loader is limited to 2K images over wifi since the WX module has a very small amount of RAM. Basically, the WX module only uses the ROM loader to load the fast loader which is <2K. You will, however be able to use RCFAST with serial loading in which case it will basically revert to the same behavior as propeller-load.
So then proploader, when using wifi, should default to a specific board type? or loader?
If you have a 5mhz crystal and want to run at 80mhz you can use the activityboard.cfg file. If you're using a 10mhz crystal and want to run at 80mhz you can use the hydra.cfg file.
Since SimpleIDE forces you to use generic. Which is file: rcfast.cfg # the generic rcfast clock setting
So I should copy my actitityboard.cfg contents and overwrite my rcfast.cfg contents with it? # the generic rcfast clock setting
Hey it looks like the baud rate in that config is why my debug interface on my Propeller-ESP board is resetting to 115200 every time I program.
Excellent.
Until simple ide can be fixed, i'll edit the default config file of rcfast.cfg to match actitityboard.cfg plus my faster speed of 921600.
Then the new proploader should work.
I'll give it a spin.. (yea yea)
That worked.
So a change in the way proploader handles -rcfast switch made simple ide not work with fairly standard boards that did work before that change.
Then simpleIDE needs to be changed?
The propeller manual shows the standard or default connection with a 5mhz external crystal.
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
But it looks like the rcfast.cfg default file is written to RCFAST boot.
_CLKMODE = RCFAST
_XINFREQ = 12_000_000
Since the user is forced to use rcfast.cfg when using the SPIN compiler, they run into my situation.
Odd.
Every parallax propeller board I own has a 5mhz external crystal.
I will revert to proploaders latest commit, and instruct simpleide builders to change the default rcfast.cfg file if using the SPIN compiler.
Just out of curiosity, why are you using SimpleIDE with Spin. A while back Parallax said they didn't support its use with Spin. PropellerIDE was supposed to be the official cross-platform IDE for Spin. Have you tried PropellerIDE? In any case, as long as there is still some semblance of Spin support in SimpleIDE, I agree that it should be fixed to allow the board type to be selected.
Oh, I am not sure why I went to simpleide, I think its because propelleride didn't work with the ParallaxESP device for me.
I just thought it was the way they were going, to an integrated language type interface.
I do like that...
I can check out propelleride again to see why I didn't keep it.
These two things are why I chose simpleide when I initially saw and tried both.
SimpleIDE has a make file.
And has some info on how to compile...
It had C C++ and spin so I figured it was the superior UNION platform.
-SimpleIDE compiles in the latest version of QT, PropellerIDE says use QT5.2 or higher, even if using QT5.11
You're probably right. I don't think PropellerIDE will support wifi downloads. I'll check with Parallax to see if they are interested in updating SimpleIDE to support board selection for Spin programs. I have no idea why they didn't in the first place.
I have a PC running Windows 8.1 and a Parallax USB to Serial converter #28030. No matter what, I get a Download error of -1 with SimpleIDE, but the Propeller Tool works fine with "spin".
Please don't tell me to "update the USB driver" because I have tried them all from Parallax and the FTDI website. Please help.
(I had the same problem with another PC running Windows 10 and did fix the problem by updating the USB driver.
Comments
You need to build openspin and get installed in a path that give the system access to the openspin.exe command.
He can't do that cause again...his build environment is missing gcc and/or g++.
No idea why the parallax build instructions aren't clearly laid out in steps for each platform on the readme... they usualy put it here..
But.. by the make file... you need..
CC=gcc
CXX=g++
ends up as...
CC=i686-w64-mingw32-gcc
CXX=i686-w64-mingw32-g++
Do you have/did you install ----> https://mingw-w64.org/doku.php/download/win-builds
I won't have winOS so i can't tell if this is what or only what you need but this installer contains the following tools for windows..
Then the script goes into this and i didn't look what it does...
./build-win32
I can't get a download to go, even from command line.
The last commit in 2017 is fine.
More info in the issue.
https://github.com/parallaxinc/PropLoader/issues/46
Not a big deal, its noted, thanks for all the work!
Clock Loop: So that leaves me with what is causing your problem. It seems unrelated to the failures I was seeing. One possibility might be that you were trying to use the RCFAST clock mode and that is unlikely to work at 115200 baud. There could also be a problem with the value of the pull-up resistor on P29. The circuit I found suggested a 2.2k ohm pull-up but I think you were using a 20k resistor. Could that be the cause of the EEPROM programming failures?
The eeprom failures were not JUST eeprom, even if I just loaded to ram and ran.
I have verified this condition again, and currently have reverted to the working c4205c0 commit.
I also have a fresh today, lean install of debian9, and was able to add things to the instruction to use 9.6 stretch.
So my only worry was that I was using a version that might be part of the problem.
Now that I am at stretch, I see the same exact scenario..
Curious, the issue seemed to just... change... when repeatedly running a new git on the two different versions.
Current commit. And c4205c0, as the working commit.
Download each one, once, and copy it elsewhere to make and work with it, and even rename it, because the version lies.
Due to the version not changing, keeping track of what .. is what is what is what is what.... ya,,, you get it.
Strictly in simpleide, on linux, used in the location of a board file, it does things?
So then this situation is related to simpleide? .. only?
I also can't get RTS to work when programming, only CTS will work properly.
I'll go over the schematic of the Wx activity board.
I looked at it and the only thing that makes me think on why you can get away with fast speeds is because the WX board has buffer logic between the Parallax-ESP and the propeller chip.
From my experience with various 8266 boards, some do better than others, I would imagine that buffer logic would help with much faster speeds.
Then the WX dosen't really need to PUSH or PULL logic pins. The transitions must be speedy compared to a pull up or down bias resistor on the same wx outputs.
And the 8266 is a power sucker! I have a 4700uF cap within 1 inch of it, i no longer doubt this chips ability to NEED JUICE!
And its wifi is much zippier... So I would imagine if it dosen't have to push/pull hard, it has less drain from the wifi.
If I had realized this earlier with my own esp devices, i might have saved time, and just used some kinda buffer logic to assist the 8266.
Perhaps that makes the logic transitions smoother, or faster, I don't know.
I can try using the DTS line for the propeller reset to see if that changes anything.
As I learn QT5 and the simpleIDE code, eventually I might see where the proploader commands are being coded, and just remove RCFAST.
I noticed the scl AND sda lines of the eeprom on the wxactivity board are pulled high with 10.5k 1$% resistors. I only pull the SDA high with 10k. I will try both.
I appreciate your help!
I can invoke the same problem on the command line if I still use RCFAST.
But the RCFAST mode barks about not having a board file if run somewhere other than the simpleide/bin folder.
So its like the problem is directly related to the board file.
You must have made the code use fast speeds since 2017's commit, and clearly buffer logic is the key to faster propeller<---BufferLogic--->esp speeds.
I tried setting very slow speeds in the PropellerESP configuration page, and no setting seemed to help or make a difference.
I will take a picture of the setup I am using asap. And post.
You must have really sped up the proploader load code, does it really load on those activity boards at 460800?
Im not that spoiled, I just figure 115200 is excellent.
The latest one 2018 dosen't work in any test i try.
Even when I set the ParallaxESP module to 921600, it still loads the program fine, with the commit in 2017.
CTS and DTR are the only pins that I can get to reset the propeller, with the commit in 2017.
The 2018 commit DOES reset those same lines when trying to program the propeller but still fails to download.
So if others see issues in linux with simpleide 1.1.2 try using the last proploader commit in 2017.
I even tried setting boen to high and low. Meh, perhaps it doesn't like the kinda bread on my board.
Then I did.
:~/Desktop/Spin/ParallaxWx$ proploader -D loader=rom ParallaxWx.binary -r
Opening file 'ParallaxWx.binary'
Downloading file to port 123.123.123.123
ERROR: Download failed
:~/Desktop/Spin/ParallaxWx$ proploader ParallaxWx.binary -r
Opening file 'ParallaxWx.binary'
Downloading file to port 123.123.123.123
3284 bytes sent
Verifying RAM
Download successful!
So its related to the commands that simple ide sends, or that the proploader program is in the simpleide/bin folder.
I attached the spin file I am using.
THIS WILL WRITE TO YOUR EEPROM IF YOU RUN IT.
It has the side file also.
It doesn't do anything special but talk to the eeprom and send data to the ParallaxESP telnet port.
The image shows the putty -telnet output.
So I guess you're saying that when invoked from the command line proploader works fine unless you specify the loader=run option that I incorrectly suggested. Is that right?
Full download.
:~/Desktop/Spin/ParallaxWx$ proploader ParallaxWx.binary -r
Opening file 'ParallaxWx.binary'
Downloading file to port 123.123.123.123
3284 bytes sent
Verifying RAM
Download successful!
So its related to the commands that simple ide sends, or that the proploader program is in the simpleide/bin folder.
So is this a simpleide bug?
The board type has never worked for me in spin, even in older versions of simpleide that I download from parallax.
I just figured it was supposed to be dimmed out for spin files.
Thats cool that I can send 921_600 telnet data from the prop wireless.
I wouldn't have tried that if the loader didn't work, but it did work at 921_600 with the 2007_proploader.
So I tried to change my propeller program debug output to 921_600, and the ParallaxWx settings.
And it shows smooth. So that is nice having a much faster data connection to work with.
So I should copy my actitityboard.cfg contents and overwrite my rcfast.cfg contents with it? # the generic rcfast clock setting
Hey it looks like the baud rate in that config is why my debug interface on my Propeller-ESP board is resetting to 115200 every time I program.
Excellent.
Until simple ide can be fixed, i'll edit the default config file of rcfast.cfg to match actitityboard.cfg plus my faster speed of 921600.
Then the new proploader should work.
I'll give it a spin.. (yea yea)
So a change in the way proploader handles -rcfast switch made simple ide not work with fairly standard boards that did work before that change.
Then simpleIDE needs to be changed?
The propeller manual shows the standard or default connection with a 5mhz external crystal. But it looks like the rcfast.cfg default file is written to RCFAST boot.
Since the user is forced to use rcfast.cfg when using the SPIN compiler, they run into my situation.
Odd.
Every parallax propeller board I own has a 5mhz external crystal.
I will revert to proploaders latest commit, and instruct simpleide builders to change the default rcfast.cfg file if using the SPIN compiler.
It is located:
I just thought it was the way they were going, to an integrated language type interface.
I do like that...
I can check out propelleride again to see why I didn't keep it.
These two things are why I chose simpleide when I initially saw and tried both.
-SimpleIDE compiles in the latest version of QT, PropellerIDE says use QT5.2 or higher, even if using QT5.11
Deleting the rcfast.cfg file and copying activityboard.cfg and renaming it to rcfast.cfg fixed the problem.
They are located here: C:\Program Files (x86)\SimpleIDE\propeller-gcc\propeller-load
Using the latest version of proploader helped with my wifi download issues I had sometimes.
Please don't tell me to "update the USB driver" because I have tried them all from Parallax and the FTDI website. Please help.
(I had the same problem with another PC running Windows 10 and did fix the problem by updating the USB driver.