Building with openspin does not complete upload to RAM or EEPROM (on Mac OS 10)

[dgately]

I'm seeing this on Mac OS X (10.11.6): Now that PropellerIDE supports a choice of compilers for Spin code, it appears that although the openspin compile completes, the compiled executable does not get uploaded to the propeller board. The attached image show a completed build using openspin. As can be seen, the executable never gets uploaded (there's no indication that it even tries to) to the prop board. Happens for both RAM & EEPROM uploads. Building with bstc completes the compile & uploads the executable, leaving a notice in the log...

[totalspectrum]

I'm seeing the same thing on Windows 10 with the PropellerIDE 0.38.5 binary downloaded from the github "releases" page. If openspin is selected as the Spin compiler then the compile completes with "Build Successful!" and the download icon is lit up, but download never finishes and nothing is output to the terminal. If bstc is selected as the Spin compiler then everything seems to work.

[bweir]

Huh, that's curious. I noticed some weirdness with the new logic, but I
hadn't seen this yet. I'll check it out when I get the chance. Thanks!

On Aug 21, 2016 4:39 PM, "Eric R. Smith" [email protected] wrote:

I'm seeing the same thing on Windows 10 with the PropellerIDE 0.38.5
binary downloaded from the github "releases" page. If openspin is selected
as the Spin compiler then the compile completes with "Build Successful!"
and the download icon is lit up, but download never finishes and nothing is
output to the terminal. If bstc is selected as the Spin compiler then
everything seems to work.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#43 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJEcGF0CbC83VeI-QGCdGsYAyTf0isuxks5qiOGagaJpZM4JpMv1
.

[Gadgetoid]

Seeing the same thing on 0.38.5, compiled from source on a Rasberry Pi, Raspbian Jessie.

Also, no matter what code I use, BTSC gives me a syntax error:

/usr/bin/btsc: 1: /usr/bi/btsc: Syntax error: "(" unexpected

[bweir]

Ahh, sorry, guys, I haven't gotten a chance to look at this yet. I'm trying
to plan my kickstarter for mid September, so not much has been happening on
any other project. I'm going to be announcing the launch date on the forum
in the next day or so.

I'll see if I can squeeze this in but I can't make any guarantees.

Also, Phil, I'm surprised bstc gives you any message at all since it was
built for x86!

On Aug 23, 2016 2:11 AM, "Philip Howard" [email protected] wrote:

Seeing the same thing on 0.38.5, compiled from source on a Rasberry Pi,
Raspbian Jessie.

Also, no matter what code I use, BTSC gives me a syntax error:

/usr/bin/btsc: 1: /usr/bi/btsc: Syntax error: "(" unexpected

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#43 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJEcGDWnyyd6YcnjAbdo9l782Upv3jiEks5qirlKgaJpZM4JpMv1
.

[totalspectrum]

Just as a note for Phil, if you need a bstc replacement for Raspberry Pi try github.com/totalspectrum/spin2cpp. It should build on any Linux, and the "fastspin" front end will work with PropellerIDE if it's renamed to "bstc". The downside is that fastspin binaries are LMM rather than Spin bytecode, so they are much bigger (but faster).

[bweir]

@totalspectrum this is not a good route to go. PropellerIDE expects bstc to support bstc command line arguments, and to output bstc output, so I don't think this is likely to work as is, and then you are messing with system-installed binaries.

You should create a compiler config for fastspin, so that it can just be used as is. Here is the bstc config for reference. https://github.com/parallaxinc/PropellerIDE/blob/master/src/propelleride/config/compiler.bstc

As far as packaging goes, what kind of application is spin2cpp? C++? C#? If it's a C++ app, we could drop a qmake project file into spin2cpp and it would be really easy to build. Packthing doesn't support arbitrary makefiles at this point, so if you wanted to go that route, it would be a lot longer before it was supported.

Either way, I am preparing for my Kickstarter right now so there won't be much activity from me for a couple months! =O

[Gadgetoid]

Also, Phil, I'm surprised bstc gives you any message at all since it was
built for x86!

Interestingly, I found the error can be reproduced on the Pi by running cat /usr/bin/bstc | bash - so the x86 binary is being interpreted as a bash script. Weird! But solves that little mystery anyway.

@totalspectrum that's interesting, thanks! I'll have to check it out.

[totalspectrum]

@totalspectrum this is not a good route to go. PropellerIDE expects bstc to support bstc command line arguments, and to output bstc output, so I don't think this is likely to work as is, and then you are messing with system-installed binaries.

I tested it and it did work, at least to the extent of being able to run some Spin and PropBASIC programs. I agree that adding a fastspin specific compiler config would be a better approach, but that requires recompilation (as far as I can see) which not everyone is up for. Also, fastspin's command line arguments are the same as openspin's, which is how I found this bug in the first place -- I tried out openspin first in PropellerIDE just to see how it works and discovered that it doesn't :(.

As far as packaging, spin2cpp is a C application, so it's probably not hard to integrate into your build system; but frankly I don't think there's a need for that, you can just use the fastspin.exe executable just as you do the bstc.exe executable.

Good luck on your Kickstarter!

[avsa242]

I've run into this, as well. I initially thought this was clang's fault (used clang to build because Ubuntu's gcc 6.2.0 can't seem to build propelleride for awhile, but this seems to be a separate issue now), but older revisions seem to work fine. Brett, you may or may not have had time to look at this at all, or maybe this will seem obvious to you, but I've bisected it to:

`29c3ddf24009cfe0ccbc52fcbbfce7b3613b00bd is the first bad commit
commit 29c3ddf
Author: Brett Weir [email protected]
Date: Wed Jul 13 23:54:58 2016 -0700

Begin implementing external compiler class, compiler interface, highlight line can resolve filenames better`

Hope this helps...if I can help more I'd be happy to.

Cheers,
Jesse

[PropGit]

@bweir - Can you look into this and solve it now? There's a thread on the forum for this over the weekend: http://forums.parallax.com/discussion/165574/propelleride-send-not-to-propeller#latest

This is a serious issue; it doesn't seem to be directly OpenSpin related, but rather caused by some other changes in PropellerIDE since v37.5. Happens on all platforms apparently. Mac OS X Sierra is particularly a problem because bstc reportedly won't work on Sierra.

[avsa242]

I found a solution to this. Edit src/propelleride/config/compiler.openspin and change the line that reads:
PATTERN_RET=.binary
to
PATTERN_RET=

When I was running PropellerIDE in a terminal I noticed that when building & running a program, after building successfully, OpenSpin was complaining that it "couldn't find/open myprogram.binary.binary"
Digging a little deeper in the PropellerIDE sources, I found the config files for external compilers and noticed that, more obvious lines aside, the config for bstc, which was mentioned above by @totalspectrum to work, was slightly different. It lies in the PATTERN_* keys. PATTERN_IN seems to be the filename suffix the compiler looks for in source, PATTERN_OUT for binaries it produces, and PATTERN_RET for what propman looks for for files to send to the prop. So, for some reason, .binary is getting appended to filenames twice and of course, OpenSpin can't find it. I have a feeling this is not the right way to fix this - probably something in the way filenames are being parsed, but it seems to work on everything I've built. Maybe if Brett isn't available, someone who knows a thing or two about C++ and QT5 can take a look.

[ironsheep]

I'm now experiencing this too. Help! What' can I do? Will you be releasing a new build with this above mentioned fix?

[avsa242]

compiler.openspin.patch.zip

@PropGit
I've attached a patch that fixes this for me. I still can't say for certain that this is the right way to fix it, but I've yet to see side effects from it, I've been running it this way for months now, and I'm not sure if @bweir is around any longer. Unzip the archive in the root of the PropellerIDE source, run the patchit.sh shell script from a command line.
Type ./patchit.sh
...or... manually patch the file typing
patch -p0 <compiler.openspin.patch

Successful output should look like:

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- src/propelleride/config/compiler.openspin  2017-07-11 16:35:11.154830619 -0400
|+++ src/propelleride/config/compiler.openspin.new      2017-07-11 16:35:01.078960428 -0400
--------------------------
checking file src/propelleride/config/compiler.openspin
Using Plan A...
Hunk #1 succeeded at 2.
done

BTW, all this amounts to is the one small change from my last post here.

Cheers,
Jesse

[schwab]

I'm having the same problem with a raspberry pi running the Propelleride with the openspin compiler selected. The patch doesn't work for me because I'm running from the release instead of source code. I tried getting the source to work, but couldn't find any instructions for build/make or whatever is needed to get it going. For now I'm stuck having to disconnect from the pi and download firmware from another machine.

[DrMichaelGreen]

For some time (months or more), I've been unable to download large programs after compilation to pretty much any Propeller. The download just fails and I get an error in the build window. If I use proploader separately in a command-line window (terminal), it all works absent some inconvenience. Is there some way to substitute proploader for whatever's used now? It would be nice too to be able to make use of the wireless downloading ability of proploader. I use MacOS (now 10.14.1).

[avsa242]

@DrMichaelGreen
PropellerIDE uses its own loader mechanism, PropellerManager. I'm far from fluent in C++, but I don't see a means for specifying an alternative external loader. It looks like it was originally implemented because it was designed to have some more advanced features than simply being a loader, according to src/propellermanager/doc/buildingspin.cpp in the source.

I'm wondering if what @bweir is talking about in faq.cpp (same subdirectory) could be affecting you, i.e., the PropellerDevice::reset() function. It sounds like adding a static delay has a possibility of mitigating some issues.

Just out of curiosity, do you have the means to try/have you tried this with multiple Prop boards, especially ones with differing USB <-> TTL chips on them?

BTW, I've used a fairly simple bash shell script to use proploader with PropellerIDE, ref http://forums.parallax.com/discussion/168942/shell-script-to-watch-for-prop-binaries-to-load-wirelessly#latest. Usage is pretty simple: cd to the directory your code is in, run it with the IP of your WX module as an argument, and it will wait for any file with a .binary suffix in that directory (e.g., ./spinbinmon.sh 192.168.1.123). Once it sees one, it calls proploader with the IP you provided. So, in PropellerIDE, you'd make your code changes, then just hit F9 to build, instead of F10 or F11 to load to RAM/EEPROM. It's not very flexible, but for repeatedly quickly changing source and trying it out on one device, it's a usable workaround.