Menu
▾
▴
amforth-devel
|
From: <an...@ki...> - 2010-05-26 15:48:51
|
Guys Been doing some thinking on bits of the conversations going off recently about protecting the Amforth Core from accidental overwrite. (Useful in some cases, particularly teaching scenarios and new starters). Thought I should throw them into the ring for discussion. Creating protection is as I understand it a three step process. 1. Rearrange the core words (or at least everything needed to compile and load the rest. etc into the boot-loader area as if it were a large boot-loader. 2. Tweak the interrupts and reset vectors (maybe the reset ISR too) and code to deal with the new location and prepare for a boot-loader start (That is actually the Amforth core system). This pseudo boot loader does in fact boot but doesn't pass off execution to anything unless turnkey is setup to do so. Turnkey or a rewritable template turnkey would have to live in the normal flash area so it could be rewritten if necessary. 3. Set the boot vector option in the fuses to make it boot from the top of flash (boot loader boot) rather than the bottom (Usual or non boot loader boot). Activating protection is a case of setting the appropriate fuses etc to lock down the boot-loader/upper flash area. Notes/thoughts. A. I don't think it is a good idea to issue the images and or templates with the protection activated. I have a nasty feeling invoking full protection will make it impossible to reprogram the boot-loader section ever again. Implementors may need/want to upgrade the core image and may optionally want to return their boards to service as a full arduino with the Arduino boot-loader. Particularly if they used it as a development platform and then built a dedicated Amforth board/device. B. Creating templates and images ready for protection to be optionally activated is a good idea. Documenting protection activation in a readme.txt file or the user guides etc is I think a good idea too. C. Issues I can see with this is that not all devices have as big a boot loader area. (Don't quote me on this, I could be wrong and would have to go through all the data sheets to be sure) D. It may be worth considering creating a word like "FactoryReset" or something that lives in the core/Boot-loader section and after confirmation wipes/purges/re-initializes the non core/Boot-loader section. Restoring the board/chip to a clean state. (Good for classroom scenarios and new starters) E. Making the ability to clone the current state of the device ie a "clone" word, part of the protected core/boot-loader would be optimal. There are arguments for not doing this and making it optional. Personally I favor the idea that it becomes an intrinsic part of all Amforth implementations. (Today forthduino, tomorrow the world, "Go forth and multiply" is a mangled biblical quote that springs to mind) F. Given all of the above we could be struggling in 8k of boot-loader unless something or other could me done with the current core set to make space. OK enough very poor puns on words. Thoughts for what they are worth..... Cheers Andy kirby |
|
From: Kalus M. <mic...@on...> - 2010-05-26 17:28:00
|
Hi Andy. Am 26.05.2010 um 17:48 schrieb an...@ki...: .. > D. It may be worth considering creating a word like "FactoryReset" or > something that lives in the core/Boot-loader section and after > confirmation wipes/purges/re-initializes the non core/Boot-loader > section. Restoring the board/chip to a clean state. (Good for > classroom > scenarios and new starters) For an atmega168 board based projekt here I use amforth 3.6 and added two words NEW and SAVESYSTEM to accomplish this: SAVESYSTEM copies all system vectors from eeprom into a reserved flash area. On a reset these vectors are restored, so there will be a working system in case something went wrong. NEW restores system vectors as well, but uses vectorcopies of the pure assembled amforth version. So with NEW I get rid of any tests and errors I have done after a brand new assembled amforth is flashed into the chip, while RESTORESYSTEM gives back to me the last working coopie of mforth. Those words share the headerless word POPEE as a piece of code also used in the MARKER word. Files added. So, on default reset runs through the compiles code given by appleturnkey.asm where restorsystem is executed, which is equal to NEW then. After a SAVESYSTEM a restoresystem now restores to the currently saved vector set. Michael |
|
From: Matthias T. <mt...@we...> - 2010-05-26 17:51:07
|
Am 26.05.2010 17:48, schrieb an...@ki...: > Guys > > Been doing some thinking on bits of the conversations going off recently > about protecting the Amforth Core from accidental overwrite. (Useful in > some cases, particularly teaching scenarios and new starters). Thought I > should throw them into the ring for discussion. > > Creating protection is as I understand it a three step process. > > 1. Rearrange the core words (or at least everything needed to compile > and load the rest. etc into the boot-loader area as if it were a large > boot-loader. > > 2. Tweak the interrupts and reset vectors (maybe the reset ISR too) and > code to deal with the new location and prepare for a boot-loader start > (That is actually the Amforth core system). My ideas go into the same direction. the amforth system in the bootloader section can be seen either as the "real" system or as a BIOS like utility that only checks the setup and than hand over the execution to the "real" code, which may be another amforth system or something completly different. > This pseudo boot loader does > in fact boot but doesn't pass off execution to anything unless turnkey > is setup to do so. Turnkey or a rewritable template turnkey would have > to live in the normal flash area so it could be rewritten if necessary. turnkey is a deferred word, and as such it is easy to give it new code to execute. > 3. Set the boot vector option in the fuses to make it boot from the top > of flash (boot loader boot) rather than the bottom (Usual or non boot > loader boot). thats a technical need. > > Activating protection is a case of setting the appropriate fuses etc to > lock down the boot-loader/upper flash area. The undestroyable amforth does not need to be protected with fuses (at least not per se). It is from the fact that the bootload area cannot be overwritten with anything that runs on the same controller. Just like a bootloader cannot overwrite itself. Using some fuses may be an add-on, but I doubt that it is that useful. > Notes/thoughts. > > > C. Issues I can see with this is that not all devices have as big a boot > loader area. (Don't quote me on this, I could be wrong and would have to > go through all the data sheets to be sure) thats right. Only the bigger controller types have the 8K+ bootloader section. On smaller systems, sorry. No way. > > D. It may be worth considering creating a word like "FactoryReset" or > something that lives in the core/Boot-loader section and after > confirmation wipes/purges/re-initializes the non core/Boot-loader > section. Restoring the board/chip to a clean state. (Good for classroom > scenarios and new starters) you are right, thats absolutly neccessairy. It need to reset the essential EEPROM cells as well. > E. Making the ability to clone the current state of the device ie a > "clone" word, part of the protected core/boot-loader would be optimal. I dont see the clone word in the bootloader section. Cloning a malfunctioning system image is useless. The cloning may clone the bootloader section only, the remaining flash may be transferred separatly. And putting the clone word into the normal flash area gives much more code space to make it a comfortable tool. > There are arguments for not doing this and making it optional. > Personally I favor the idea that it becomes an intrinsic part of all > Amforth implementations. (Today forthduino, tomorrow the world, "Go > forth and multiply" is a mangled biblical quote that springs to mind) It may be part of the distribution but never ever part of the default configuration. > > F. Given all of the above we could be struggling in 8k of boot-loader > unless something or other could me done with the current core set to > make space. There is still room for optimization, no doubt. But 8K is not that little space. Matthias |
|
From: <an...@ki...> - 2010-05-30 19:04:54
|
Mathias I have just been doing a comparison of a hand full of Atmegas and their boot loader/protected flash sizes. Principaly aimed at forthduino as they are mostly the types used for the most common of the arduino boards plus the sanguino (greatly favored by the maker-bot community within the reprap project) 1280, 168, 328, 644 The largest common size really is 1K. So I guess this ends up being as you suggest, bootloader/bios territory, plus as many of the primitives as can be got into the 1k. Did someone get the 168 to actualy work or do I need to put some time into this again ?? Just ordering up a duemilanove (328) for testing. I have 168's and 644's left over from reprap work and 16mhz crystals, so can bread board those. I will rename the forthduino asm file to be mega and add in definitions for Duemilanove, Deicimilla and Sanguino. A bit like the Polin boards/definitions. That should pretty much be the full set of major Arduino boards then. I can't see the point of doing any more than those. Cheers Andy Kirby On 26/05/10 18:50, Matthias Trute wrote: > Am 26.05.2010 17:48, schrieb an...@ki...: >> Guys >> >> Been doing some thinking on bits of the conversations going off recently >> about protecting the Amforth Core from accidental overwrite. (Useful in >> some cases, particularly teaching scenarios and new starters). Thought I >> should throw them into the ring for discussion. >> >> Creating protection is as I understand it a three step process. >> >> 1. Rearrange the core words (or at least everything needed to compile >> and load the rest. etc into the boot-loader area as if it were a large >> boot-loader. >> >> 2. Tweak the interrupts and reset vectors (maybe the reset ISR too) and >> code to deal with the new location and prepare for a boot-loader start >> (That is actually the Amforth core system). > > My ideas go into the same direction. the amforth system in the > bootloader section can be seen either as the "real" system or as a > BIOS like utility that only checks the setup and than hand over > the execution to the "real" code, which may be another amforth > system or something completly different. > >> This pseudo boot loader does >> in fact boot but doesn't pass off execution to anything unless turnkey >> is setup to do so. Turnkey or a rewritable template turnkey would have >> to live in the normal flash area so it could be rewritten if necessary. > > turnkey is a deferred word, and as such it is easy to give it > new code to execute. > >> 3. Set the boot vector option in the fuses to make it boot from the top >> of flash (boot loader boot) rather than the bottom (Usual or non boot >> loader boot). > > thats a technical need. > >> >> Activating protection is a case of setting the appropriate fuses etc to >> lock down the boot-loader/upper flash area. > > The undestroyable amforth does not need to be protected with fuses (at > least not per se). It is from the fact that the bootload area cannot be > overwritten with anything that runs on the same controller. Just like a > bootloader cannot overwrite itself. Using some fuses may be an add-on, > but I doubt that it is that useful. > >> Notes/thoughts. >> >> >> C. Issues I can see with this is that not all devices have as big a boot >> loader area. (Don't quote me on this, I could be wrong and would have to >> go through all the data sheets to be sure) > > thats right. Only the bigger controller types have the 8K+ bootloader > section. On smaller systems, sorry. No way. > >> >> D. It may be worth considering creating a word like "FactoryReset" or >> something that lives in the core/Boot-loader section and after >> confirmation wipes/purges/re-initializes the non core/Boot-loader >> section. Restoring the board/chip to a clean state. (Good for classroom >> scenarios and new starters) > > you are right, thats absolutly neccessairy. It need to reset the > essential EEPROM cells as well. > >> E. Making the ability to clone the current state of the device ie a >> "clone" word, part of the protected core/boot-loader would be optimal. > > I dont see the clone word in the bootloader section. Cloning a > malfunctioning system image is useless. The cloning may clone > the bootloader section only, the remaining flash may be transferred > separatly. And putting the clone word into the normal flash area gives > much more code space to make it a comfortable tool. > >> There are arguments for not doing this and making it optional. >> Personally I favor the idea that it becomes an intrinsic part of all >> Amforth implementations. (Today forthduino, tomorrow the world, "Go >> forth and multiply" is a mangled biblical quote that springs to mind) > > It may be part of the distribution but never ever part of the > default configuration. > >> >> F. Given all of the above we could be struggling in 8k of boot-loader >> unless something or other could me done with the current core set to >> make space. > > There is still room for optimization, no doubt. But 8K is not that > little space. > > Matthias > > ------------------------------------------------------------------------------ > > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Erich W. <ew....@na...> - 2010-05-31 07:09:59
|
Hi Andy > Did someone get the 168 to actualy work or do I need to put some time > into this again ?? I have a "rumpus" (http://www.lochraster.org/rumpus/) featuring an atmega168. I do have a working configuration using amforth 3.7 and using the "avra" Assembler. Please find attached a tar file with the more relevant files ./40_rumpus/Makefile ./40_rumpus/dict_appl.inc ./40_rumpus/dict_appl_core.inc ./40_rumpus/main.asm ./40_rumpus/devices/atmega168.asm ./40_rumpus/devices/atmega168.frt ./40_rumpus/devices/m168def.inc ./40_rumpus/main.fs Feel free to recycle, or ask for missing parts. Cheers, Erich |
|
From: Kalus M. <mic...@on...> - 2010-05-30 20:42:53
|
Hi Andy. Am 30.05.2010 um 21:04 schrieb an...@ki...: .. > Did someone get the 168 to actualy work or do I need to put some time > into this again ?? I use amforth 3.6 on a board called "triacmega2" (4x Triacs 220V, 4xADC) to control solar heat colecting at home. The board is used in an industrial scale as well. amforth ran right away, no probs. Well, almost: You have to have the right m168def.inc and for AVRA there at hand. I still use AVRA Version 1.2.0 Build 30 (15. October 2006) which can not handle the #<commands> in the m168def.inc file like #ifndef #endif and #pragma so I had to comment them out. My m168def.inc version is from 2005 too, still working on PowerBook G4, macOSX. The other adjusment was caused by the application: polling key and emit, excluding amforths high level interupt handling, changing emit to halfduplex. Michael |
|
From: Erich W. <ew....@na...> - 2010-05-31 07:18:27
|
Andy, I found an old (amforth 3.5) folder for the atmega644, used with the Atmel Assembler2 > I have 168's and 644's left over from reprap work and 16mhz crystals, so can bread board those. So please find attached another tar files with stuff to recycle. ./36_rs485_ws4_644/Makefile ./36_rs485_ws4_644/dict_appl.inc ./36_rs485_ws4_644/dict_appl_core.inc ./36_rs485_ws4_644/main.asm ./36_rs485_ws4_644/devices/atmega644.asm ./36_rs485_ws4_644/devices/atmega644.frt ./36_rs485_ws4_644/devices/m644def.inc ./36_rs485_ws4_644/main.fs ./36_rs485_ws4_644/main.fs.unfold No promises, on how good this is though ... Cheers, Erich |
|
From: Andy K. <an...@ki...> - 2010-05-31 07:57:53
|
Hmmmmmm rs485 interesting thats on my list of things to do one day. A lightweight 485lan using the multidrop features of the atmel uart. Thanks i'll have a rummage through the files and recycle as a start point. Cheers andy kirby -- Like a rolling stone ----- Original message ----- > Andy, > > I found an old (amforth 3.5) folder for the atmega644, used with > the Atmel Assembler2 > > > I have 168's and 644's left over from reprap work and 16mhz crystals, > > so can bread board those. > > > So please find attached another tar files with stuff to recycle. > ./36_rs485_ws4_644/Makefile > ./36_rs485_ws4_644/dict_appl.inc > ./36_rs485_ws4_644/dict_appl_core.inc > ./36_rs485_ws4_644/main.asm > ./36_rs485_ws4_644/devices/atmega644.asm > ./36_rs485_ws4_644/devices/atmega644.frt > ./36_rs485_ws4_644/devices/m644def.inc > ./36_rs485_ws4_644/main.fs > ./36_rs485_ws4_644/main.fs.unfold > > No promises, on how good this is though ... > > Cheers, > Erich |
|
From: Erich W. <ew....@na...> - 2010-05-31 12:00:49
|
On 05/31/2010 10:04 AM, Andy Kirby wrote: > Hmmmmmm > > rs485 interesting thats on my list of things to do one day. > A lightweight 485lan using the multidrop features of the atmel uart. The rs485 part was shamelessly stolen from Lubos: http://www.forth.cz I'm using this for my stuff with modest success ... Cheers, Erich |
|
From: <an...@ki...> - 2010-06-03 14:30:22
|
Erich Thanks for that, I can read the forth on Lubos site but struggle with the eastern european. Checkoslovakian ?? With the 485 I have always been a little concerned about the overhead of microcontrolers following a data stream of which only a fraction is addressed for the controler. Reading through the Atmegas usarts there is an additional 9 bit mode that allows the usart to ignore traffic that is'nt addressed for the microcontroler in question. Good for reducing unnecesary interupts etc. I think this could be useful. Cheers Andy Kirby On 31/05/10 13:00, Erich Waelde wrote: > On 05/31/2010 10:04 AM, Andy Kirby wrote: >> Hmmmmmm >> >> rs485 interesting thats on my list of things to do one day. >> A lightweight 485lan using the multidrop features of the atmel uart. > > > The rs485 part was shamelessly stolen from Lubos: > http://www.forth.cz > > I'm using this for my stuff with modest success ... > > Cheers, > Erich > |
|
From: Matthias T. <mt...@we...> - 2010-06-07 14:02:34
|
Hi Andy, > Did someone get the 168 to actualy work or do I need to put some time > into this again ?? All systems mentioned in the core/devices directory should work without trouble. > I will rename the forthduino asm file to be mega and add in definitions > for Duemilanove, Deicimilla and Sanguino. A bit like the Polin > boards/definitions. That should pretty much be the full set of major > Arduino boards then. I can't see the point of doing any more than those. I agree with you that the arduino boards are (now) much better suited as a starting point than the pollins. But the pollin's are cheaper (at least for me ;=) ). And they can be used for a any controller that is still available in the PDIP format (no SMD) That makes porting amforth much easier. forthduino may serve as the toplevel name for various implementations since they are no longer real arduino's. But: IANAL I do not want to get any legal trouble Matthias |
|
From: Andy K. <an...@ki...> - 2010-06-07 14:45:27
|
Ok what would you rather name them ??? I am not too hung up on names. I agree that the prpject needs to protect itself from fuss. -- Like a rolling stone ----- Original message ----- > Hi Andy, > > > Did someone get the 168 to actualy work or do I need to put some time > > into this again ?? > > All systems mentioned in the core/devices directory should work > without trouble. > > > I will rename the forthduino asm file to be mega and add in definitions > > for Duemilanove, Deicimilla and Sanguino. A bit like the Polin > > boards/definitions. That should pretty much be the full set of major > > Arduino boards then. I can't see the point of doing any more than > > those. > > I agree with you that the arduino boards are (now) much better suited as > a starting point than the pollins. But the pollin's are cheaper (at least > for me ;=) ). And they can be used for a any controller that is still > available > in the PDIP format (no SMD) That makes porting amforth much easier. > > forthduino may serve as the toplevel name for various implementations > since they are no longer real arduino's. But: IANAL I do not want to get > any legal trouble > > > > Matthias > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
×
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