What is the Propeller identifier data over serial?

Jorge P

1. What is the Propeller identifier data that is sent to a PC during Propeller detection?
2. Is this stored on the FTDI Chip, or on the propeller itself?

Mike Green

The identification sequence is complex and not describable as just some data. Here's a description from both the PC side and the Propeller side. The code to do this is stored in the Propeller's ROM.

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)

Jorge P

Thanks Mike,
Is it safe to assume that the stamps are similar? or should I ask in the Stamp forums?

I ask because in another thread I am trying to dabble in making a C# GUI that can be universal for detecting various programmable chips, and hopefully the uM-FPU and various GPS, I just wanna try the propeller first. I'd like the PC software eventualy to just detect as much as possible so it can be put into a .NET lib/dll and distributed so others can make their own GUI's compilers, tools, etc... from any language that supports .NET. Hopefully it will all work under mono too.

turbosupra

I know this is a couple of months old, did anything come of this?

I'd also like to know a way to detect which port the prop is residing on automatically.

Heater.

Beware of scanning all ports for all kinds of devices. May well upset some device as it goes along.

turbosupra

What about scanning all ports for propeller chips?

Heater. wrote: »

Beware of scanning all ports for all kinds of devices. May well upset some device as it goes along.

Unsoundcode

If you are able to incorporate the Propellant dll into your PC application it has its own identifier routine.

Jeff T.

turbosupra

Sweet, thanks I will try that

Heater.

I don't know. It has never happened to me but I have read people complaining that while some IDE or other is querying all the ports for whatever it is looking for it upsets some other system that is on some serial port.
In the case of discovering Propellers first we reset the potential prop by wiggling DTR. Well that might cause something odd to happen on some other device that is in use. Then we send a byte of $F9 which for all we know could initiate the self destruct sequence of the Big Brain for example.

Unsoundcode

Sweet, thanks I will try that

Which OS are you using and which language are you using to develop your application.

The Propellent dll uses the same method to communicate with a Prop on the system as the Proptool, if the serial port is already in use it will be ignored in the search. So basically the same communication rules apply to using the stand alone library as they do to the Proptool.

Jeff T.

turbosupra

C sharp ... I got it working but would like to have a value returned to a variable and not a messagebox.

turbosupra

Nevermind, thanks to an example from Unsoundcode, I have that working now