Menu
▾
▴
amforth-devel
|
From: Enoch <ix...@ho...> - 2013-02-19 21:36:22
|
G'day to you to you all, I found something that seems to me useful on http://www.4e4th.eu/ WIPE ( -- ) Back to original status. Stacks unchanged. uarea back to original. Having an asm based word which restores the system into its original Amforth state, both Flash & EEPROM content, means that on-site code replacement can be done without a JTAG, etc. Comments? Thank you, Enoch. P/S Marker is not good enough: It does not restore the EEPROM. It removes itself after application. |
|
From: Michael K. <mi-...@t-...> - 2013-02-19 23:21:08
|
Hi. > Comments? :-) Michael Am 19.02.2013 um 22:36 schrieb Enoch: > G'day to you to you all, > > I found something that seems to me useful on http://www.4e4th.eu/ > > WIPE ( -- ) Back to original status. Stacks unchanged. uarea back to > original. > > Having an asm based word which restores the system into its original > Amforth state, both Flash & EEPROM content, means that on-site code > replacement can be done without a JTAG, etc. > > Comments? > > Thank you, Enoch. > > P/S Marker is not good enough: It does not restore the EEPROM. It > removes itself after application. > > > > > > ---------------------------------------------------------------------- > -------- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Enoch <ix...@ho...> - 2013-02-20 03:36:11
|
"Michael Kalus" <mi-...@t-...> writes: > Hi. > >> Comments? > > > :-) > > > > Michael > Honored to meet you, the "4e4th" guy :-) To become current with Forth I review code by other OSS Forth projects. Another that deserves attention, IMHO, is the Open Firmware <http://wiki.laptop.org/go/Open_Firmware>. In any case, we here should focus on Forth code that utilizes Atmel's AVR special features and quirks. In this connection I patiently wait for Matthias to recognize/decline my SBI/CBI utilization macros ;-) Regards, Enoch. > > > > > Am 19.02.2013 um 22:36 schrieb Enoch: > >> G'day to you to you all, >> >> I found something that seems to me useful on http://www.4e4th.eu/ >> >> WIPE ( -- ) Back to original status. Stacks unchanged. uarea back to >> original. >> >> Having an asm based word which restores the system into its original >> Amforth state, both Flash & EEPROM content, means that on-site code >> replacement can be done without a JTAG, etc. >> >> Comments? >> >> Thank you, Enoch. >> >> P/S Marker is not good enough: It does not restore the EEPROM. It >> removes itself after application. >> >> >> >> >> >> ---------------------------------------------------------------------- >> -------- >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb |
|
From: Michael K. <mi-...@t-...> - 2013-02-20 10:52:22
|
Hi Enoch. Am 20.02.2013 um 04:35 schrieb Enoch: .. > Honored to meet you, the "4e4th" guy :-) To tell the truth, most of 4e4th is Camelforth, so Brad deserves the honor. Dirk Brühl is the guy with most of the ideas that brought it onto MSP430 LaunchPad. And Ulrich Hoffmann contributed as well, such as caps and crc. So I'm the code monkey. > > To become current with Forth I review code by other OSS Forth > projects. > Another that deserves attention, IMHO, is the Open Firmware > <http://wiki.laptop.org/go/Open_Firmware>. > > In any case, we here should focus on Forth code that utilizes Atmel's > AVR special features and quirks. In this connection I patiently > wait for > Matthias to recognize/decline my SBI/CBI utilization macros ;-) I like it. Regards, Michael > > Regards, Enoch. > > >> >> >> >> >> Am 19.02.2013 um 22:36 schrieb Enoch: >> >>> G'day to you to you all, >>> >>> I found something that seems to me useful on http://www.4e4th.eu/ >>> >>> WIPE ( -- ) Back to original status. Stacks unchanged. uarea >>> back to >>> original. >>> >>> Having an asm based word which restores the system into its original >>> Amforth state, both Flash & EEPROM content, means that on-site code >>> replacement can be done without a JTAG, etc. >>> >>> Comments? >>> >>> Thank you, Enoch. >>> >>> P/S Marker is not good enough: It does not restore the EEPROM. It >>> removes itself after application. >>> >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> -------- >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_feb >>> _______________________________________________ >>> Amforth-devel mailing list for http://amforth.sf.net/ >>> Amf...@li... >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> >> >> --------------------------------------------------------------------- >> --------- >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb > > > ---------------------------------------------------------------------- > -------- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Erich W. <ew....@na...> - 2013-02-20 08:02:54
|
Hi Enoch, On 02/19/2013 10:36 PM, Enoch wrote: > G'day to you to you all, > > I found something that seems to me useful on http://www.4e4th.eu/ > > WIPE ( -- ) Back to original status. Stacks unchanged. uarea back to > original. > > Having an asm based word which restores the system into its original > Amforth state, both Flash& EEPROM content, means that on-site code > replacement can be done without a JTAG, etc. > > Comments? "the original state" is what? So WIPE needs to store a copy of the first N eeprom Bytes elsewhere (done at assembly time) and then replace eeprom, user area and thus the stack pointers as well? > Stacks unchanged strikes me as odd. > > Thank you, Enoch. > > P/S Marker is not good enough: It does not restore the EEPROM. It > removes itself after application. Well marker does not remove itself. The defined word does. </nitpick> So, do I see this right? WIPE restores a known state. This state needs to be calculated at assembly time. It includes the initial state of eeprom, wordlist and other pointers, user area, disabling tasks ... where do you stop? Does wipe call COLD as well? Do you need to clear any interrupts, too? Does it restore the default interrupt handlers? No, I did not look at the code of WIPE. Well, I'm using marker a lot. And I don't see, how wipe would get me any further. The only time I need to reflash is when I screwed up something in the dictionary before the first marker or som flash based data structures. Cheers, Erich |
|
From: Enoch <ix...@ho...> - 2013-02-20 09:16:47
|
Erich Waelde <ew....@na...> writes: > Hi Enoch, > > On 02/19/2013 10:36 PM, Enoch wrote: >> G'day to you to you all, >> >> I found something that seems to me useful on http://www.4e4th.eu/ >> >> WIPE ( -- ) Back to original status. Stacks unchanged. uarea back to >> original. >> >> Having an asm based word which restores the system into its original >> Amforth state, both Flash& EEPROM content, means that on-site code >> replacement can be done without a JTAG, etc. >> >> Comments? > > "the original state" is what? So WIPE needs to store a copy of the > first N eeprom Bytes elsewhere (done at assembly time) and then > replace eeprom, user area and thus the stack pointers as well? >> Stacks unchanged > strikes me as odd. > > >> >> Thank you, Enoch. >> >> P/S Marker is not good enough: It does not restore the EEPROM. It >> removes itself after application. > > Well marker does not remove itself. The defined word does. </nitpick> > > So, do I see this right? > WIPE restores a known state. This state needs to be calculated at > assembly time. It includes the initial state of eeprom, wordlist and > other pointers, user area, disabling tasks ... where do you stop? > Does wipe call COLD as well? Do you need to clear any interrupts, too? > Does it restore the default interrupt handlers? No, I did not look > at the code of WIPE. > > > Well, I'm using marker a lot. And I don't see, how wipe would get me > any further. The only time I need to reflash is when I screwed up > something in the dictionary before the first marker or som flash > based data structures. MARKER is great for development, and I use it as well, but it is not good enough in production situation: Let's say we are consultants and ship an Amforth based "blackbox" to a client whose firmware we loaded before shipping via JTAG. When this firmware needs a bug fix or an upgrade we must provide the client with a serial port based method of new firmware install (compiling/uploading new Forth) without the client having to open the box. 4e4th is targetting educational applications. There too there's a need for rapid "factory reset" between one student application to the next one. Regards, Enoch. > > Cheers, > Erich > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb |
|
From: Michael K. <mi-...@t-...> - 2013-02-20 11:50:34
|
Hi. Am 20.02.2013 um 10:16 schrieb Enoch: >> So, do I see this right? >> WIPE restores a known state. This state needs to be calculated at >> assembly time. Yes. >> It includes the initial state of eeprom, wordlist and >> other pointers, user area, disabling tasks ... where do you stop? >> Does wipe call COLD as well? Do you need to clear any interrupts, >> too? >> Does it restore the default interrupt handlers? No, I did not look >> at the code of WIPE. WIPE is simple in 4e4th, since it it taylored for the MSP430G2553 on LaunchPad. It just erases user flash and executes FACTORY then. FACTORY moves a ROM tabel to RAM user area, clears variable area in RAM to zero, and does a SAVE on it so that 'factory settings' is the new app, and runs into ABORT. There is no eeprom, and we do not have to take care of other MCUs. Michael >> >> >> Well, I'm using marker a lot. And I don't see, how wipe would get me >> any further. The only time I need to reflash is when I screwed up >> something in the dictionary before the first marker or som flash >> based data structures. > > MARKER is great for development, and I use it as well, but it is not > good enough in production situation: > > Let's say we are consultants and ship an Amforth based "blackbox" to a > client whose firmware we loaded before shipping via JTAG. When this > firmware needs a bug fix or an upgrade we must provide the client > with a > serial port based method of new firmware install (compiling/uploading > new Forth) without the client having to open the box. > > 4e4th is targetting educational applications. There too there's a need > for rapid "factory reset" between one student application to the next > one. Exactly. This is what we had in mind. And a recovery mechanism if a student gets locked in forth some how, has no terminal access any more, and reset does not help. Press switch S2+reset to WIPE and start over. But you have to chose 4e4thpro (pro for production) to strip S2 booting capability and use that pin for apps too. Michael > > Regards, Enoch. > > > > > > > > > > > > > >> >> Cheers, >> Erich >> >> --------------------------------------------------------------------- >> --------- >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb > > > ---------------------------------------------------------------------- > -------- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Matthias T. <mt...@we...> - 2013-02-20 18:47:21
|
Hi, > MARKER is great for development, and I use it as well, but it is not > good enough in production situation: > > Let's say we are consultants and ship an Amforth based "blackbox" to a > client whose firmware we loaded before shipping via JTAG. When this > firmware needs a bug fix or an upgrade we must provide the client with a > serial port based method of new firmware install (compiling/uploading > new Forth) without the client having to open the box. In which way would MARKER prohibit this scenario? A well designed application with in-field replaceable application code (the amforth core cannot be changed with WIPE btw) can place a strategic marker label that does all you want to do. One may want to re-check if the information, MARKER restores is sufficient, but that would be a bug in MARKER. > 4e4th is targetting educational applications. There too there's a need > for rapid "factory reset" between one student application to the next > one. An "unbreakable" amforth is possible as well. I came across this years ago but never really implemented it. It requires an atmega with an NRWW section big enough to hold the whole amforth core system. Since the NRWW section cannot be destroyd by amforth itself, there is only a copy of the EEPROM needed and a trigger that reprograms the EEPROM at boot time. Should be easy to implement. Finally: I do understand WIPE and the goals that one may want to achieve with it (IMHO its an alias for MARKER). But why on earth should this (rather complex) tool be implemented in assembly language? Matthias |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X