Question about IDE and Spin formatting

Mike Green

I've finally started writing some of my own Spin code rather than just trying the samples and demos. I find that the Spin compile behaves strangely if you don't have at least 2 blank lines between sections (VAR CON DAT PRI PUB etc). I'm not sure what's it's doing, but it seems to compile and transfer stuff to RAM and EEPROM and verify it, but things don't work. What I had done was cut and paste bits and pieces from several demos into one source file (referencing tv_text and, indirectly, tv). Not knowing better, I just left a single blank line between functions (PRI PUB). All of a sudden, what worked as a demo didn't work (meaningless behavior) when I appended some additional source that I didn't even reference. If this is the way the IDE is supposed to behave, I'd like to put in a request for some kind of error checking and a warning message.

Beau Schwabe

Mike,

Can you post the code that is giving you these results?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

SSteve

All of my propeller code has a single blank line between sections and works fine.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

links:
My band's website
Our album on the iTunes Music Store

Mike Green

Beau,
I'm not sure which version of the files is which. I'll try to nail it down. As I think about it, I was moving back and forth between a Mac editor and the Propellor Tool running under Virtual PC. Maybe the line endings had to do with it (CR,LF vs CR).

Beau Schwabe

Mike,

In your Mac under a terminal window, you should be able to use a file called unix2dos or mac2dos etc. (transversely you can also use dos2unix or dos2mac going the other way.)

From the PC end, you might need to cut and paste everything into a "generic" editor such as windows Notepad ( I would not use Word in this case ) to "clean up" the issue you
might be having with CR,LF vs CR

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Mike Green

I use a Mac editor called TextWrangler and it knows how to switch and maintain line endings for Windows and Linux. Usually if there is a problem with line endings, the text looks funny. When I copied the files over and opened them in the Propellor Tool, they looked perfectly fine and I didn't think there'd be a problem. Some programs are very happy with CR (Mac), CRLF (Windows), or LF (Linux) interchangably. TextWrangler, for example, makes a note of which line ending it sees, replaces them with some internal marker, then reconstitutes either what it saw or what you explicitly request when it updates the file.

cgracey

It shouldn't matter if there is a single carriage-return or a dozen. The compiler doesn't care. I am curious to see your code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Mike Green

Chip,
After a bit of playing around, it looks like this indeed has nothing to do with the formatting. Somehow, with a variety of programs, the IDE appears to successfully compile the program and downloads the binary either to RAM or to both RAM and EEPROM, seems to be happy with the verification cycle, yet the downloaded program just doesn't do anything expected. Sometimes repeatedly downloading the program will work. I'm concerned that the verification process doesn't catch this.
I'm using the Demo Board mounted on a BOE-BOT chassis and the USB-serial port connected to a Mac PowerBook running Windows XP Personal Edition using Virtual PC under MacOS 10.4.7 (the latest). Power is either the BOE-BOT's battery pack or an external 6V 1.5A switching wall-wart. There are 3 servos attached to the 6V line, but only one is currently activated. They're all powered, but without servo pulse input.
I'm still trying to isolate some simple change that takes the program from working to broken. It may be a problem on the Mac or Virtual PC end, but I'm still concerned that there's no error message. The data in the EEPROM must be bad because resetting the Propellor doesn't help.

Mike Green

Here we go ... The archive contains my program, a slightly modified "tv_text" and the other unmodified library references. Included are the binaries and eeprom images that work and "bomb". The program as included does work. If you uncomment the Float32Full and FloatString objects and recompile, it fails. Note that I changed FloatString to reference Float32Full rather than FloatMath. I had the same failure when I left the reference to FloatMath, but the included "bomb" binary and eeprom files use Float32Full for FloatString.