Propeller Serial Loader?

davidsaunders · 2013-09-25 08:50

I know that there used to be a thread about this though I can not find it for searching.I am looking for the details of the serial comms for loading the Propeller. There are two reasons for this, first I would like to be able to compile my Prop projects on RISC OS on my Raspbery Pi (no problem) and load it into the Prop. Second I would like to creat a couple Prop based peripherials for the Raspberry Pi and be able to reload them (using a software controled power disconect to the prop from the RPi) on with new firmware with out reprogramming the ROM.So if any one could point me in the correct direction it would be much apreciated. I knew that I should have printed out that information while it was still fresh on the forums.

Tracy Allen · 2013-09-25 09:16

Maybe you are referring to this program by Chip Gracey?
Propeller-Loader

There are also threads that depend on using the Propellent dll. For example,
PropLoader-Propeller-Firmware-Loader

davidsaunders · 2013-09-25 09:24

Not quite. There was a much older thread about the actual signalling. This is what I am after, while I could disect Chips code I would prefer to just find the thread that gives all of the details. As I remember a couple of people used the information to create a couple of loaders that did not require any specific DynaLib.My intention is to make a link from the Raspbery Pi GPIO that produces the signal in software under RISC OS. If I could find the thread this would be easy.I do remember that the link is not exactly proper serial, it just uses the timing of serial data to implement a unique protocal for data transfer. Though I do not remember the exact details.

Mike Green · 2013-09-25 09:32

Here's some information:

BOOT SEQUENCE
-------------

PC:	set 115200-8-N-1
	DTR low
	wait at least 10ms
	DTR high
	wait 100ms (+-10% tolerance)
	send $F9 (%0100111111 timing calibration)
	LFSR: taps = $B2, initialy = "P"
	send bitwise LFSR[250] ($FF/$FE)
	send $F9[250+8] for bitwise responses ($FE/$FF)
	receive bitwise LFSR[250] + version[8] within 50ms
		if timeout or mismatch, done (hardware not found error)
	send encoded command long (up to 3 bits sent per serial byte):

		0 = shutdown
		1 = load ram, then run
		2 = load ram+eeprom+verify, then shutdown
		3 = load ram+eeprom+verify, then run

		if command 0, done (okay)

	send encoded length long
	send encoded data longs
	send $F9 every 10ms for bitwise response(s):

		if command 1-3,	receive bitwise checksum pass/fail within 10(?) seconds
					if timeout, done (connection error)
					if checksum fail, done (checksum error)

		if command 1,	done (okay)

		if command 2-3,	receive bitwise program pass/fail within 5 seconds
					if timeout, done (connection error)
					if program fail, done (program error)
				receive bitwise verify pass/fail within 2 seconds
					if timeout, done (connection error)
					if verify fail, done (verify error)
				done (okay)


CHIP:	<reset>
	wait for up to 150ms @20MHz for $F9 + bitwise LFSR[250]
		if timeout or mismatch, EEBOOT

	use incoming $F9 bytes to convey bitwise LFSR[250] + version[8]

	receive encoded command[32]:

	    if command 0, 4+: SHUTDOWN

	    if command 1..3:

		receive encoded length[32]
		receive encoded data[32], dump into $0000..length<<2-1
		fill length<<2..$7FFC with $00
		write dbase @$0008 structure: long[dbase-4] = $FFF9FFFF, long[dbase-8] = $FFF9FFFF
		bytewise sum $0000..$7FFF for checksum verify
			if checksum failure, convey error on next $F9, SHUTDOWN
			else, convey okay on next $F9

		if command 1, LAUNCH

	    if command 2-3:

		program eeprom from ram
			if eeprom timeout (10ms @20MHz), convey error on 2nd $F9, SHUTDOWN
			else, convey okay on next $F9
		verify eeprom against ram
			if verify fail, convey error on 2nd $F9, program $0004 to $00 in eeprom, SHUTDOWN
			else, convey okay on next $F9

		if command 2, SHUTDOWN

		if command 3, LAUNCH


EEBOOT:		read eeprom into ram
		LAUNCH

LAUNCH:		if word at $0004 is not $0010, SHUTDOWN
		setclk(byte[15] & $78)
		wait 50ms at 20MHz
		setclk(byte[15])
		launch interpreter from $0004 in current cog

SHUTDOWN:	dira=0, setclk($01)

Note that the "encoding" mentioned involves encoding the bits into bytes or 3 bits to a byte in a self-timing fashion. The start bit of the serial channel is part of the encoding of the 1st bit. That's always low so we have either 001 or 011 for a bit cell representing a 0 or 1 respectively. If you're using one bit per byte, that's 001111111 or 011111111 including the start bit. Without the start bit, that's $FE or $FF. Packing the bits 0,1,0 into a byte gives you 001011001. Without the start bit, that's $59.

I hope this explanation is correct ... I'm doing it from memory. Correct me if I'm wrong.

davidsaunders · 2013-09-25 09:43

@Mike:Unfortunately with the new forums the text in a code block overflows everything after the post up until the end of the code listing, and as such is unreadable, also the forum ignores my CR so no way for me to seperate submited paragraphs :-( . Though I can not read your post, thank you anyway. Do you by chance know when they changed the forums to break this in NetSurf?? It used to look like it is suposed to, and work correctly.

Heater. · 2013-09-25 10:01

davisaunders,

I would like to create a couple Prop based peripherials for the Raspberry Pi and be able to reload them (using a software controled power disconect to the prop from the RPi) on with new firmware with out reprogramming the ROM

That is just the way I am heading. Except using Raspbian. To that end I have been busy building propgcc and SimpleIDE for the Raspberry Pi.
http://forums.parallax.com/showthread.php/150441-SimpIeIDE-for-Debian-%28x86%29-and-Raspbian-%28Raspberry-Pi%29

If you fetch the source code of the Propeller GCC package in there you will find a Propeller loader written in C.
https://code.google.com/p/propgcc/

No idea if that code is useful in creating a RISC OS version.

I'm curious how are you building Propeller code under RISC OS?

Heater. · 2013-09-25 10:04

davidsaunders,

...also the forum ignores my CR so no way for me to seperate submited paragraphs :-( . Though I can not read your post, thank you anyway. Do you by chance know when they changed the forums to break this in NetSurf??

It was some long while ago that the CRs stopped working for me in the Chrome browser. It's very annoying as I have to switch to Firefox to post here.

davidsaunders · 2013-09-25 10:07

@Heater:

Currently by hand one byte at a time. I am working on throughing together a simple SPIN/PASM compiler in BBC BASIC (so as to save development time), though I only work on that on spare spare time, main spare time is spent playing with other RISC OS coding, and doing real Prop stuff (coded by hand).

Heater. · 2013-09-25 10:28

davidsaunders,

Currently by hand one byte at a time

You Sir, are a rock. I take my hat off. I haven't been into that much since writing 6809 assembler in hex back in the early eighties.

There is a Propeller loader written in Python the code is here:
https://github.com/wendlers/install-propeller-toolchain/blob/master/patches/spinloader

I also attached it to this post.

Can't find the original forum post for that but there is another thread discussing a Python loader here:
http://forums.parallax.com/showthread.php/99366-Python-Downloader-modified-for-MacOS

davidsaunders · 2013-09-25 10:52

Thank you Heater, I think I can sort it out from that bit of Python. It seems as if every one is trying to get me into Python :-) I am just glad that it is easier to folow than C, or C++, though still not as easy as ARM Assembly, PASM, or SPIN.

davidsaunders · 2013-09-25 10:57

@Mike Green:

Thank you for your help, I managed to copy it out successfully (dificult with overlapping text). And it is helpful information.

Heater. · 2013-09-25 11:05

No way am I pushing Python.

I like Python and Spin but that white space block delimiting still drives me nuts.

davidsaunders · 2013-09-25 13:32

@Heater:

Thank you for the links. After folowing them, and the links in those threads (and wasting most of the afternoon :-) ) I have been able to peice togather all of the information that I needed. No more emulating windows to load a Prop :-) .

David Betz · 2013-09-25 14:11

There is also C code that Steve (jazzed) Denson wrote that is part of propeller-load that knows how to load a Propeller chip. If you'd like, I can extract that code from the propgcc repository and post it. I believe it comes with a small sample program.

davidsaunders · 2013-09-25 14:45

@David Betz:

I would apreciate that much. The more information the better, as I can not find the original thread and am down to examining a bunch of source.

David Betz · 2013-09-25 15:15

davidsaunders wrote: »

@David Betz:

I would apreciate that much. The more information the better, as I can not find the original thread and am down to examining a bunch of source.

Here it is. You can build the test program like this:

cc -o pload -DMAIN PLoadLib.c osint_linux.c

This is on the Mac or Linux. You can build it using mingw under Windows as well but you'll have to include osint_mingw.c instead of osint_linux.c.

ploadlib.zip

davidsaunders · 2013-09-25 16:09

David Betz wrote: »
Here it is. You can build the test program like this:
cc -o pload -DMAIN PLoadLib.c osint_linux.c 

:-) . A bit more work than that on RISC OS, though thank you much.
Also so that you know on RISC OS the "." charactor is a directory seperator, so dots in forign file systems are converted to "/" (so that PloadLib.c becomes PloadLib/c [PloadLib.c would refer to the file "c" in the relitive subdirectory PloadLib]). Thank you.

This is on the Mac or Linux. You can build it using mingw under Windows as well but you'll have to include osint_mingw.c instead of osint_linux.c.

ploadlib.zip

Thank you much, this will help greatly.

David Betz · 2013-09-25 17:45

davidsaunders wrote: »

:-) . A bit more work than that on RISC OS, though thank you much.
Also so that you know on RISC OS the "." charactor is a directory seperator, so dots in forign file systems are converted to "/" (so that PloadLib.c becomes PloadLib/c [PloadLib.c would refer to the file "c" in the relitive subdirectory PloadLib]). Thank you.

Ugh. Why did they do that?

Heater. · 2013-09-25 18:00

Well, RISC.OS comes from ACORN who invented the ARM chip. They just wanted to be different:)

David Betz · 2013-09-25 18:53

Heater. wrote: »

Well, RISC.OS comes from ACORN who invented the ARM chip. They just wanted to be different:)

Is it too late to shoot them? :-)

Cluso99 · 2013-09-25 20:32

Catalina has a loader "payload" that might help.
Also, recently (a month or two ago) I asked about the wireless loading to hub ram. I noticed that there are multiple resets that occur in PropTool for downloading so that does not work with what I wanted.
Chip also produced some download code for a prop to download another prop.

What I was after is to be able to download code by putting the prop into a "special program" mode so that PropTool could download a binary without actually resetting the prop. I am interested to see what you come up with because it could be an alternative to what I am trying currently.

davidsaunders · 2013-09-26 05:22

RISC OS does things as made sence. Remember this was from the mid 80s, there were no standards for that yet. Some OSes used "." as a seperator, some "/", some, "\" some "#", some "%", some ":" and a few others. Who is to say which is correct just because most OSes today use "/" that does not mean that is the only way.

Cluso99 wrote:

What I was after is to be able to download code by putting the prop into a "special program" mode so that PropTool could download a binary without actually resetting the prop. I am interested to see what you come up with because it could be an alternative to what I am trying currently.

It will just be something simple that bit bangs the Raspberry Pi's GPIO pins to load the Propeller, and it is being written in BBC BASIC V (The real version [on RISC OS the OS it is made for]), this so that I have a good WIMP (GUI in RISC OS terms) user interface, as well as a way to send it data from another task.

davidsaunders · 2013-09-26 05:23

To note:
I am still waiding through the sources, attempting to make sure that I get it 100% correct.

Heater. · 2013-09-26 05:43

davidsauders,

What's this about bit banging the Pi's GPIO pins to load the propeller? There is a perfectly good UART on the Pi's GPIO header.
That is what I have been using to download code to the Propeller with a modified version of the Propeller loader that comes with propgcc.

The only bit banging I do is to wiggle a GPIO pin to reset the Propeller. Normally we would just use DTR or CTS, one of which is also on the GPIO header but I wanted to use a pin nearby the UART Tx and Tx and I have no idea how to drive DTR anyway:)

davidsaunders · 2013-09-26 06:13

Heater. wrote: »

davidsauders,

What's this about bit banging the Pi's GPIO pins to load the propeller? There is a perfectly good UART on the Pi's GPIO header.

Well I want know that I got it correct, and beings as it is not exactly a true serial signal, bitbanging just made sence.

That is what I have been using to download code to the Propeller with a modified version of the Propeller loader that comes with propgcc.

And that works greate for you as all of the tools are written to use the Linux DeviceFS for serial IO. I will eventually redo it in Serial, though that will be after I know that it is working correctly.

The only bit banging I do is to wiggle a GPIO pin to reset the Propeller. Normally we would just use DTR or CTS, one of which is also on the GPIO header but I wanted to use a pin nearby the UART Tx and Tx and I have no idea how to drive DTR anyway:)

Yes using a GPIO is simpler. you could probe the HW directly (if you drop out of Linux and go bare metel or just start using RISC OS).

The Propeller and the RPi are a perfect match, so long as you do either Baremetel, DexOS, or RISC OS on the RPi :-) .

David Betz · 2013-09-26 06:30

What is the advantage of using RISC OS over Linux on the RaspberryPi?

Heater. · 2013-09-26 06:41

davidsaunders,

The Propeller and the RPi are a perfect match, so long as you do either Baremetel, DexOS, or RISC OS on the RPi :-) .

The Propeller and the Pi are a perfect match. However I'm not about to give up all my Debian luxuries: ssh, bash, vim,gcc, nginx, node.js, Free Pascal etc etc. If I want to do assembler, that is what the Prop is for:)

David Betz,

I have never tried RISC OS, I should, but after you have seen how slowly X runs on the Pi you might like it for it's speed. I have no idea what modern apps it might have available, like browsers and such.

David Betz · 2013-09-26 06:44

Heater. wrote: »

davidsaunders,

The Propeller and the Pi are a perfect match. However I'm not about to give up all my Debian luxuries: ssh, bash, vim,gcc, nginx, node.js, Free Pascal etc etc. If I want to do assembler, that is what the Prop is for:)

David Betz,

I have never tried RISC OS, I should, but after you have seen how slowly X runs on the Pi you might like it for it's speed. I have no idea what modern apps it might have available, like browsers and such.

I'm more of a command line guy. I probably wouldn't even try running X on a Pi (if I had one).

davidsaunders · 2013-09-26 06:52

David Betz wrote: »

What is the advantage of using RISC OS over Linux on the RaspberryPi?

Depends on your application. RISC OS is natively a single tasking system, with a cooperative multitasking layer in the WIMP that uses the MMU to swap the address space in order to run multiple tasks at the same base address. Nothing special there. The big advantages are the ability to single task where you have to, and the ability to easily get down and dirty and directly play with the Hardware with out the OS getting in the way, while you still have a good OS with a good GUI, with all of the bells and whistles of a modern OS. The only thing really lacking is a good modern web borwser, and that is an application not the OS, though NetSurf goes a long way toward correcting this (they are working on adding Java Script and HTML5 [Slow process]), and there is a 2.x version of FireFox available if you like the slow bloated stuff.

.t.

Also RISC OS runs much faster than Linux. Though I guess that this is to be expected as RISC OS is designed for the ARM specificly.

Though I would guess that for those on this forum the biggest advantage is that there are many available Assemblers, and the best ARM C compiler that runs natively on the ARM, that being Norcroft C. As well as the fact that RISC OS is very well documented, and the RPi distrobution comes with all of the documents needed to understand the entire OS. And it is possible for a single person to understand the Entire OS in detail.

:-(

Sorry for having to use code sections to create Line breaks, I do not know what was changed or when that seems to have broke the way these forums work with NetSurf.

Heater. · 2013-09-26 06:54

Did I list X under my "luxuries"

However SimpleIDE runs there OK.

David Betz · 2013-09-26 06:55

Thanks for the explanation of RISC OS. Sounds like it might be interesting to try.

Propeller Serial Loader?

Comments