amforth-devel — Development discussion and user support

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

Re: [Amforth-devel] Image Debug

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

Hi Andy,

I think you want to look at marker.  From gforth:

marker forget1  ok
: hello ." Hello One " cr ;  ok
marker forget2  ok
: hello ." Hello Two " cr ; redefined hello   ok
hello
Hello Two
  ok
forget2  ok
hello
Hello One
  ok
forget1  ok
hello
:55: Undefined word
>>>hello<<<
Backtrace:
$7FBA4EB4 throw
$7FBB1618 no.extensions
$7FBA502C interpreter-notfound1


On Tue, 25 May 2010, an...@ki... wrote:

> 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.
>
> I guess I need to tidy up the templates, sort out ISR comms and enable
> brown out detect etc.
>
> Something I noticed looking at the datasheets the 640, 1280 and 2560 are
> the same device/pinout. Implications being it is possible (with SMT
> rework) to upgrade a standard Arduino Mega to an Arduino Mega-Mega. ie
> using the 2560 instead of the smaller 1280. Same IO more memory.
>
> Could be a useful platform for developing Amforth for larger memory devices.
>
> I am surprised no one is selling these commercially yet.
>
> A quick question, forget does not seem to be implemented, how do I get
> rid of the words I compiled without a full reload ?? (There must be a
> way but at silly o'clock this morning I was'nt seeing it.)
>
> Cheers
>
> Andy Kirby
>
>
> Erich Waelde wrote:
>> Hi Andy,
>>
>> On 05/23/2010 10:59 PM, an...@ki... wrote:
>>> Guys
>>>
>>> We have a prompt at least that bit works. The issue was the USART
>>> initialization plus the fuse bits. (These look to be working as Ext
>>> 0xFF, Hi 0xD9, Lo 0xF7)
>>
>> You made it! Congrats! Getting a device up is hard, no question ...
>>
>>
>> Cheers,
>> Erich
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Amforth-devel mailing list
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>
> ---------------------------------
  ---------------------------------------------
>
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] Image Debug

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

I guess I need to tidy up the templates, sort out ISR comms and enable 
brown out detect etc.

Something I noticed looking at the datasheets the 640, 1280 and 2560 are 
the same device/pinout. Implications being it is possible (with SMT 
rework) to upgrade a standard Arduino Mega to an Arduino Mega-Mega. ie 
using the 2560 instead of the smaller 1280. Same IO more memory.

Could be a useful platform for developing Amforth for larger memory devices.

I am surprised no one is selling these commercially yet.

A quick question, forget does not seem to be implemented, how do I get 
rid of the words I compiled without a full reload ?? (There must be a 
way but at silly o'clock this morning I was'nt seeing it.)

Cheers

Andy Kirby


Erich Waelde wrote:
> Hi Andy,
> 
> On 05/23/2010 10:59 PM, an...@ki... wrote:
>> Guys
>>
>> We have a prompt at least that bit works. The issue was the USART
>> initialization plus the fuse bits. (These look to be working as Ext
>> 0xFF, Hi 0xD9, Lo 0xF7)
> 
> You made it! Congrats! Getting a device up is hard, no question ...
> 
> 
> Cheers,
> Erich
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Image Debug

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

Hi Andy,

On 05/23/2010 10:59 PM, an...@ki... wrote:
> Guys
>
> We have a prompt at least that bit works. The issue was the USART
> initialization plus the fuse bits. (These look to be working as Ext
> 0xFF, Hi 0xD9, Lo 0xF7)

You made it! Congrats! Getting a device up is hard, no question ...


Cheers,
Erich

Re: [Amforth-devel] Image Debug

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

Guys

We have a prompt at least that bit works. The issue was the USART 
initialization plus the fuse bits. (These look to be working as Ext 
0xFF, Hi 0xD9, Lo 0xF7)

Assembled and programmed I now get the amforth 3.8 ATmega 128 banner 
(Need to change this to 1280) and an ok prompt.

Don't have time tonight but in a day or so I can have a play with 
writing a bit of : script and seeing if it compiles and stores etc.

I will forward the template and device files to Mathias to go in the 
repository.

Cheers

Andy Kirby





Andy Kirby wrote:
> Just noticed the usart mode select that is being configured into usart register c is selecting synchronous when it should be asynchronous.
> 
> UMSEL does not need setting at all the default 00 is asynchronous for these. Will try it tonight at some point.
> 
> Cheers
> 
> andy kirby 
> 
> --
> Like a rolling stone
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Image Debug

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

Just noticed the usart mode select that is being configured into usart register c is selecting synchronous when it should be asynchronous.

UMSEL does not need setting at all the default 00 is asynchronous for these. Will try it tonight at some point.

Cheers

andy kirby 

--
Like a rolling stone

Re: [Amforth-devel] Image Debug

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

Yup I found the AVR fuse calculator/s today.

I will try those settings. we certainly don't want to set the boot 
vector fuse, as this causes a reset or boot to go straight to the boot 
loader section of flash. (Top of flash)

When as I understand it amforth is booting from the label just after the 
interrupt vector table at the bottom of flash. (default).

So I will get rid of that and try again.

I think taking some time to rummage through the listing file will help 
as well, as everything is ordered in there as it goes onto the device. I 
find this makes it easier for me to follow what is happening rather than 
trying to work out which files and includes are in/out and in what 
order/segments the code will end up.

Cheers

Andy Kirby







Matthias Trute wrote:
> Hi Andy,
> 
> 
> A few remarks from me (sorry, but I dont have the right
> hardware at hand and the simulator is not really helpful)
> 
> Do you know the the web avr fuse calculator?
> 
> http://www.engbedded.com/fusecalc
> 
> I just played around with it from your remarks
> 
>>>> BOD, Disabled
>>>> SPI, Enabled
>>>> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000)
>>>> Full swing osc , slow rise time with max delays
>>>>       
> 
> I stumbled across the full swing osc. The arduino schematics tells me
> there is a quartz.
> My guess for the fuses would be low 0x7f, high 0x99 and extended 0xff
> (just enter
> the values on the website to see the effects: factory default and a 16MHz
> quartz).
> 
>>  >> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000)
>> is correct though, or is it ??
>>   
> 
> The max_dict_address is the highest address the self programming
> feature can deal with. Everything above this limit is read-only for amforth.
> It's basically the same as the maximum boot loader size. But: It's not a
> bootloader, the reset has to start at address 0x0000, not at the bootloader
> start address. (to make things even more complicate: It's possible to
> move the amforth to the bootloader and turn it into an unbreakable
> system, but thats a completly different story; I would not stress it _now_).
> 
> 
>> Hmm a scope it is then, my hearing is very poor in the ultrasonic <|;)
>>   
> 
> ROTFL mine too ;=)
> 
>> That's reassuring to know. I think I want to keep this to the templates 
>> and board specific bits though. Rather than mess with the code that is 
>> common to all.
>>   
> 
> I just ordered an arduino mega, but it will take a week or two. Just
> keep the hope
> that it works. I absolutly sure it will do so.
> 
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Image Debug

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

Yup looks like the mailing list is (probably very sensibly) filtering out attachments.

Having emailed mathias direct with the attachments i was kind of hoping they would automagicaly appear in the repository as the current state of the work in progress. Mathias maybe busy thoug.

I am working at the moment so will forward on the files to anyone askin when i get in tonight.

The cheapest arduino clones i have found are the  dfrduino boards made in china. I got two mega clones from a uk importer (www.yerobot.com).

Sorry probably a bit late if you have already ordered.

Cheers 

andy kirby 
 

--
Like a rolling stone
----- Original message -----
> Duhhhh
>
> Helps if I actually attach the zip file does'nt it.
>
> an...@ki... wrote:
> > Guys
> >
> > Please find attached the current copy of the forthduino application
> > templates so far. (I wonder if we should really be calling it
> > forthduino1280, amforthduino, or amforthmegaduino or some such ??)
> >
> > There is a devices folder in there with the two device definition files.
> > I know they don't go there really.
> >
> > I put them there to get it all into an easy zip file to email. So they
> > need to come out and be put in the right place in the repository amongst
> > the core stuff.
> >
> > These are the current state of non working play.
> >
> > All tweaked to assemble with the release version of amforth using AVR
> > Studio 4.18 with no warnings or errors.
> >
> > Still no go on uart0 talking to us and doing interactive forth.
> >
> > Time to add some LED action I think.
> >
> > BTW, the amforth project docs that are on the front page of the web site
> > imply that the templates are used by copying them to \amforthxxx when
> > for the paths etc to work they need to be copied to \amforthxxx\core.
> > Again a little thing. Sorry.
> >
> > Cheers
> >
> > Andy Kirby
> >
> > PS the zip file minus the device definitions is a starter contribution
> > for the forthduino amforth app template to go in to the appl folder with
> > the other templates
> >
> >
> >
> >
> >

Re: [Amforth-devel] Image Debug

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

Hi Andy,


A few remarks from me (sorry, but I dont have the right
hardware at hand and the simulator is not really helpful)

Do you know the the web avr fuse calculator?

http://www.engbedded.com/fusecalc

I just played around with it from your remarks

>>> BOD, Disabled
>>> SPI, Enabled
>>> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000)
>>> Full swing osc , slow rise time with max delays
>>>       

I stumbled across the full swing osc. The arduino schematics tells me
there is a quartz.
My guess for the fuses would be low 0x7f, high 0x99 and extended 0xff
(just enter
the values on the website to see the effects: factory default and a 16MHz
quartz).

>  >> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000)
> is correct though, or is it ??
>   

The max_dict_address is the highest address the self programming
feature can deal with. Everything above this limit is read-only for amforth.
It's basically the same as the maximum boot loader size. But: It's not a
bootloader, the reset has to start at address 0x0000, not at the bootloader
start address. (to make things even more complicate: It's possible to
move the amforth to the bootloader and turn it into an unbreakable
system, but thats a completly different story; I would not stress it _now_).


> Hmm a scope it is then, my hearing is very poor in the ultrasonic <|;)
>   

ROTFL mine too ;=)

> That's reassuring to know. I think I want to keep this to the templates 
> and board specific bits though. Rather than mess with the code that is 
> common to all.
>   

I just ordered an arduino mega, but it will take a week or two. Just
keep the hope
that it works. I absolutly sure it will do so.

Matthias

Re: [Amforth-devel] Image Debug

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

Hi Andy,

Thought you might appreciate some feedback.  Thanks!  This is a quiet 
list usually but wonderful progress is being made on wonderful forth.

I'm a beginner but have been able to enjoy amforth.

I did not see the attachments... maybe filtered by the listserver?

On Fri, 21 May 2010, an...@ki... wrote:

> Guys
>
> Please find attached the current copy of the forthduino application
> templates so far. (I wonder if we should really be calling it
> forthduino1280, amforthduino, or amforthmegaduino or some such ??)
>

I like Arduino-Forth mainly because in my mind the Butterfly is 
Butter-Forth ... but I think the authors should have the honour of naming.

Ian

Re: [Amforth-devel] Image Debug

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

Duhhhh

Helps if I actually attach the zip file does'nt it.

an...@ki... wrote:
> Guys
> 
> Please find attached the current copy of the forthduino application 
> templates so far. (I wonder if we should really be calling it 
> forthduino1280, amforthduino, or amforthmegaduino or some such ??)
> 
> There is a devices folder in there with the two device definition files. 
> I know they don't go there really.
> 
> I put them there to get it all into an easy zip file to email. So they 
> need to come out and be put in the right place in the repository amongst 
> the core stuff.
> 
> These are the current state of non working play.
> 
> All tweaked to assemble with the release version of amforth using AVR 
> Studio 4.18 with no warnings or errors.
> 
> Still no go on uart0 talking to us and doing interactive forth.
> 
> Time to add some LED action I think.
> 
> BTW, the amforth project docs that are on the front page of the web site 
> imply that the templates are used by copying them to \amforthxxx when 
> for the paths etc to work they need to be copied to \amforthxxx\core. 
> Again a little thing. Sorry.
> 
> Cheers
> 
> Andy Kirby
> 
> PS the zip file minus the device definitions is a starter contribution 
> for the forthduino amforth app template to go in to the appl folder with 
> the other templates
> 
> 
> 
> 
> 

Re: [Amforth-devel] Image Debug

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

Guys

Please find attached the current copy of the forthduino application 
templates so far. (I wonder if we should really be calling it 
forthduino1280, amforthduino, or amforthmegaduino or some such ??)

There is a devices folder in there with the two device definition files. 
I know they don't go there really.

I put them there to get it all into an easy zip file to email. So they 
need to come out and be put in the right place in the repository amongst 
the core stuff.

These are the current state of non working play.

All tweaked to assemble with the release version of amforth using AVR 
Studio 4.18 with no warnings or errors.

Still no go on uart0 talking to us and doing interactive forth.

Time to add some LED action I think.

BTW, the amforth project docs that are on the front page of the web site 
imply that the templates are used by copying them to \amforthxxx when 
for the paths etc to work they need to be copied to \amforthxxx\core. 
Again a little thing. Sorry.

Cheers

Andy Kirby

PS the zip file minus the device definitions is a starter contribution 
for the forthduino amforth app template to go in to the appl folder with 
the other templates

Re: [Amforth-devel] Image Debug

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

Matthias Trute wrote:

> 
> You defined the usart3 as your terminal IO port. Is that really really ok?
> I had that kind of error more than often, stupid thing that.
> 

Actually that was already in the templates I copied. But I corrected 
this for references to usart0 before sending the original email. Sorry 
that wouldn't have been clear.

I guess USART3 is standard on some board or other that the template was 
drawn from ?????

The usart flags (Assembling under avr studio 4.18) also needed to have 
the usart number in the mnemonic. THis looks to be a quirk of updated 
AVR Studio device defs. It does'nt seem very efficient to me but is'nt 
mine to choose.

; initial baud rate of terminal
.equ BAUD = 9600
.equ USART_B_VALUE = (1<<TXEN0) | (1<<RXEN0) ;| (1<<RXCIE0)
.equ USART_C_VALUE = (1<<UMSEL0)|(3<<UCSZ00)

I will forward the updated templates & defs with all the tweaks etc as 
soon as I have something that is a step forward, ie it looks to be at 
least booting and responding. I did'nt think it worth sending a copy of 
them after every trial.

Cheers

Re: [Amforth-devel] Image Debug

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

OK on the notes below.

Matthias Trute wrote:
> Andy,
> 
>> Compilation is fine except for a single warning:-
>>
>> C:\Documents and 
>> settings\andy\Desktop\forthduino_3.8\core\devices/atmega1280.asm(192): 
>> warning: .cseg .db misalignment - padding zero byte
>>   
> 
> Just add a space to your mcuname string. It's not crtical however.
> 
>> At the moment I am considering the list below.
>>

fixed this.

>> 1. I missed tweaking something in the code as it comes, Mathias 
>> suggested  using polled serial comms instead of ISR's. Do I need to 
>> tweak something to make this so, or does it do it already? There may be 
>> no response from the serial link but the board may actually be running.
>>   
> 
> I just reviewed the template application files. They use the
> poll based words now. Maybe the commit diffs that can
> be viewed at
> 
> http://amforth.svn.sourceforge.net/viewvc/amforth?view=rev&revision=860
> 
> are helpful as well.
> 

Ah so, the interupt flag was'nt commented out in my template. Sorted now.

>> 2. I have got something wrong with the fuses and addresses etc and the 
>> board just is'nt running. Programing all verifies etc and is done from 
>> AVR Studio, 4.18 with an AVR ISP Mk2.
>>
>> BOD, Disabled
>> SPI, Enabled
>> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000)
>> Full swing osc , slow rise time with max delays
>>   
> 
> That is probably wrong. Just set the fuses to the factory defaults _and_
> change the osc settings _only_ . The boot fuses are not relevant here.
> 

sorted

I assume though that
 >> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000)
is correct though, or is it ??

>> 3. I have got something wrong with the hardware defs or the tweaks to 
>> the app asm file and the code just is'nt running, crashed.
>>   
> 
> You defined the usart3 as your terminal IO port. Is that really really ok?
> I had that kind of error more than often, stupid thing that.
> 
>> To help with the debugging, I need to turn on the debugging LED that is 
>> connected to port B7.
>>
>> Where and how is best to place the code?
>>   
> 
> An LED is not that useful. Place a piezo there instead. Than you
> can hear the controller working. The LED may only dim.

A piezo would work, the board already has an LED though (All Arduino 
Megas do) and no piezo, once I have a pin toggling I usually hook up my 
oscilloscope so I can see what is happening and do some easy timing 
calculations etc. On the Arduino Mega the debug LED's port is also 
brought out to an external connector. This makes life real easy.

> 
> I usually use the pause word to toggle the IO port, than I can hear
> that the controller does nothing but waiting for a keystroke. Another
> place would be the DO_NEXT label, but here you may need to
> put an count down as well since the inner interpreter is called
> very often (ultra sonic frequencies usually).
> 
> 

Hmm a scope it is then, my hearing is very poor in the ultrasonic <|;)


>> Whilst ultimately blinking would be nice for now I am happy with turn 
>> the LED on.
>>
>> I am not really looking for someone to do this for me here, just point 
>> me in the right Amforth compatible direction.
>>   
> 
> There is no such "amforth compatible direction" thing at all.

That's reassuring to know. I think I want to keep this to the templates 
and board specific bits though. Rather than mess with the code that is 
common to all.

> 
> Good luck
> Matthias
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

I will probably need it, of to play some more.

Thanks for the quick response, and guidance, much appreciated.
Hopefully disabling the UART interrupt flag and the above will be enough.

Cheers

Re: [Amforth-devel] Image Debug

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

Andy,

> Compilation is fine except for a single warning:-
>
> C:\Documents and 
> settings\andy\Desktop\forthduino_3.8\core\devices/atmega1280.asm(192): 
> warning: .cseg .db misalignment - padding zero byte
>   

Just add a space to your mcuname string. It's not crtical however.

> At the moment I am considering the list below.
>
> 1. I missed tweaking something in the code as it comes, Mathias 
> suggested  using polled serial comms instead of ISR's. Do I need to 
> tweak something to make this so, or does it do it already? There may be 
> no response from the serial link but the board may actually be running.
>   

I just reviewed the template application files. They use the
poll based words now. Maybe the commit diffs that can
be viewed at

http://amforth.svn.sourceforge.net/viewvc/amforth?view=rev&revision=860

are helpful as well.

> 2. I have got something wrong with the fuses and addresses etc and the 
> board just is'nt running. Programing all verifies etc and is done from 
> AVR Studio, 4.18 with an AVR ISP Mk2.
>
> BOD, Disabled
> SPI, Enabled
> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000)
> Full swing osc , slow rise time with max delays
>   

That is probably wrong. Just set the fuses to the factory defaults _and_
change the osc settings _only_ . The boot fuses are not relevant here.

>
> 3. I have got something wrong with the hardware defs or the tweaks to 
> the app asm file and the code just is'nt running, crashed.
>   

You defined the usart3 as your terminal IO port. Is that really really ok?
I had that kind of error more than often, stupid thing that.

>
> To help with the debugging, I need to turn on the debugging LED that is 
> connected to port B7.
>
> Where and how is best to place the code?
>   

An LED is not that useful. Place a piezo there instead. Than you
can hear the controller working. The LED may only dim.

I usually use the pause word to toggle the IO port, than I can hear
that the controller does nothing but waiting for a keystroke. Another
place would be the DO_NEXT label, but here you may need to
put an count down as well since the inner interpreter is called
very often (ultra sonic frequencies usually).


> Whilst ultimately blinking would be nice for now I am happy with turn 
> the LED on.
>
> I am not really looking for someone to do this for me here, just point 
> me in the right Amforth compatible direction.
>   

There is no such "amforth compatible direction" thing at all.

Good luck
Matthias

[Amforth-devel] Image Debug

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

Guys

I have compiled and downloaded the image for the amforth core as it 
comes, using a hand tweaked set of device defs. But cant get a squeak 
out of the board. (atmega1280, on an arduino mega clone)

Compilation is fine except for a single warning:-

C:\Documents and 
settings\andy\Desktop\forthduino_3.8\core\devices/atmega1280.asm(192): 
warning: .cseg .db misalignment - padding zero byte

ATmega1280 memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x000000 0x01e7e0   1904   5908   7812  131072   6.0%
[.dseg] 0x000200 0x000200      0      0      0    8192   0.0%
[.eseg] 0x000000 0x000040      0     64     64    4096   1.6%

Assembly complete, 0 errors. 1 warnings



At the moment I am considering the list below.

1. I missed tweaking something in the code as it comes, Mathias 
suggested  using polled serial comms instead of ISR's. Do I need to 
tweak something to make this so, or does it do it already? There may be 
no response from the serial link but the board may actually be running.

2. I have got something wrong with the fuses and addresses etc and the 
board just is'nt running. Programing all verifies etc and is done from 
AVR Studio, 4.18 with an AVR ISP Mk2.

BOD, Disabled
SPI, Enabled
Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000)
Full swing osc , slow rise time with max delays


3. I have got something wrong with the hardware defs or the tweaks to 
the app asm file and the code just is'nt running, crashed.


To help with the debugging, I need to turn on the debugging LED that is 
connected to port B7.

Where and how is best to place the code?

Where: as in it will run at boot and turn on the LED showing something 
is live. Where it can stay once I have completed and become part of the 
templates in the distribution. (not somewhere it will interfere with 
someone else's implementation of a 1280 based non arduino board, will 
blink it rather than leave it on eventualy)

How: as in, just in line assembler at the indicated spot, or do 
something that approaches the assembler approximation of forth.

40 DDRB c!
40 PORTB c!

Whilst ultimately blinking would be nice for now I am happy with turn 
the LED on.

I am not really looking for someone to do this for me here, just point 
me in the right Amforth compatible direction.

All input and advice welcome.

Cheers

Andy Kirby

Re: [Amforth-devel] Connection to host

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

Michael

That would be great.

It may (or may not) be useful to take a peak at the ICSP programming 
code for the arduino.

It can be found in the example code for V18 of the arduino IDE and is 
called ArduinoISP. This emulates the AVR ISP I think using the STK protocol.

Certainly there is a whole bunch that can be trimmed out for a more 
simple clone function ie the STK protocol and a whole bunch of the host 
comms code.

It is written in C and I am certainly not suggesting doing similar. It 
would be useful though to pull apart and understand the programming 
algorithms and bit banging etc though.

An optionally overridden check of the device ID's could be used to 
ensure that a successful clone is possible.

I was sugesting overridden because Atmel do have a habit of bringing out 
new variants of their processors that are directly compatible but have a 
different device ID. I am thinking of the "p" or low power variants 
here. ie the 644 and 644p are 100% compatible code wise from 644 => 644p.

If you already had a bunch of this covered, sorry. Not knowing I thought 
it better to contribute just in case it was of some use.

Cheers

Andy Kirby

PS off to play some more with getting amforth onto an Arduino Mega 
(ATMega1280). I have got it assembling and loading but does not yet run.

Kalus Michael wrote:
> HI.
> 
> Am 19.05.2010 um 15:01 schrieb an...@ki...:
> ..
>> There is perhaps a missed oportunity
>> to implement something like a "clone" word that will allow an amforth
>> installation to clone itself (via ICSP) to an identical but empty  
>> atmel
>> device.
> 
> Yes, a clone word should be there in amforth. I'll think about it.
> 
> Michael
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Connection to host

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

HI.

Am 19.05.2010 um 15:01 schrieb an...@ki...:
..
> There is perhaps a missed oportunity
> to implement something like a "clone" word that will allow an amforth
> installation to clone itself (via ICSP) to an identical but empty  
> atmel
> device.

Yes, a clone word should be there in amforth. I'll think about it.

Michael

Re: [Amforth-devel] Connection to host

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

Hurro Mathias & guys


> I know that amforth is difficult to use for an absolute beginner. For
> both langauge and hardware reasons. I myself had to spend a lot of
> time until my first microcontroller program did run (no, it was not
> amforth but a simple "hello world" that flashed a LED). The only
> way around I see is that those people get a pre-programmed
> chip / complete system. The arduino has it's success mainly
> because of those pre-programmed hardware ready to use.
> 
> Thinking that approach further: the amforth core system can
> reside within 8KB flash, selecting an atmega with that boot sector
> size would allow an "undestroyable" amforth system. No user
> could overwrite the forth system at will or by mistake. Well, there
> are still a few things more to do, but that would work.

There is certainly some mileage in this. I could see it working and 
giving new users a quick in.

The undestroyable idea has its merits.

I am thinking back a little here to an English company that produced 
Forth based microcontrolers TDS2020 back before flash was really 
available. Tiny EEPROM's or battery backed sram were as good as it got. 
The company was called TDS I think. Their system used Eproms and battery 
backed sram. So was along those lines. (I still have the manuals, but 
seem to have lost the boards etc.)

On getting forth onto virgin chips. There is perhaps a missed oportunity 
to implement something like a "clone" word that will allow an amforth 
installation to clone itself (via ICSP) to an identical but empty atmel 
device.

If an arduino can be used as an stk500 programmer purely from code to 
program a blank atmel microcontroler with a bootloader the clone should 
be as easily doable. Perhaps easier as it would only clone to an 
identical device.

Sure it is limited to only cloning to identical devices but it would 
give folk teaching classes a way to do forth only and bypass the fuss of 
the toolchain. Students could breadboard up an empty forth system and 
clone the core from the tutors example system or from each others.

The students could then take away their devices, as a ready to go device 
they could use at home on their own breadboard, pcb or breadboard.

cheers

Andy Kirby

[Amforth-devel] Build paths

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

Guys

Bit of a dum bunch of questions, but I have got to ask them, sorry.

Just attempting a build of amforth 3.8 under windows and avrstudio 4.12.

I have followed the guideance of the user guide and copied my template 
files into the folder \amforth3.8.

Then followed the guidance of the amforth FAQ for building under windows.

I get a number of errors which in summary amount to the template needs 
tweaking so that the paths to the amforth initial includes need prefxing 
with /core.

The build then has dificulties with the rest fo the sub includes that 
the amforth includes reference.

I am happy to tweak and hack these but looking at the amount of work you 
guys have gone to to set this up to build easily in the first instance. 
I can't help but think you probably intended it all to work a different 
way and I have missed something. (Like building from the wrong folder ???)

Just before I leap in and tweak every path to fix the build errors, can 
I have some advice ??

Cheers

Andy Kirby

[Amforth-devel] Binaries and images

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

Just some thoughts....

Is it worth considering creating (only for each full release) a set of 
binaries that are ready to program.

But only for a specifically small set of designated off the shelf boards 
and perhaps a single (Amforth Project specific) published DIY design.

It is neither desirable nor possible to turn out images for every 
variant and potential application.

I guess the aim here is to be able to give a would be Amforth newbie the 
ability to get something up to play with very quickly that could 
reinforce their interest and give them incentive to want to do more.

By buying in off the shelf or making their own starter Amforth system 
(breadboard, strip-board or home made single sided PCB) and programming 
on the image/s.

The tool-chain and compilation is of course really necessary when you 
know what you are wanting to achieve, how you will be doing it and what 
you will be doing. Both in terms of hardware and forth words. I think 
there is no doubt about this. Tailoring your end product/project is 
always going to be the best way forwards.

The objective of the suggestion is to make the first tentative steps easy.

What boards are chosen and what is in the binary images in terms of 
words, is a discussion to have if the suggestion proves to be popular...

Being able to experiment using inexpensive off the shelf boards without 
having to run up and get to grips with a full tool-chain, could be 
inviting to some.

Thoughts for what they are worth..

Cheers

Andy Kirby