amforth-devel — Development discussion and user support

[Amforth-devel] [Solved] Possible problem in words/greater.asm

[Erich W. <ew....@na...>]

Just for the records:

this was a classic "layer 8" problem:

: > ~end ; \ cancel rs485 echo loops  <-- bad idea!

:-/
Erich

On 06/02/2010 11:34 AM, Erich Waelde wrote:
> Hello,
>
> I was wondering, why my simple code would stall the controller.
> Turns out that '<' and'>' behave differently, or more
> precisely, '>' (words/greater.asm) seems broken. This is in
> releases/3.8, but md5sum suggests, this file is unchanged in
>
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.3/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.4/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.5/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.6/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.7/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.8/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.9/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/trunk/core/words/greater.asm
>
> However, this could be a sideeffect from some other change ...
>
>
>   >  ver
> amforth 3.8 ATmega32 ok
>   >  : f1  1 >  if ." gt" else ." not gt" then cr ;
>    ok
>   >  : f2  1 <  if ." lt" else ." not lt" then cr ;
>    ok
>   >  4 f2
> not lt
>    ok
>   >  4 f1
> ��獊�����<-- controller stalls here
>
>
> Cheers,
> Erich
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth-devel] avra

[Ian J. <ij...@sa...>]

Just FYI,

There seems to be some activity around AVRA again and an upcoming 1.3 release.

"Thanks to Tobias Weber I'm now the project admin and integrating the patches from the mailing list and some new targets. It is already in the git repository but have to make a release. This release will also support Apple Mac OS X snow leopard Universal :-)

2010-05-11 19:50:44 UTC by jerryjacobs"

In addition there are some tools in the mailing list archives I missed to add additional part descriptors to device.c to the Assembler.  I ended up manually patching some version of AVRA (1.2.x) to support the ATMEGA169 that seemed to work although I'm not entirely sure I did it correctly.  The tcl tool works against the xml part description files.  I have not tried yet.

http://sourceforge.net/mailarchive/message.php?msg_id=44B8B018.5000604%40suprafluid.de

Sadly wine didn't (doesn't) work on my version of 64 bit FreeBSD so I ended up using Avra for amforth which seems OK.  I thought others might have the same issue.

IJ

Re: [Amforth-devel] Forthduino

[<an...@ki...>]

Just caught up with the renames/ moves etc.

This is looking good, thanks mathias. Found the Duemilanova starter 
files too.

I will get those other files out some time soon honest guys, just been 
up to my eyeballs.

Cheers

Andy Kirby

On 30/05/10 19:55, an...@ki... wrote:
> Guys
>
> Dumb question time.
>
> Why is the template for the forthduino in the /applications section
> rather than in /trunk/appl with the other development boards like the
> butterfly ??
>
> The forthduino template is'nt actually an application it is a
> development board to build an application on.
>
> In all reality anywhere is good and I am happy to go with the flow, it
> just seems a little counter intuitive.
>
> Thoughts
>
> Cheers
>
> Andy Kirby
>
>
>

Re: [Amforth-devel] Protected Amforth

[Andy K. <an...@ki...>]

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

Re: [Amforth-devel] Forthduino

[Andy K. <an...@ki...>]

At the moment yes. When isr comms and the debug led code is added in though they will have differed a little.

Has anyone had much of a play with zigbee yet ???

-- 
Like a rolling stone
----- Original message -----
> > Guys
> > 
> > Dumb question time.
> > 
> > Why is the template for the forthduino in the /applications section
> > rather than in /trunk/appl with the other development boards like the
> > butterfly ??
> 
> The application section contains all of the hardware that I cannot test
> myself.
> 
> > In all reality anywhere is good and I am happy to go with the flow, it
> > just seems a little counter intuitive.
> 
> In the meantime I've got my own arduino mega so I may move
> the code to the "right" place at trunk/appl/arduino
> 
> The various types of arduinos may be part of the game, they are
> mostly duplicates of the eval-pollin/ tree but with different build
> names.
> 
> 
> 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

Re: [Amforth-devel] Protected Amforth

[Matthias T. <mt...@we...>]

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

Re: [Amforth-devel] Forthduino

[Matthias T. <mt...@we...>]

> Guys
>
> Dumb question time.
>
> Why is the template for the forthduino in the /applications section
> rather than in /trunk/appl with the other development boards like the
> butterfly ??

The application section contains all of the hardware that I cannot test
myself.

> In all reality anywhere is good and I am happy to go with the flow, it
> just seems a little counter intuitive.

In the meantime I've got my own arduino mega so I may move
the code to the "right" place at trunk/appl/arduino

The various types of arduinos may be part of the game, they are
mostly duplicates of the eval-pollin/ tree but with different build
names.


Matthias

Re: [Amforth-devel] files for atmega644

[<an...@ki...>]

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
>

Re: [Amforth-devel] Possible problem in words/greater.asm

[Kalus M. <mic...@on...>]

Hm...:

» diele
  ok
» ver
amforth 3.6 ATmega168.forthISRoff ok
» 1 4 <
  ok
» 1 4 >
  ok
» .s
0 1195 0
1 1197 65535
  ok
» : f1  1 > if ." gt" else ." not gt" then cr ;
  ok
» : f2  1 < if ." lt" else ." not lt" then cr ;
  ok
» 4 f1
gt
  ok
» 4 f2
not lt
  ok
» 1 f1
not gt
  ok
» 1 f2
not lt
  ok
» 0 f1
not gt
  ok
» 0 f2
lt
  ok
»

Michael

[Amforth-devel] Possible problem in words/greater.asm

[Erich W. <ew....@na...>]

Hello,

I was wondering, why my simple code would stall the controller.
Turns out that '<' and '>' behave differently, or more
precisely, '>' (words/greater.asm) seems broken. This is in
releases/3.8, but md5sum suggests, this file is unchanged in

e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.3/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.4/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.5/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.6/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.7/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.8/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.9/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/trunk/core/words/greater.asm

However, this could be a sideeffect from some other change ...


 > ver
amforth 3.8 ATmega32 ok
 > : f1  1 > if ." gt" else ." not gt" then cr ;
  ok
 > : f2  1 < if ." lt" else ." not lt" then cr ;
  ok
 > 4 f2
not lt
  ok
 > 4 f1
��獊�����   <-- controller stalls here


Cheers,
Erich

Re: [Amforth-devel] Amforth 3.9 errors with ATmega128

[Andy K. <an...@ki...>]

Best advice is double check that the serial comms isr stuff rx and tx is commented out and the polled serial stuff is un commented.

After that crack open the data sheet for your device and double check the uart mnemonics for correct uart and that the a b c regisgters are being initialised to something sensible. Ie

8 bits no stop interupts disabled. Make sure mode of uart reg c is definitely async. My original template was set synchronous.

If that does,nt work i think you will probably need to mail out your device and build files so we can see what is in them.

Sorry for my email workstation is belly up and this is from my phone.

Cheers

andy kirby 

-- 
Like a rolling stone
----- Original message -----
> Hi Guys
> 
> I tried version 3.9 for my ATmega128.     I got it to compile without
> errors, but it does not display a prompt. 
> 
> Did you run across issues with the extended I/O ports? 
> 
> m128.inc:
> ; Definitions marked "MEMORY MAPPED"are extended I/O ports
> ; and cannot be used with IN/OUT instructions
> .equ    SPMCSR    = 0x68    ; MEMORY MAPPED
> 
>       change IN to LDS                   - istore_nrww.asm(109)
>       change OUT to STS                 - istore_nrww.asm(116)
> 
> I saw that Andy had to sort out issues with interupts and asynchronous,
> did these make into the core portion of the package or is that only
> apply to the ardurino?     
> 
> My results are attached if you would be so kind as to take a look.     
> 
> Thanks!
> 
> D
> 
> 
>               
<Attachment>     amforth39-ATmega128errors.txt

Re: [Amforth-devel] Amforth 3.9 errors with ATmega128

[Andy K. <an...@ki...>]

Best advice is double check that the serial comms isr stuff rx and tx is commented out and the polled serial stuff is un commented.

After that crack open the data sheet for your device and double check the uart mnemonics for correct uart and that the a b c regisgters are being initialised to something sensible. Ie

8 bits no stop interupts disabled. Make sure mode of uart reg c is definitely async. My original template was set synchronous.

If that does,nt work i think you will probably need to mail out your device and build files so we can see what is in them.

Sorry for my email workstation is belly up and this is from my phone.

Cheers

andy kirby 

-- 
Like a rolling stone
----- Original message -----
> Hi Guys
> 
> I tried version 3.9 for my ATmega128.    I got it to compile without
> errors, but it does not display a prompt. 
> 
> Did you run across issues with the extended I/O ports? 
> 
> m128.inc:
> ; Definitions marked "MEMORY MAPPED"are extended I/O ports
> ; and cannot be used with IN/OUT instructions
> .equ    SPMCSR    = 0x68    ; MEMORY MAPPED
> 
>      change IN to LDS                  - istore_nrww.asm(109)
>      change OUT to STS                - istore_nrww.asm(116)
> 
> I saw that Andy had to sort out issues with interupts and asynchronous,
> did these make into the core portion of the package or is that only
> apply to the ardurino?    
> 
> My results are attached if you would be so kind as to take a look.    
> 
> Thanks!
> 
> D
> 
> 
>              
<Attachment>    amforth39-ATmega128errors.txt

Re: [Amforth-devel] files for atmega644

[Erich W. <ew....@na...>]

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

Re: [Amforth-devel] files for atmega644

[Andy K. <an...@ki...>]

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

[Amforth-devel] files for atmega644

[Erich W. <ew....@na...>]

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

Re: [Amforth-devel] Protected Amforth

[Erich W. <ew....@na...>]

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

Re: [Amforth-devel] Protected Amforth

[Kalus M. <mic...@on...>]

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

Re: [Amforth-devel] Protected Amforth

[<an...@ki...>]

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
>

[Amforth-devel] Forthduino

[<an...@ki...>]

Guys

Dumb question time.

Why is the template for the forthduino in the /applications section 
rather than in /trunk/appl with the other development boards like the 
butterfly ??

The forthduino template is'nt actually an application it is a 
development board to build an application on.

In all reality anywhere is good and I am happy to go with the flow, it 
just seems a little counter intuitive.

Thoughts

Cheers

Andy Kirby

[Amforth-devel] Amforth 3.9 errors with ATmega128

[D W. <dou...@ya...>]

Hi Guys

I tried version 3.9 for my ATmega128.  I got it to compile without errors, but it does not display a prompt. 

Did you run across issues with the extended I/O ports? 

m128.inc:
; Definitions marked "MEMORY MAPPED"are extended I/O ports
; and cannot be used with IN/OUT instructions
.equ	SPMCSR	= 0x68	; MEMORY MAPPED

  change IN to LDS         - istore_nrww.asm(109)
  change OUT to STS        - istore_nrww.asm(116)

I saw that Andy had to sort out issues with interupts and asynchronous, did these make into the core portion of the package or is that only apply to the ardurino?  

My results are attached if you would be so kind as to take a look.  

Thanks!

D


      

Re: [Amforth-devel] Protected Amforth

[Matthias T. <mt...@we...>]

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

Re: [Amforth-devel] Protected Amforth

[Kalus M. <mic...@on...>]

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

[Amforth-devel] Protected Amforth

[<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). 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

[Amforth-devel] New release with arduino and Atmega2561

[Matthias T. <mt...@we...>]

Hi list,

I do not usually announce new version here, but this time it's
worth doing so. Andy did a great job with porting amforth to
the arduino mega platform. This and the Atmega2561 support
(it was difficult to get working) may serve as an excuse for
this mail ;=)

The files in the sourceforge file section contain pre-compiled
hex files for the forthduino (a name I like, btw).

Have fun with it, and feedback is as always very welcome.

Matthias

Re: [Amforth-devel] Image Debug

[Matthias T. <mt...@we...>]

Am 25.05.2010 16:43, schrieb an...@ki...:
> Erich, Matthias, Guys
> 
> Thanks.
> 
> I had a quick play with the installed amforth last night and it works fine.
> 
> The usual "Hello World" compiled and ran fine as well as a couple of 
> other simple words.

Great!

> Could be a useful platform for developing Amforth for larger memory devices.
> 
> I am surprised no one is selling these commercially yet.

Well, amforth works on all the controller types you mention ;=)
Maybe it's worth to deal with the un-destroyable amforth than.
I'm looking forward to get my board at hand..

> A quick question, forget does not seem to be implemented,

It was present in early versions but a few people with much
more forth experience pursuaded me that it's a bad idea. And
in fact, whith word lists it would be very hard to implement
it properly. The already mentioned marker is much better in
any respect. It's defined in one of the frt files, and it
has postpone as a pre-requisite (in another frt file).


Michael Kalus wrote (writes?) an forth_to_assembly converter
named G4 (> http://www.forth-ev.de/repos/g4/ ), that may
be useful as well, I'm sure you want to include some words
into the initial flash files that are available as forth
source only ;=)

Another way to get an re-usable flash image is create a generic
initial hex file, send a few forth source files afterwards to
the controller and read back the flash and EEPROM from the
controller, that way I prefer btw...

Matthias