What is the Propeller identifier data over serial?
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?
2. Is this stored on the FTDI Chip, or on the propeller itself?
Comments
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)
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.
I'd also like to know a way to detect which port the prop is residing on automatically.
Jeff T.
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.
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.