PDA

View Full Version : Standalone, cross-platform Propeller assembler



Cliff L. Biffle
10-23-2006, 04:53 AM
I've put my reverse engineering documentation to good use, and written an assembler for the P8X32 chips. I am currently using this for actual Propeller development.

www.cliff.biffle.org/software/propeller/propasm/ (http://www.cliff.biffle.org/software/propeller/propasm/)

Overview:
- Runs on any platform with Java available.
- Supports Parallax-format files, including all mnemonics, pseudo-ops (like CALL), and directives (like FIT).
- Command-line tool, usable from scripts or Makefiles.
- Fast.
- Will shortly be open-source (as soon as I finish slapping the GPL on all the files).

Main limitations:
- Does not support SPIN. This is an assembler, not a SPIN compiler.
- Does not yet have a linker -- programs must be in a single file. (You could easily work around this with m4/cpp.)
- There is currently no way to load the output onto the Propeller without using the Propeller Tool. I'll try to fix this shortly.
- Does not yet support expressions (e.g. 80_000_000/9600) in constants or operands. This will also be fixed.
- Does not yet have an Eclipse plugin. http://forums.parallax.com/images/smilies/smile.gif

The assembler expects input in "bare" files, devoid of SPIN-style section delimiters. Here's an example that blinks the lights on the demo board once a second:



mov DIRA, mask ' outputs
mov time, CNT
add time, cps
blink mov OUTA, mask ' high
waitcnt time, cps
mov OUTA, #0 ' los
waitcnt time, cps
jmp #blink

mask long $00FF_0000 ' light port mask
cps long 80_000_000
time res 1
fit

acantostega
10-27-2006, 11:39 AM
This is great Cliff! One more reason to learn assembly for this thing.

wastehl
10-27-2006, 02:43 PM
Hi Cliff,

What do you expect the advantages of your assembler over the Parallax product to be?

Bill

JT Cook
10-28-2006, 01:01 AM
Since this doesn't use any spin code does that mean that with this there will be access to all 8 cogs since the spin interperter won't be loaded into the first cog?

Mike Green
10-28-2006, 01:48 AM
JT,
You can have access to all 8 cogs even using SPIN to start it all up. COGINIT can start up an assembly program in the same cog that's running the SPIN interpreter, replacing it with the assembly program.

Cliff's assembler packages the assembly program with a tiny SPIN preamble that does just that.
Mike

Cliff L. Biffle
10-28-2006, 01:57 AM
Mike's dead on, as usual.

The primary advantages of propasm over the Parallax assembler are:
- It can run on non-Windows, non-x86 systems.
- It accepts identifiers in non-English character sets.
- It can be scripted from command-line tools.
- It doesn't do SPIN. (Well, I think this is an advantage. http://forums.parallax.com/images/smilies/smile.gif )

As a cleanroom project, it also doesn't have a lot of the bugs from the official assembler.

More (both the good and the bad) on this page: www.cliff.biffle.org/software/propeller/propasm/differences.html (http://www.cliff.biffle.org/software/propeller/propasm/differences.html)

cgracey
10-28-2006, 07:55 AM
Cliff L. Biffle said...
Mike's dead on, as usual.

The primary advantages of propasm over the Parallax assembler are:
- It can run on non-Windows, non-x86 systems.
- It accepts identifiers in non-English character sets.
- It can be scripted from command-line tools.
- It doesn't do SPIN. (Well, I think this is an advantage. http://forums.parallax.com/images/smilies/smile.gif )

For what you are doing, I agree, but Spin sure made it easy for me to concoct that·singing monks demo·in just a few hours, after·having spent the prior·four months writing optimized assembly code for the VocalTract and StereoSpatializer objects.

As a cleanroom project, it also doesn't have a lot of the bugs from the official assembler.

Hey,·come on! "Bugs" implies "broken" to any reader, but you're using·the term·as a·label for things you simply would have done differently. BTW, we used to allow all-sized source constants, but we had lots of customers wondering why things like·'MOV DIRA,#$00FF0000' didn't work (and then expressing disbelief that the assembler didn't catch this). So, we made the assembler·verify source constant size·(hence,·a "bug").·I can appreciate your viewpoint, but I don't want people to wrongly suppose that our assembler·is buggy, because it's not, and it took a lot of perseverence to make it so.

Stop the presses! I misunderstood what you were saying. I'm really sorry! I thought your assembler didn't error on excessive source constants, but it does! But contrary to your site, ours does, too, and has for quite some time. I thought about preventing source-only registers like INA from being utilitized as destination registers, too, but then you couldn't access the shared RAM location which might be useful for CMP operations if things ever got really tight. Your way is safer for beginners as this source-only rule has caught me a few times, even though I should know better. I like your enhancements. Those are things we should improve in our tool, too. Sorry for kind of jumping on above. Would you forgive me?

More (both the good and the bad) on this page: www.cliff.biffle.org/software/propeller/propasm/differences.html (http://www.cliff.biffle.org/software/propeller/propasm/differences.html)


My point here was to suggest that you build a serial (or USB-to-serial) loader into your assembler, so it would be totally stand-alone. You can look at the PropellerLoader object to see what is required. I'm sorry if we already talked about this and I'm not remembering. Anyway, once you have a loader built into your tool, it could go many places without the Windows hindrance. I imagine this·has got be·your goal, anyway. No·point in·preaching to the choir.

I'm glad you're working on this. I'm sure your tool will turn out nicely and I know it will make the Propeller palatable to a lot of independently-minded people who seek freedom·from Microsoft's hegemony. "May the force be with you, Cliff."
·


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


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 10/28/2006 7:37:17 AM GMT

cgracey
10-28-2006, 03:37 PM
Cliff, come back! Please see edits above in red.

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


Chip Gracey
Parallax, Inc.

Cliff L. Biffle
10-28-2006, 04:05 PM
Chip,

You're right -- Propeller Tool does indeed reject out-of-range operands. It even catches out-of-range results of expressions. I'll fix my page!

It does still allow this:



CON
x = $100
DAT
entry byte $42AA
byte $EECC
byte x




(The bytes wind up being 0xAA, 0xCC, and 0x00, respectively.)

And, yes, I do consider this a bug -- particularly that last case, where it might not even be a typo.

(My assembler has all sorts of interesting bugs as well, but writing a Forth kernel is proving an excellent stress test and I'm flushing them out as I find them.)


Chip Gracey said...
For what you are doing, I agree, but Spin sure made it easy for me to concoct that singing monks demo in just a few hours, after having spent the prior four months writing optimized assembly code for the VocalTract and StereoSpatializer objects.


I don't disagree, by any means. I'm a big believer in high-level languages -- I am just, as a matter of opinion, not a tremendous fan of SPIN.

I have, however, been using it as a test harness for some of my assembly code, since the turnaround for making changes is much faster (and my compiler doesn't work yet).


Chip Gracey said...
I thought about preventing source-only registers like INA from being utilitized as destination registers, too, but then you couldn't access the shared RAM location which might be useful for CMP operations if things ever got really tight.


By "the shared RAM location" I'm going to assume we mean PAR; correct me if I'm wrong.

Can PAR and the other read-only registers be used in the D field of rdlong/wrlong? I know (from several hours of debugging) that they don't work in the D field of CMP, for example.


Chip Gracey said...
My point here was to suggest that you build a serial (or USB-to-serial) loader into your assembler, so it would be totally stand-alone. You can look at the PropellerLoader object to see what is required. I'm sorry if we already talked about this and I'm not remembering. Anyway, once you have a loader built into your tool, it could go many places without the Windows hindrance. I imagine this has got be your goal, anyway. No point in preaching to the choir.


Yeah, you read my mind. http://forums.parallax.com/images/smilies/smile.gif

I've read the PropellerLoader code; now it's just a question of coercing a traditional UART to speak your variable-length-bit protocol. (Since the start bit gives me one bit-delay of low, it should be straightforward.) Is the Propeller picky about the timing between lows, after the initial sync pattern? The code isn't clear on this.

If it's picky, I'll have to be careful; if not, I can kick the UART into 9-data-bit mode, pack tightly, and see how fast it'll go. http://forums.parallax.com/images/smilies/smile.gif

Currently, it's proving more productive to simply finish my Forth, which will give me a Propeller-hosted interactive development environment with debugging. Plugging the board into a TV and keyboard lets me ditch both Windows and Unix. http://forums.parallax.com/images/smilies/smile.gif (I'm stuck on a serial console for now, until I get expression support in propasm.)

Edit: Should probably explain: expression support in propasm will let me link the TV driver into my Forth kernel. It relies heavily on compile-time computed constants.

Post Edited (Cliff L. Biffle) : 10/28/2006 8:09:54 AM GMT

Cliff L. Biffle
10-29-2006, 06:25 AM
propasm's source code is now available, under the GPL v2, here:

Project page: code.google.com/p/propasm/ (http://code.google.com/p/propasm/)
Source links: code.google.com/p/propasm/source (http://code.google.com/p/propasm/source)
Issue tracking: code.google.com/p/propasm/issues/list (http://code.google.com/p/propasm/issues/list)

You can browse the repository by hand, or check out the codebase using Subversion and build it. (You'll need the JDK 5, and either Apache Ant or any modern Java IDE. All other dependencies are included.)

Cliff L. Biffle
10-30-2006, 05:49 AM
Just in case anyone other than me is using propasm for real work, I've added some features and fixed several bugs.

The new features:
- New directive .align allows you to specify an alignment at any point in the source file. The assembler will pad as needed. Example:
- New directive .include allows you to textually include other files (to arbitrary depth).

All my extension directives will start with a dot, since it's syntactically illegal in Parallax's assembler. Wouldn't want to risk colliding with future Parallax extensions.

Example from my Forth kernel:



prompt byte $6F, $6B, $0D
.align long ' will pad a byte
QUIT .include "quit.paf"




Macros coming soon. http://forums.parallax.com/images/smilies/smile.gif

Mike Green
10-30-2006, 06:37 AM
Cliff,
Does the assembler automatically pad if the alignment changes like with some byte values followed by a word value?

Does the .include directive allow relative paths?

Thanks, Mike

Cliff L. Biffle
10-30-2006, 09:00 AM
Mike Green said...
Does the assembler automatically pad if the alignment changes like with some byte values followed by a word value?


Yes, but I'm also tempted to make this an optional warning when no explicit .align is present.


Mike Green said...
Does the .include directive allow relative paths?


Yes. It defaults to the cwd of the assembler (not the location of the source file) and allows both relative paths from there and absolute paths. (This is a bug; it will interpret relative paths relative to the source file in the next rev.)

Windows paths can be written using forward-slashes or doubled backslashes; single backslashes are for escape characters.

Mike Green
10-30-2006, 09:11 AM
I'd like to suggest, whenever you add optional things like this, that you have an .option directive to be able to set them in the source program if you're not planning already to do that.

Please provide an option for the binary output file to not have the SPIN preamble and a second option for the binary output file to begin at some location other than zero. I would like to be able to have assembly overlays that might load directly into a cog and would like the option to load them somewhere other than the beginning of cog memory without a lot of work.

Thanks, Mike

Mike Green
10-30-2006, 09:19 AM
Do you already have named constants? If so, what's the syntax of their declaration?

Cliff L. Biffle
10-30-2006, 03:40 PM
Mike Green said...
I'd like to suggest, whenever you add optional things like this, that you have an .option directive to be able to set them in the source program if you're not planning already to do that.


Yes; I intend to have all optional behavior controlled by directives, and optionally overridden by command-line switches.


Mike Green said...
Please provide an option for the binary output file to not have the SPIN preamble and a second option for the binary output file to begin at some location other than zero.


They're both on the list. Thanks for the input.

Since the binary format isn't sparse, I'm also considering adding a directive to pad to a particular shared-RAM address. For example, a particular part of my Forth kernel would read



.at $7380
pstack res 64




...tentatively speaking.


Mike Green said...
I would like to be able to have assembly overlays that might load directly into a cog and would like the option to load them somewhere other than the beginning of cog memory without a lot of work.


This would, of course, require code running inside the Cog to process the overlay. I'm all for it, but we'd need to specify the overlay format and a canned overlay loader sequence.


Mike Green said...
Do you already have named constants? If so, what's the syntax of their declaration?


I haven't finished the code. The syntax at the moment is



.con name value



but I'm open to suggestions.

Currently, they'll come in the same release as expression support.

Mike Green
10-30-2006, 11:04 PM
Cliff,
Thanks. FYI I'm planning on expanding my OS I2C loader to accomodate assembly overlays (since I already have the I2C read/write routines). The routines already just take an EEPROM address, HUB address, and count. I'll be adding option bits for reading and writing from COG memory with an option to jump to the block of data just loaded (and some convention for the return address) and to start a cog using a block of HUB memory just read (without the SPIN interpreter). The loader currently takes under 200 longs, so there's room for at least a 256 long overlay. I'll probably just subdivide a 32K EEPROM space into 15 x 2K or 31 x 1K areas with one area for system overhead. It'll take some real use to see whether something fancier is needed. I'll let you know. Any thoughts are welcome.
Mike

Cliff L. Biffle
10-30-2006, 11:38 PM
Mike, sounds great. Let me know when you've got the format nailed down and I'll be happy to generate it.

Chad George
10-31-2006, 04:04 AM
I've been working on a loader for a few days now. I need one to interface with Python under linux for a project I'm working on. I've been able to load programs into RAM and load programs into EEPROM.

Chip, at the risk of looking dumb I'd have to say that the PropellerLoader code didn't seem to provide me with very much insight into how to actually accomplish the task using a PCs UART and serial drivers. So I had to resort to reversing the communication between the propeller loader and the propeller chip. By recording a "conversation" and then duplicating what the propeller loaders part of the conversation was, I've been able to program a chip from both C# and Python.

My problem now is how to convert any given binary image into a stream of bytes that the propeller's bootload will understand. During the third phase of the programming sequence the body of the program is sent, but looking at what the Propeller Tool is sending this is certainly not just the bytes of the image. If anybody can help me understand how to do this I'd appreciate the help.

Also Chip if you could provide some insight into how you generate and use those LFSR bytestrings I'd appreciate it. When I recorded them they show up as 0xF9, 0xFE, 0xFF,..... and when I send these to the propeller verbatim is certainly responds correctly, but I was unable to duplicate the sequence from the code in the PropellerLoader.

Thanks,
Chad

Cliff L. Biffle
10-31-2006, 05:11 AM
Chad George said...
I've been working on a loader for a few days now. I need one to interface with Python under linux for a project I'm working on. I've been able to load programs into RAM and load programs into EEPROM.


Planning to release your code? I'd be happy to work with you (though I'm working in Java and Python gives me hives).

You're right, the PropellerLoader -- while technically being "everything we need" -- is not documentation. Give me a flow chart, spec, and timing diagram any day.

What problems are you having with the LFSR? Are you sure your taps are correct?

Chad George
10-31-2006, 06:28 AM
Cliff,

I'm certainly planning to release my code when I get it working. I'm not particularly a Python junkie myself but its appropriate for my current project (although I guess Java would be too, but I've used Python more) Once the logic of the code works it really should be trivial to get working in either language.

I guess my biggest problem with the LFSR was that I'm not entirely sure what exactly PropellerLoader was doing. I have to admit that I haven't actually run PropellerLoader for myself (has anyone else?), but looking at the code raises more questions than answers. What's the deal with the Echo and where is the serial protocol or any timing at all? Finally I kindof abandoned the idea of try to convert SPIN/Propeller code to real PC code.

I used HDD's Serial Monitor program on my PC to watch the communication between the Propeller Tool and the Propeller at the device driver level. Sure enough it follows the "general" flow of the logic shown in PropellerLoader but seems to use completely different mechanism to achieve it. Here's what I've found out so far.

First the Propeller Tool seems to open the serial port in 115200-8-N-1 mode. After toggling the DTR line to reset the Propeller, it transmits 0xF9 followed by a sequence of 0xFEs and 0xFFs. This sequence is followed by a large block of 0xF9s. I'm sure all this corresponds to the 250 iterations of the LFSR but I don't see how. When I tried to duplicate the LFSR in Python I couldn't get anything even remotely close. Then the Propeller responds with a similar (but different) block of 0xFEs and 0xFFs. Again I'm
sure this corresponds to the LFSR somehow. The Propeller then sends 2 bytes 0xFE 0xFE which I believe is the version number?

After this the Propeller Tools sends a command byte (RAM or EEPROM) followed immediately by block of data which corresponds to the binary image of the program. I haven't spent alot of time analyzing the format of the this data, but it doesn't seem to directly match up with the bytecodes of the program. Something weird is going on here and I think has to do with how the Propeller is "reading" the serial data.

Finally the Propeller Tool sends 0xF9 periodically (every 50msec seems to work) until the Propeller responds with 0xFE. This acknowledgment protocol can be repeated twice more if the command code was programming to the EEPROM.

Of course nothing that I've said is a surprise because the PropellerLoader code made it totally obvious to begin with right :)

Currently my implementation is a bit of a hack because I just embedded the LFSR transmit sequences that I recorded directly into my code and send them verbatim. I'd like to actually understand what's going on, but having it work is good enough for now.

I'm also testing with copies of the "program" data that the Propeller Tool sent while loading a chip, but I've proven that the rest of the process is independent of the program code. If I could somehow generate the correct sequence of bytes to send directly from a program binary then we'd be ready to go.

I'm at school right now so I don't have access to my source code or testing files. I'll upload them tonight when I get home for anyone who's interested.

-Chad

Mike Green
10-31-2006, 07:00 AM
Chad and Cliff,
The $F9 is the 'calibration pulse'. The start pulse is a short (one) pulse while the two zero bits in the $F9 is a long (zero) pulse. After that, the least significant bit of the LFSR is sent by the Tool, one per character, for 250 bits, with the $FF being a short (one) pulse and the $FE being a long (zero) pulse. Then the Propeller sends back the next 250 bits in the LFSR, also one bit per byte by echoing the $F9 characters, changing them to $F8 to indicate that they were processed properly.

After all the LFSR bits, the Tool and the Propeller shift into a 3 bits per byte mode with each bit cell being 3 bits and the start bit counting as one bit of the first cell (which is always zero). As you might expect, a one is a short (1 zero pulse time) and a zero is a long (2 zero pulse times) and the Propeller echos the data. There's a mix of 8 bit and 32 bit sequences, etc.

You may ask "why this mess?"

I think this protocol is to make sure there's a Propeller there. The Propeller is running off its internal fast clock which is not accurate
enough to do asynchronous serial stuff, so this is a self-clocking system initially (to set up the bit times) and never goes for more than 2 bit times (one data bit) without cleaning up the timing.

Cliff L. Biffle
10-31-2006, 11:28 AM
Chip and I have discussed the loader details, and yes, the LFSR is there to be reasonably certain we're not false-triggering on a non-Propeller device. (LFSRs come from crypto, originally, and there's a good writeup on them in Schneier's Applied Cryptography.)

Chad, I'm glad you have a protocol analyzer. The dit-dah style protocol was evident from the Spin code, but I wasn't sure how picky the Prop was going to be on bit timing. I'll write up some test code.

Chad George
10-31-2006, 02:14 PM
Mike,

Thanks for the info, it really helped everything make alot more sense.

I've been able to implement the LFSR in code rather than sending pre-recorded arrays.
Also I've been able to convert the capture program code back to the original hex code.
Of course this is backwards, but I'm definitely almost there.


-Chad

Post Edited (Chad George) : 10/31/2006 10:26:45 PM GMT

cgracey
10-31-2006, 02:47 PM
Here is some PC-side code that talks to the Propeller. It is a Delphi (Pascal) unit. It doesn't operate stand-alone, but wrapped in an application, it takes over the whole task of locating a Propeller on any COM port and then loading it up. This code packs 3 bits into outgoing bytes, for transmit efficiency.

Also attached is a small text file that was used during the chip's development as a 'contract' description between a host (PC) and the Propeller chip. It's terse, but when viewed with the Delphi code, should answer almost any quesion.



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


Chip Gracey
Parallax, Inc.

Cliff L. Biffle
10-31-2006, 11:41 PM
Chip,

Rock on. Thanks!

Haven't read a line of Delphi in nearly ten years, but I'll try to make sense of it.

Chad George
11-01-2006, 06:23 AM
Chip, Thanks for the code samples it made a huge difference.

For anyone who's interested I've finished porting Chip's code to Python.
The only non-default library required is pySerial which can be downloaded here
pyserial.sourceforge.net/ (http://pyserial.sourceforge.net/)

Like I said I basically just ported Chip's code directly to Python.

The TalkToHardware() function requires a list of bytes containing the program
to be loaded. I've included Example 1 from the Manual already in the code.
Something like this should send the program to the chip:

TalkToHardware(1, man_ex_1)


Also some people might need to change the ValidCommPorts() routine so it
returns a list of port names that make sense for the OS.

Again, thanks Chip for the documents they helped out immensely.

-Chad

Cliff L. Biffle
11-01-2006, 04:24 PM
Chad,

I've verified your loader on Mac OS X 10.4.8, using Python 2.3.5 and the FTDI-supplied serial driver. Nice work.

I disassembled the man_ex_1 byte array, and it's the standard format used by both Propeller Tool and propasm (and documented on my reverse engineering pages). Your loader should work just fine with the output from propasm.

Soon, we will have options. http://forums.parallax.com/images/smilies/smile.gif

cgracey
11-01-2006, 10:56 PM
Cliff,

I knew you didn't like Spin, but...

http://cliffhacks.blogspot.com/2006/10/propeller-spin-object-oriented-my-***.html

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


Chip Gracey
Parallax, Inc.

Cliff L. Biffle
11-01-2006, 11:46 PM
Chip,

That's no so much a reaction to SPIN as to the repeated writeups in the trade press describing it as "object oriented," when it's not. (I do note in that post that the Parallax docs don't use the term.)

However, I do tend to get too fired up about these things, and that was (in hindsight) way harsh. I've taken it down. I'll be reposting soon with a more balanced perspective.

Now it's my turn to ask forgiveness. http://forums.parallax.com/images/smilies/smile.gif

Tracy Allen
11-02-2006, 01:38 AM
Hi Cliff,

I found it harsh too, even though I am not one to say anything at all about what is and is not "object oriented". The one looming factor I see in Spin is the accomplishment of making the whole interpreter fit in 512 longs of one COG. Wow!

I appreciate what you're doing with the standalone assembler (I'm running the Prop Tool on a Mac under VPC). But I still like Spin and the fact that the assembly code is embedded in the Spin, where it is so easy to glue things, objects? methods? devices? algorithms? together.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com (http://www.emesystems.com)

Cliff L. Biffle
11-02-2006, 01:48 AM
Tracy,

I tend to be pretty picky about the usage of the term OO specifically, due to its general dilution by languages like VB and Python. (I am one of those bitter Smalltalk people.)

I really like one principal concept from Spin, and that's the component model. (Spin calls them objects; I think of them as components.) On a platform with no hardware peripherals, the ability to stitch together soft peripherals in a high-level language is very powerful.

propasm isn't intended to replace that. It's intended for people (like me) who are implementing other, non-Spin languages, or who just really want to get their hands dirty.

At Mike's request, it will soon be able to emit partial object files, intended to be loaded at certain addresses in shared RAM. This will allow propasm and Propeller Tool to live in harmony, as you'll be able to write low-level code using propasm's extended dialect, and then include it in your DAT section with a file directive.

Paul Baker
11-02-2006, 02:57 AM
Chip chose to incorporate elements of various languages into Spin when he felt it would directly benefit the development of the Propeller. It was always viewed as what would help rather than conforming to a pre-conceived notion of doing things. Some elements of object oriented programming were incorporated, but only those which directly aided the development. Unfortunately people rely on what they already know to describe something new, so terms will be used that aren't really accurate. The approach used to develop Spin will always irritate purists who like things in neat packages, but from the development aspect it really helps to be unencumbered by the baggage of the past. (How many years did Microsoft have to work around thier 640K memory limitation?)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

Post Edited (Paul Baker (Parallax)) : 11/1/2006 7:11:40 PM GMT

cgracey
11-02-2006, 04:45 AM
Cliff L. Biffle said...
Chip,

That's no so much a reaction to SPIN as to the repeated writeups in the trade press describing it as "object oriented," when it's not. (I do note in that post that the Parallax docs don't use the term.)

However, I do tend to get too fired up about these things, and that was (in hindsight) way harsh. I've taken it down. I'll be reposting soon with a more balanced perspective.

Now it's my turn to ask forgiveness. http://forums.parallax.com/images/smilies/smile.gif
No problem, Cliff.

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


Chip Gracey
Parallax, Inc.

potatohead
11-02-2006, 07:10 AM
Personally, I really am liking the environment.

This language discussion is good for all of us in that a more diverse set of tools will eventually come from it. I'm looking at the assembler at some point because I prefer a pure OSS development environment. No biggie for me, just a preference in that I want my skills tied to software that I've no worries about from a licensing point of view.

Having said that, the combination of spin and assembly is excellent. I've had my prop for about a week now. Have had a few hours to tinker with it. IMHO, the hybrid approach embodied in the language really makes it shine. A great example is the graphics functionality. With little learning curve, I was quickly able to back trace one of the included demos to the assembly code that actually builds the screen! (very cool)

With very little learning, it's completely obvious how things are put together. I'm not completely happy with how things end up in memory, but it's a non issue for me at this time. (Like to have more control over data areas and absolute locations of things)

Objects can be a mix of both and that's really powerful when dealing with smaller scale computing. That's really what the prop is all about at this time.

My initial reaction to SPIN was not too sweet. I find the syntax full of cryptic operators and shortcuts. However, this really is more about the author than the language itself. Clearer code can be written and in most instances would not affect performance to any significant degree from what I can tell at this early stage. No biggie all things considered. Once I get the operators down, reading the code and understanding what is happening will get a lot easier. It's nice to know that's really the only major obstacle where I'm concerned.

Assembly took a bit to really grok. (No registers and indexing, self modifying code everywhere sheesh!) The interaction between the COG's and HUB RAM appear less complex, but problematic if one is planning on using multiple COG's to accomplish a task. COGS could be bigger and I'd have no complaints! Again, this is where SPIN really makes a lot of things easier because it's like a wrapper for assembly that frees the developer from a lot of cruft that would otherwise get in the way of actually coding the target of interest.

So, I'm a happy prop owner right now. Love to see this evolve as the prop platform clearly will. Just thought I would toss my first impressions in.

I'm having a lot of fun and that's not happened for me in computing for a good long time!

Remy Blank
12-20-2006, 04:12 AM
Chip,


Chip Gracey (Parallax) said...
Here is some PC-side code that talks to the Propeller. It is a Delphi (Pascal) unit. It doesn't operate stand-alone, but wrapped in an application, it takes over the whole task of locating a Propeller on any COM port and then loading it up. This code packs 3 bits into outgoing bytes, for transmit efficiency.

I am trying to integrate the code upload into a tool I'm writing, and from your Delphi code, I was wondering about the following part in TalkToHardware:



// send count and longs
TLong(LongCount);
for i := 0 to LongCount-1 do TLong(PIntegerArray(@MemoryBuffer)[ i]);
TComm;
// update progress form
ProgressForm.StatusLabel.Caption := 'Verifying RAM';
ProgressForm.StatusLabel.Repaint;
// receive ram checksum pass/fail
if RBit(True, 2500) = 1 then CommError('RAM checksum error on');


More specifically, the timeout for receiving a reply after uploading the code is set to 2.5 seconds. Now, for EEPROM files (size 32768 bytes), the time it takes to send the whole data at 115200 bps with 11 bytes per long is 7.82 seconds. And indeed, measuring the time in my application, I get a total transmit time between 5.6 and 5.9 seconds (which is a bit odd, considering the fixed bitrate).

Is it possible that you rely on some Windows-specific parameters like OS buffer sizes with the timeout? I have been trying to get the Propeller Tool to work on Linux using VMware and a Win2k guest, and have had timeouts 8 times out of 10. Could this be the cause?

cgracey
12-21-2006, 11:50 AM
Remy Blank said...


Is it possible that you rely on some Windows-specific parameters like OS buffer sizes with the timeout? I have been trying to get the Propeller Tool to work on Linux using VMware and a Win2k guest, and have had timeouts 8 times out of 10. Could this be the cause?
Remy,

Gee, I had to look at the code for a while to figure out how come 2.5 seconds actually works. Here's why: The TX and RX buffer sizes were set to 256 bytes, so any time measurements were taken within the last 256 bytes transmitted.

If you have·a transmit buffer big enough for the whole download, you had better set your timeouts to accommodate the whole data set. Using a timeout of 8 seconds would do it, since it takes 11 bytes to transmit each long, of which there might be 8,192. The good thing about having shorter buffer sizes, like 256, is that you can error out faster if something's wrong. That's why it was done that way.

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


Chip Gracey
Parallax, Inc.

Remy Blank
12-21-2006, 06:08 PM
Chip Gracey (Parallax) said...
Using a timeout of 8 seconds would do it, since it takes 11 bytes to transmit each long, of which there might be 8,192. The good thing about having shorter buffer sizes, like 256, is that you can error out faster if something's wrong. That's why it was done that way.


8 seconds is what I used. It's still surprising that the actual transfers take only about 6 seconds.

Thanks for the explanation!

-- Remy

computer guy
05-13-2007, 11:46 AM
Can someone port chip's code into perl for me.

Thank you http://forums.parallax.com/images/smilies/smile.gif

bambino
05-25-2007, 10:00 PM
Thanks for the code Chip,

As usual I'm behind the Learning curve again. While I am slowly learning Delphi, Is the any reading somewhere that could help me·better understand Checksums?

I'm already looking at Wicopedia so I was hopeing for a "Checksums for Dummies" Somewhere!

M. K. Borri
05-25-2007, 11:05 PM
I'm "porting" people (college freshmen/sophomores mostly) from pBasic to Spin and what I've been doing is telling them "It works a lot like Basic, except you define your own functions like with C, and you get these nifty looking arrows to decide when an if/then block ends". That plus the bs2 library generally gets the point across in three-four days.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://forums.parallax.com/showthread.php?p=650217

meow, i have my own topic now? (sorta)

Filip S
08-02-2007, 09:22 PM
What does -Ord(i=10) return, I'm trying to port the code to Visual Basic, and I don't get it to work correctly, and I think that might be the problem.


Filip

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com

Mike Green
08-02-2007, 09:27 PM
ord() is a type conversion "function" that takes a non-integer argument and returns its equivalent as an integer. In this case, i=10 is a Boolean expression and ord(i=10) returns 0 for false and 1 for true. The overall expression "-ord(i=10)" returns -1 if i is 10 or 0 if i is not 10.

Filip S
08-03-2007, 02:23 AM
Thanks Mike, I'm going to see if it works now. (I've never used Delphi before, so I don't know all it's functions and so on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com

simonl
08-03-2007, 05:03 PM
Hi Filip,

Does this mean you're writing a VB app' that'll download a binary to the Propeller? I suer hope so, I'd love to have a copy when it's done :-)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

Roadster
08-03-2007, 07:04 PM
I don't have a vb version, but here is a C# version I found on the forum but I can't fine the thread, so here is the attachment, I could probably convert it to vb.net if anyone is interested.

Filip S
08-05-2007, 11:21 PM
Yes,simonl, I'm porting the code to VB. I'm able to check the version of the chip(1) at the moment. I've also tried to download a sample bin-file to the prop. (or should there be an EEPROM-file?), but the propeller just resets before I can get the checksum-bit, but I'm not giving up yet!

BTW, I'll post it here as soon I get it working.

I've got a little further now, I'm getting the checksum bit, but it's allways 1 (failure). How is the checksum calculated on the propeller (it's easier to debug when you've got some idea of what's gone wrong)

Filip

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com

Post Edited (Filip S) : 8/6/2007 8:35:55 AM GMT

Filip S
08-22-2007, 02:46 AM
Hello again, I've made some progress, but I still don't get the verify bit (if i get it it's 1).

But here comes a demo of the program (VB source).

Click Load prop and select a file. If you get the Unknown error it's because the verify bit isn't 0. If you get Hardware Lost Error It's because that byte is never sent. (This is what I don't get working!)

Anyway the Identify works on my demoboard (but not my 'real serial' wired·board (not USB))

//Filip


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com

Filip S
09-03-2007, 01:50 AM
Yes, It's working! (at least on my demoboard!)

Here it comes, fully functional to a demoboard (strange, but it doesn't work on a 'real' serial port yet).

The file blinker.spin is a test-file that blinks the LED's on the demoboard I used to try it out.

//Filip

EDIT: I forgot to remove some debug-code which is now fixed!

EDIT: Now it's working even with the 'real' serial ports! (sorry for all the edits!)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com

Post Edited (Filip S) : 9/2/2007 6:17:59 PM GMT

simonl
09-03-2007, 07:52 PM
Hi Filip,

WOW - can't wait to try this (Unfortunately I can't download it through the work firewall, but I'll be sure to get it this evening). THANKS http://forums.parallax.com/images/smilies/cool.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

simonl
09-08-2007, 06:47 PM
Hi Filip,
Just unzipped VBLoader and hit the identify button, but got the following error:


Run-time error '339':
Component 'MSCOMM32.OCX' or one of its dependencies not correctly registered: a file is missing or invalid

I'm using WinXP SP2; I have the VB6 run-time files installed, but I guess that means I'm missing the OCX? Would you be so kind as to·supply an installer version of VBLoader?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

Filip S
09-09-2007, 01:30 AM
I'm sorry, but I don't have the source here and I couldn't even download the file I posted(strange).

But here is the MSCOMM32.OCX-file, it should be enough to put it·in the same directory as the program, but if that doesn't work, search microsoft.com for Microsoft Comm Control or MSCOMM(32) to find an installer to the file.

//Filip

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com

Sapieha
09-10-2007, 07:13 AM
MSCOMM32.OCX

Plase it to:
C:\windows\system32\
And it works fine!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sapieha

simonl
09-10-2007, 08:28 PM
Thanks Filip / Sapieha,

Once again the work firewall blocks me, so I'll d/load it this evening.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

Filip S
09-11-2007, 01:31 AM
OK, here is the packaged version of the program!

Download the three files to a folder and run setup.exe

//Filip

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com

simonl
09-12-2007, 04:41 PM
Hi Filip,

WOW! That works excellently - many, many thanks http://forums.parallax.com/images/smilies/smile.gif

Just for info: I'm using WinXP Pro SP2, and running the setup.exe required me to restart - as it needed to change some system files. After the restart, I re-ran setup.exe, and it said several of my files were newer - so I chose to keep them (!) - and soon after that the setup completed. Running PropLoader I was immediately able to ID the prop, download to RAM, and then download to EEPROM http://forums.parallax.com/images/smilies/smile.gif

This is just the utility several forum members have been crying out for, so WELL DONE, and THANK YOU again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

simonl
02-15-2008, 08:11 AM
Hi Filip,

Been using this for a while now - what a GREAT utility. MANY MANY THANKS.

One question: are there any command-line 'switches/parameters'? I'd like to be able to call PropLoader with a filename and directive to load to RAM or EEPROM, if that's possible.

Thanks again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

Filip S
02-16-2008, 12:46 AM
Here you are! I've added a status-text too!

The interface is (add a - or a / in front of the syntax):

? Show command-line parameters

A Promts for file and mode (like the old version, also if no command-line is provided)

U'file' Prompts for mode only (looks like the old version, but you're not allowed to change the file)

R'file' Load file to RAM and run it.

E'file' Load file to EEPROM and run it.

Replace file (not the ':s) with the full path to the file.

PS. You don't need to re-install it, just replace the executable provided here.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com

simonl
02-16-2008, 06:43 PM
WHOA! You're an absolute star Filip http://forums.parallax.com/images/smilies/smile.gif Thank you very much.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

J.A.B.
02-17-2008, 02:56 AM
Lovely tool. I'm definitively gonna find some use for this. :)

In GUI mode I was a bit confused by the "Load EEPROM" checker option. To me it would be more natural to call it something like "Save/Flash/Write EEPROM".

Filip S
02-18-2008, 12:36 AM
Thanks for the kind words J.A.B.

Here is a version of the .exe which says Save to EEPROM instead of Load EEPROM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my game page: http://fgames.110mb.com

heater
05-15-2008, 11:00 PM
How can I set the clockmode and input frequency with propasm directives ?

I'm not so hot with java but looking at the source it seems to want something like:

.clkmode "xtal1"

but I just get the error:

Line 2:2: Unknown directive .clkmode

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cliff L. Biffle
05-16-2008, 01:09 AM
Wow, I go away for a couple years and my thread on cross-platform Propeller tools is now about some Windows program. Crazy stuff. http://forums.parallax.com/images/smilies/smile.gif

heater
05-16-2008, 01:26 AM
Yes, but what about propasm and how to set the clock mode ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater
05-16-2008, 04:07 AM
OK I got it.

1. Download the propasm sources from code.google.com
2. Rebuild them (after having figured out I need to install and use ant for this) the downloadable propasm.jar does not understand the clkmode directive.
3. The syntax is not as described in the sources comments but this works



.clkmode xtal1 x8
.xinfreq 10000000




The "." must not be the first character on the line.

Now a couple of other possible bugs in propasm:

1. You cannot put any code after a "fit" directive. Which is a shame because I want to put LMM code there and keep my "fit".
2. It does not like:



long #FFFFFFFF



have to use -1 instead

3. It Does not like 0-0, but I understand constant expressions were on the TODO list.

4. It does not like:


stack_bot long 0[64]



I can live with these it's just these it's just that they are differences from the Parallax assembler so my code did transfer with out attention

Otherwise it's working a treat for me.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

hinv
05-16-2008, 11:06 AM
Welcome back Cliff! I was hoping you would come back. Where have you been?
Did you play with any SeaForth chips?

Doug