NO -- My thinking was have alternate Loader -- That can load Simple ASCI HEX file from any terminal program and execute it.
If You read entire Forum You will find that many people have problems with Load Propeller from all type of wireless serial communication.
With Intel HEX Loader I talk on - that problem can be resolved.
Yes, and a configured terminal can even have a tick box that uses the 'Loader+' to replace the minimal monitor, with a Use-all-of-the-gog version.
That larger version can be Chip's Message Strings + Move + Search - all those nice-to-have things, now have no base-cost.
- you would simply point to the Larger Monitor, and replace the teensy one ROM loaded. A user would need never know it happened.
One would be a 'safe superset' of the other.
You have saved RAM, and now allow the Larger/Smarter Monitor to change - Win-Win.
The features are not a problem it is the base-cost that is the problem.
One thing I can add to Yours comments are that many of Terminal programs have ---- Send TEXT file command inbuilt that simplify that Loading.
Of course, as you collect the functions you want, trialed by quick-pastes, you would make a project text file that has them all, and send that from a cold boot to confirm you have a valid project build. Any field host, can now do exactly the same.
Expanding: A pragma (comment to some, command to others) could even include an expected echo, to allow simple local operation verify/retry.
I think @Sapieha is confused about the Monitor replacing boot over serial. As far as I understand the monitor is the last in the line of duty.
So after failing to boot from serial, and failing to boot from flash the monitor gets activated if NO fuses for encryption are destroyed/set.
So there is still a normals serial boot-loader, right?
Can you please confirm this?
Enjoy!
Mike
That's correct. The Prop2 first attempts to load serially, then via flash, using a simple, but binary, protocol. If that fails, the monitor is activated.
I don't understand exactly what you are asking, but it sounds like you would like the monitor to have a restricted mode where it only allows a subset of commands to enable a verifiable download-and-execute procedure?
Not exactly.
Hi potatohead
Re: Patch
I think he's asking for an easy extension scheme. Boot monitor, "squirt the extensions over" restart, and now it's a monitor, plus some stuff.
Bet it's not hard to do once we get to play with it some.
You hit the pot!
I wanna use the entire monitor foundation "as is", plus:
- Serially transmit one or many pieces of code to Hub memory (monitor does it);
- Checksum this code to verify its integrity (monitor does it);
- If defective, retry the transmition (the retry pass/fail/count behavior is meant to be managed at the transmiting endpoint, so no work is to be done at the monitor code front)
- If the checksum is ok, send a new command (functionality to be added to the current monitor command set) to patch (under monitor control) any part of monitor code itself using partially or totaly the (already verified) code present at Hub memory; Then jump to a new entry point to get the patched code running, surely making use of most if not all the rest of the monitor.
Naturally the monitor code portions involved in the execution of this specific command are not meant to be patched (overwritten); There is the risk of disaster, disrupting program flow. Even there, with careful coding ...... might be done.
I'm looking for a way to leverage on the monitor foundation and add/change funcionalities "on the fly", with minimum time overhead.
And Prop2 threading mechanism could lead to even better results, as one can antecipate...
Having to send an entire application or an "almost the same" monitor when only minor changes from the existing one will suffice is a waste of time/resources mainly when using slow serial links.
Also, one can pack and send various "plugins" as a one time block, to be received/checked at once.
Then some "a few strokes" commands could put any part of them into Cog memory and then get it running, providing new funcionalities.
I think that this is one way to viabilize many "just out of the box" applications to be attempted, even by newbies.
Smells like Isaac Asimov's interchangeable hands robots? You bet!
One thing I can add to Yours comments are that many of Terminal programs have ---- Send TEXT file command inbuilt that simplify that Loading.
I may be wrong and I'm not being critical of you or anyone else but it seems to me that like the P1 the primary boot is via serial. My hope is that Parallax provides tools to allow this to be done easily from operating systems other than windows. This would eliminate need to upload a program from a terminal program.
I may be wrong and I'm not being critical of you or anyone else but it seems to me that like the P1 the primary boot is via serial. My hope is that Parallax provides tools to allow this to be done easily from operating systems other than windows. This would eliminate need to upload a program from a terminal program.
It is not to replace primary boot.
It is to simplify upload by wireless and other test proposes.
I like Intel hex for the same reasons and because of the rejection of bad lines it becomes an easy matter to retransmit the same file one or more times blindly to increase the chances of receiving a complete file which in this manner can be applied as a global or group broadcast to update firmware over a RS485 or wireless network.
I like Intel hex for the same reasons and because of the rejection of bad lines it becomes an easy matter to retransmit the same file one or more times blindly to increase the chances of receiving a complete file which in this manner can be applied as a global or group broadcast to update firmware over a RS485 or wireless network.
If I can add this functionality to the monitor, what should I have it do when it gets a bad checksum? Just print "Error" and beep before returning a new prompt?
If I can add this functionality to the monitor, what should I have it do when it gets a bad checksum? Just print "Error" and beep before returning a new prompt?
I like Intel hex for the same reasons and because of the rejection of bad lines it becomes an easy matter to retransmit the same file one or more times blindly to increase the chances of receiving a complete file which in this manner can be applied as a global or group broadcast to update firmware over a RS485 or wireless network.
As far as I can tell, must review the commands again, Chip's monitor allows sending of any data into any memory location and verifying a checksum on the whole thing or blocks of it as you go along. Basically everything you can do with Intel HEX.
I presume Chip's check sum is a CRC not just a simple sum as in Intel HEX. That would make Chip's solution vastly superior.
Two observations:
1) If you are loading code to a remote Prop over serial, wireless, whatever, you are going to want some intelligence in the host end to look for checksum failures and correct restart. A very short and simple script in almost any language can do that with Chips loader or Intel HEX. The fact that terminal programs allow a blind sending of a file is not much benift, it only helps if a user is operating the thing, doing the checking and reloading.
2) Chip's loader is essentially useless for loading remote Prop's if the user wants to use the code security features of the Prop. It only works if security fuses are not used and uses clear text.
3) Once you have managed to update a remote system with verified checksums it can still hang or fail when run. How do you then get to remotely repair that situation?
Edit: Loading and checksum verfication is shown by Chup in post #1510 looks good to me.
There is nothing really special about Intel hex, it's very common, which is why if it is used then you would not need "special" tools to generate the image. But for the hex loader to work the way I mentioned it requires that each line is decoded first into a 16 byte binary buffer and only loaded into it's destination memory if the checksum is good. If you get 30 bad lines out of 300 then you will probably not get the same 30 lines bad on the next repeat transmission. Repeat that again if you have a noisy channel and eventually the missing bits get filled in. It's not as bad as it sounds as it pretty much gets it first time anyway. The very worst that can happen is it will be incomplete but try, try again, and as long as some good hex lines get through it will eventually have a perfect copy. You need a final crc embedded in the file for the code block to be verified as Intel hex is very basic, and that's it. Reporting errors will accomplish little as there is little you can do about them.
The other thing I always like to build in is some form of remote reset over serial, usually in the form of a break condition, although a continuous break is more of a fault and should be ignored.
They are widely standard, easily created and merged, and the syntax allows comments/headers as a safe extension.
This makes them natural for inclusion as part of a larger host system, talking to a Prop II as an Intelligent IO, and allows self Documenting Libraries to be built up.
You could use Intel Hex and block checksum, if you had a noisy host link.
{I presume Chip's check sum is a CRC not just a simple sum as in Intel HEX. That would make Chip's solution vastly superior.}
Edit: I see the PropMon only does block checksum, not CRC )
Edit: Loading and checksum verification is shown by Chip in post #1510 looks good to me.
If someone wanted to add block checksum control, nice would be a launch-if-crc-matches
eg we have now 1000.103F^ -> 00001C98
so perhaps a command that included StartAdr, EndAdr,BlockCheckSum32,Cog ?
would work one-way, and not need compare ability on the host.
It also reduces the transactions to a field friendly 'Send one file' and check reply OK.
8 COGs
128k RAM minus ROM size = ~124k
160 MHz ??? we will see when the chip is there - IIRC
92 IOs 4 of the 96 IOs are not brought out to pins (thanks Bill Henning)
@braino - this is a looong and in parts quite interresting thread ... but 78 pages is a monster - if you just want the numbers ;-)
Earlier, someone (Chip?) mentioned the idea of using the monitor to debug/inspect another block of code. How would this work, exactly? It appears that the monitor (even the newer, smaller version) takes up nearly the entire COG memory to run, leaving little else to run in the same COG.
I would think the monitor's ability to load hex data and run it is a different use case than loading Intel HEX data and running it. The former is primarily intended for development and one-off hacking abilities, but *could* be used for more (e.g. loading entire routines, simple programming environment for the really hardcore, etc.). The Intel HEX use case (at least based on what I'm reading in the thread) is in a "production" scenario where the code that will be loaded and run will *always* be from an Intel HEX source (FPGA, host system, etc.), but *could* be used for more (e.g. loading a troubleshooting tool/monitor). If I'm understanding this correctly, wouldn't it make sense to just program an Intel HEX loader in EEPROM so that it loads instead of the monitor?
Earlier, someone (Chip?) mentioned the idea of using the monitor to debug/inspect another block of code. How would this work, exactly? It appears that the monitor (even the newer, smaller version) takes up nearly the entire COG memory to run, leaving little else to run in the same COG.
you don't need to run it in the same COG.
you can use the monitor commands to inspect and modify HUB RAM and then load part of HUB-RAM to another COG and run it there ...
and you can use the monitor in one COG to inspect what other COGs are doing in HUB RAM - nice for debugging.
kind a very very low level ... how is it called ... VIEWPORT ...
I would think the monitor's ability to load hex data and run it is a different use case than loading Intel HEX data and running it. The former is primarily intended for development and one-off hacking abilities, but *could* be used for more (e.g. loading entire routines, simple programming environment for the really hardcore, etc.). The Intel HEX use case (at least based on what I'm reading in the thread) is in a "production" scenario where the code that will be loaded and run will *always* be from an Intel HEX source (FPGA, host system, etc.), but *could* be used for more (e.g. loading a troubleshooting tool/monitor). If I'm understanding this correctly, wouldn't it make sense to just program an Intel HEX loader in EEPROM so that it loads instead of the monitor?
You can of course load anything at all, but the handler is very close to Intel Hex now, and Intel hex is a well documented standard, which allows simple scripting like this psudeo code
you don't need to run it in the same COG.
you can use the monitor commands to inspect and modify HUB RAM and then load part of HUB-RAM to another COG and run it there ...
That would be the most common usage case, but it does raise the special case question of
Can the Monitor Self-replace, and Re-Launch transparently ?
This would allow a Smarter terminal to patch the Monitor invisibly to users.
I think that might work, if the AutoBaud Period was preserved ?
you don't need to run it in the same COG.
you can use the monitor commands to inspect and modify HUB RAM and then load part of HUB-RAM to another COG and run it there ...
and you can use the monitor in one COG to inspect what other COGs are doing in HUB RAM - nice for debugging.
kind a very very low level ... how is it called ... VIEWPORT ...
That's what I thought. Except, there would be no way to start the monitor "on the fly" unless one of the running COGs has the necessary code and a method to trigger it (and it wasn't the misbehaving code you were hoping to troubleshoot with the monitor). So, while it would be possible (with deliberate effort) to use the monitor as a secondary tool, the reality is that it will only really be useful in this capacity if it's the first code to run and you manually use it to start your other code (as you indicated above).
Isn't that always a choice somebody can make? Since it's in there, launching it to watch pins, search for values, etc... can be done in parallel with any user code running.
You are right. Intel HEX is a mess. The early versions for 8 bit machines only have 16 bit addresses, not enough for the Prop II. Later versions for 16 bit and 32 bit machines extend the addressing with hacks get into that segmented memory addressing mess reflecting the brain dead architectures of 8086 and 286 class machines. And as you say endianness is unspecified. I don't want to see that ugly hack anyway near the Propellers.
Motorola S records are cleaner.
Both suffer from having only 8 bit checksums on records, At least S Records allow for a vendor specific field which can be used for an overall CRC if required.
You are right. Intel HEX is a mess. The early versions for 8 bit machines only have 16 bit addresses, not enough for the Prop II. Later versions for 16 bit and 32 bit machines extend the addressing with hacks get into that segmented memory addressing mess reflecting the brain dead architectures of 8086 and 286 class machines. And as you say endianness is unspecified. I don't want to see that ugly hack anyway near the Propellers.
Motorola S records are cleaner.
Both suffer from having only 8 bit checksums on records, At least S Records allow for a vendor specific field which can be used for an overall CRC if required.
Not too keen on either of them.
It's not about keenness or cleanness with but it is very easy to generate on just about any machine or OS I've come across. I'd be just as happy with S format too but there is probably no way I'd be trying to load more than 64K using either method! The thing is we don't want a command prompt interaction messing up wireless or half-duplex communications, we just need silent loading until done and dusted.
You are right. Intel HEX is a mess. The early versions for 8 bit machines only have 16 bit addresses, not enough for the Prop II. Later versions for 16 bit and 32 bit machines extend the addressing with hacks get into that segmented memory addressing mess reflecting the brain dead architectures of 8086 and 286 class machines. And as you say endianness is unspecified. I don't want to see that ugly hack anyway near the Propellers.
Motorola S records are cleaner.
Both suffer from having only 8 bit checksums on records, At least S Records allow for a vendor specific field which can be used for an overall CRC if required.
...no way I'd be trying to load more than 64K using either method!
Given the Prop II has almost 128K RAM to load I take it that means you don't want Intel HEX or S Record loader formats in the PROM.
...we don't want a command prompt interaction messing up wireless or half-duplex communications, we just need silent loading until done and dusted
You may want it but there is no such thing. So you hit the button, all your code gets beamed to the Prop, over whatever medium, and if successful it starts to run. But I'm sure you will want to know if it was successful and did start to run. There is your user interaction. No way around it if you want to be confident.
I conclude you might as well use Chips monitor. A simple one page script on any OS will do the job.
Reminds me of the evolution of file transfer in the CP/M days. Started out with PIP: moved on to XMODEM with some rude and crude error checking over dial up lines. Flaws in that were fixed with YMODEM and then ZMODEM. All the while what they really wanted was TCP/IP and FTP.
Comments
Yes, and a configured terminal can even have a tick box that uses the 'Loader+' to replace the minimal monitor, with a Use-all-of-the-gog version.
That larger version can be Chip's Message Strings + Move + Search - all those nice-to-have things, now have no base-cost.
- you would simply point to the Larger Monitor, and replace the teensy one ROM loaded. A user would need never know it happened.
One would be a 'safe superset' of the other.
You have saved RAM, and now allow the Larger/Smarter Monitor to change - Win-Win.
The features are not a problem it is the base-cost that is the problem.
Of course, as you collect the functions you want, trialed by quick-pastes, you would make a project text file that has them all, and send that from a cold boot to confirm you have a valid project build. Any field host, can now do exactly the same.
Expanding: A pragma (comment to some, command to others) could even include an expected echo, to allow simple local operation verify/retry.
That's correct. The Prop2 first attempts to load serially, then via flash, using a simple, but binary, protocol. If that fails, the monitor is activated.
Not exactly.
Hi potatohead
You hit the pot!
I wanna use the entire monitor foundation "as is", plus:
- Serially transmit one or many pieces of code to Hub memory (monitor does it);
- Checksum this code to verify its integrity (monitor does it);
- If defective, retry the transmition (the retry pass/fail/count behavior is meant to be managed at the transmiting endpoint, so no work is to be done at the monitor code front)
- If the checksum is ok, send a new command (functionality to be added to the current monitor command set) to patch (under monitor control) any part of monitor code itself using partially or totaly the (already verified) code present at Hub memory; Then jump to a new entry point to get the patched code running, surely making use of most if not all the rest of the monitor.
Naturally the monitor code portions involved in the execution of this specific command are not meant to be patched (overwritten); There is the risk of disaster, disrupting program flow. Even there, with careful coding ...... might be done.
I'm looking for a way to leverage on the monitor foundation and add/change funcionalities "on the fly", with minimum time overhead.
And Prop2 threading mechanism could lead to even better results, as one can antecipate...
Having to send an entire application or an "almost the same" monitor when only minor changes from the existing one will suffice is a waste of time/resources mainly when using slow serial links.
Also, one can pack and send various "plugins" as a one time block, to be received/checked at once.
Then some "a few strokes" commands could put any part of them into Cog memory and then get it running, providing new funcionalities.
I think that this is one way to viabilize many "just out of the box" applications to be attempted, even by newbies.
Smells like Isaac Asimov's interchangeable hands robots? You bet!
Yanomani
I may be wrong and I'm not being critical of you or anyone else but it seems to me that like the P1 the primary boot is via serial. My hope is that Parallax provides tools to allow this to be done easily from operating systems other than windows. This would eliminate need to upload a program from a terminal program.
It is not to replace primary boot.
It is to simplify upload by wireless and other test proposes.
If I can add this functionality to the monitor, what should I have it do when it gets a bad checksum? Just print "Error" and beep before returning a new prompt?
Simple return to Prompt are good enough.
As in time it is OK no any transmit to Terminal -- It is simple to see that transmit are incorrect.
In automated Terminal / Transmitter program it is simple to use then that PROMPT as resend command.
One good document on HEX format that even show how to declare 32 bits addresses.
You are correct.
Even if You place that system in Space -- with that system it is still possible to update it.
As far as I can tell, must review the commands again, Chip's monitor allows sending of any data into any memory location and verifying a checksum on the whole thing or blocks of it as you go along. Basically everything you can do with Intel HEX.
I presume Chip's check sum is a CRC not just a simple sum as in Intel HEX. That would make Chip's solution vastly superior.
Two observations:
1) If you are loading code to a remote Prop over serial, wireless, whatever, you are going to want some intelligence in the host end to look for checksum failures and correct restart. A very short and simple script in almost any language can do that with Chips loader or Intel HEX. The fact that terminal programs allow a blind sending of a file is not much benift, it only helps if a user is operating the thing, doing the checking and reloading.
2) Chip's loader is essentially useless for loading remote Prop's if the user wants to use the code security features of the Prop. It only works if security fuses are not used and uses clear text.
3) Once you have managed to update a remote system with verified checksums it can still hang or fail when run. How do you then get to remotely repair that situation?
Edit: Loading and checksum verfication is shown by Chup in post #1510 looks good to me.
The other thing I always like to build in is some form of remote reset over serial, usually in the form of a break condition, although a continuous break is more of a fault and should be ignored.
They are widely standard, easily created and merged, and the syntax allows comments/headers as a safe extension.
This makes them natural for inclusion as part of a larger host system, talking to a Prop II as an Intelligent IO, and allows self Documenting Libraries to be built up.
You could use Intel Hex and block checksum, if you had a noisy host link.
{I presume Chip's check sum is a CRC not just a simple sum as in Intel HEX. That would make Chip's solution vastly superior.}
Edit: I see the PropMon only does block checksum, not CRC )
If someone wanted to add block checksum control, nice would be a launch-if-crc-matches
eg we have now 1000.103F^ -> 00001C98
so perhaps a command that included StartAdr, EndAdr,BlockCheckSum32,Cog ?
would work one-way, and not need compare ability on the host.
It also reduces the transactions to a field friendly 'Send one file' and check reply OK.
my phone is too crappy to read all 78 pages of this thread, can you point me to the current definition of prop2? number of cogs, memory, clock, etc
thanks!
128k RAM minus ROM size = ~124k
160 MHz ??? we will see when the chip is there - IIRC
92 IOs 4 of the 96 IOs are not brought out to pins (thanks Bill Henning)
@braino - this is a looong and in parts quite interresting thread ... but 78 pages is a monster - if you just want the numbers ;-)
http://www.parallaxsemiconductor.com/Products/propeller2specs
See PDF at the bottom of the link above.
you can use the monitor commands to inspect and modify HUB RAM and then load part of HUB-RAM to another COG and run it there ...
and you can use the monitor in one COG to inspect what other COGs are doing in HUB RAM - nice for debugging.
kind a very very low level ... how is it called ... VIEWPORT ...
You can of course load anything at all, but the handler is very close to Intel Hex now, and Intel hex is a well documented standard, which allows simple scripting like this psudeo code
Copy Pre_Amble.SCR + CodeBlock.HEX+Post_Amble.SCR SendFile.hex
Copy SendFIle.hex Com1:
Post_Amble.SCR would include a monitor command something like
'Launch Memory from StartAdr to EndAdr in COGn IF BlockChecksum==Value
and the CodeBlock can be built locally, or a web-provided library.
Of course SendFile.hex can also be cut/pasted in an editor, or even in the Terminal
The idea should be simplicity in use, and to reduce the transactions.
Thus a single file send, should be able to Go_If_OK
That would be the most common usage case, but it does raise the special case question of
Can the Monitor Self-replace, and Re-Launch transparently ?
This would allow a Smarter terminal to patch the Monitor invisibly to users.
I think that might work, if the AutoBaud Period was preserved ?
That's what I thought. Except, there would be no way to start the monitor "on the fly" unless one of the running COGs has the necessary code and a method to trigger it (and it wasn't the misbehaving code you were hoping to troubleshoot with the monitor). So, while it would be possible (with deliberate effort) to use the monitor as a secondary tool, the reality is that it will only really be useful in this capacity if it's the first code to run and you manually use it to start your other code (as you indicated above).
Propeller Semiconductor, Inc has an up-to-date short story. Look at the links at the top of your Forum page.
If there was any commonly used file format recommended it'd have to be the S-record format as it is clear about endian-ness.
Motorola S records are cleaner.
Both suffer from having only 8 bit checksums on records, At least S Records allow for a vendor specific field which can be used for an overall CRC if required.
Not too keen on either of them.
For me it can be any format Chip write by him self.
More important -- That it works
Given the Prop II has almost 128K RAM to load I take it that means you don't want Intel HEX or S Record loader formats in the PROM.
You may want it but there is no such thing. So you hit the button, all your code gets beamed to the Prop, over whatever medium, and if successful it starts to run. But I'm sure you will want to know if it was successful and did start to run. There is your user interaction. No way around it if you want to be confident.
I conclude you might as well use Chips monitor. A simple one page script on any OS will do the job.
Reminds me of the evolution of file transfer in the CP/M days. Started out with PIP: moved on to XMODEM with some rude and crude error checking over dial up lines. Flaws in that were fixed with YMODEM and then ZMODEM. All the while what they really wanted was TCP/IP and FTP.