amforth-devel — Development discussion and user support

Re: [Amforth] Help using second uart

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

Hello David,
welcome to the club!

On 10/25/2012 08:17 PM, David Wallis wrote:
> Hi all,
> 
> Sorry for using this list for help, but I'm not sure where else to go. I am
> new to Forth (although I've been aware of it since the days of the Jupiter
> Ace when I was at school!), but I have an AVR project to do and I thought
> I'd give amforth a try.
> 
> My question is, is there an easy way of using a second (hardware) uart with
> amforth? I am using an atmega324pu. I have amforth running on it nicely and
> I can communicate with usart1 in Forth very simply by setting it up and
> reading/writing UDR1. But I'd like interrupt driven RX on uart1. I can
> implement this by hand (I've done it before in C) if I have to, but is
> there an easier/cleaner way? Has it already been implemented? If so, can
> anyone point me (in Forth newbie language) in the direction of how to do it?

I'm not sure, if I understand your question correctly.
a. are you trying to use usart1 instead of usart0? Or
b. are you trying to use both usart1 and usart0 "simultaneously"?


If you just want to move the connection to usart1 then there
is a line in template.asm:

; define which usart to use.
.include "drivers/usart_0.asm"
------------------------^
If you change that to usart_1.asm, you should be all set.
If that does not assemble, I'd consider it a bug.



If you want to communicate on both usarts, I do not have good
answers. Two connections at the same time? Serviced by multi-tasking?
One line to control some other device? Don't hesitate to come
up with details ...


Cheers,
Erich

[Amforth] Help using second uart

[David W. <ins...@gm...>]

Hi all,

Sorry for using this list for help, but I'm not sure where else to go. I am
new to Forth (although I've been aware of it since the days of the Jupiter
Ace when I was at school!), but I have an AVR project to do and I thought
I'd give amforth a try.

My question is, is there an easy way of using a second (hardware) uart with
amforth? I am using an atmega324pu. I have amforth running on it nicely and
I can communicate with usart1 in Forth very simply by setting it up and
reading/writing UDR1. But I'd like interrupt driven RX on uart1. I can
implement this by hand (I've done it before in C) if I have to, but is
there an easier/cleaner way? Has it already been implemented? If so, can
anyone point me (in Forth newbie language) in the direction of how to do it?

Many thanks,

David

Re: [Amforth] marker

[Enoch <ix...@ho...>]

Thanks Erich,

MARKER does indeed work and it is essential -- we can't expect an
enduser to use JTAG when upgrading appl.

Regards, Enoch.

ew....@na... writes:

> Hi Enoch,
>
>
> Quoting Enoch <ix...@ho...>:
>
>> Hi,
>>
>> Can marker be fixed?
> ...
>> |S|   23|    1+ dup @i to dp
>> |S|   24|    1+ dup @i swap 1+ dup @i swap >r
>> |S|   25|    swap over !e set-current
>> |E=set-current ?? -13 24
>> **** /home/enoch/private/iobcan/amforth/lib/ans94/core-ext
>> Error: Error in line sent
>
>
> The error says, that "set-current" is not available.
> This can be fixed by adding the line
>
> .include "dict_wl.inc"
>
> to file dict_appl.inc and reassembling amforth.
> "marker" is working.
>
> Cheers,
> Erich
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct

Re: [Amforth] marker

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

Hi Enoch,


Quoting Enoch <ix...@ho...>:

> Hi,
>
> Can marker be fixed?
...
> |S|   23|    1+ dup @i to dp
> |S|   24|    1+ dup @i swap 1+ dup @i swap >r
> |S|   25|    swap over !e set-current
> |E=set-current ?? -13 24
> **** /home/enoch/private/iobcan/amforth/lib/ans94/core-ext
> Error: Error in line sent


The error says, that "set-current" is not available.
This can be fixed by adding the line

.include "dict_wl.inc"

to file dict_appl.inc and reassembling amforth.
"marker" is working.

Cheers,
Erich

[Amforth] marker

[Enoch <ix...@ho...>]

Hi,

Can marker be fixed?

Thanks, Enoch.

(AT90CAN128)> #include marker.frt
|D=#include marker.frt
|I=getting filenames on the host
|I=  Reading .
|I=  Reading ../../lib
|I=using marker.frt from/home/enoch/private/iobcan/amforth/lib/ans94/core-ext
**** /home/enoch/private/iobcan/amforth/appl/avr-can
|I=getting MCU name..
|I=successfully loaded register definitions for at90can128
|F=/home/enoch/private/iobcan/amforth/lib/ans94/core-ext/marker.frt
|C|    1|\ defines a word which resets the dictionary when called 
|C|    2|\ better then forget but has still limitations
|W|    3|
|W|    4|
|S|    5|: marker ( c<chars> -- )
|S|    6|    get-order
|S|    7|    get-current dup @e
|S|    8|    dp
|S|    9|    edp
|S|   10|    here
|C|   11|    \ maybe save turnkey as well
|S|   12|    create 
|S|   13|    , , , , ,
|C|   14|    \ for save the search order wordlists
|S|   15|    dup ,
|S|   16|    0 ?do
|S|   17|	dup ,
|S|   18|	@e  ,
|S|   19|    loop
|S|   20|    does>
|S|   21|       dup @i to here
|S|   22|    1+ dup @i to edp 
|S|   23|    1+ dup @i to dp
|S|   24|    1+ dup @i swap 1+ dup @i swap >r
|S|   25|    swap over !e set-current
|E=set-current ?? -13 24 
**** /home/enoch/private/iobcan/amforth/lib/ans94/core-ext
Error: Error in line sent

Re: [Amforth] amforth-shell.py idea

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

Hi,

>> \ older mcu's may need
>> [undefined] TCCR0B [if] TCCR0 constant TCCR0B [then]
>> [undefined] TIMSK0 [if] TIMSK constant TIMSK0 [then]
>> ....
>>
>> That would not even require any external tool at all
>>
>> Volunteers welcome ;) (be aware: its not that easy
>> as its seems to be). I just added
>> http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/lib/ans94/tools/bracket-conditional.frt?view=log
>> it does not work in interactive mode however.
> 
> That's based on a forth200x extension and I like it. Will you document
> it (i.e., refcard) when it works in interactive mode as well?

_when_ yes. Probably in the recipes sections.

> A somewhat related question. Can this initialization and other
> initializations be uninstalled (words removed) after execution to save
> space?

Not really. FORGET is not state-of-the-art and MARKER resets the whole
dictionary, not a wordlist only. That makes an implementation of [IF]
and friends on the host side (e.g. the shell) attractive, IMHO.

Matthias

Re: [Amforth] amforth-shell.py idea

[Enoch <ix...@ho...>]

On 10/14/2012 05:01 AM, Matthias Trute wrote:
> Am 13.10.2012 22:51, schrieb Enoch:
>> On 10/13/2012 02:53 PM, Matthias Trute wrote:
>>> Hi,
>>>
>>>> We do still have a problem how to deal with hardware idiosyncrasies as
>>>> timer0.frt demonstrates. It should not be dealt with through the shell
>>>> (re my ill thought #py idea).
>>>>
>>>> The generic frt code should include some preprocessing instructions to
>>>> produce MCU specific code, m4 perhaps?
>>>
>>> A preprocessor would create a similiar dependency on
>>> additional tools that (at least) Erich dislikes.
>>>
>>> m4 (or cpp) are tools for the unix people, but the
>>> majority of the amforth users use windows (for whatever
>>> reason....)
>>
>> Because Atmel provides a great IDE for Windows free of charge :-)
>>
>>>
>>>> Once you decide on the standard people would follow :-)
>>>
>>> Hell, no! I wont make decisions for you ;)
>>>
>>> maybe a preprocessor in (g)forth can help us?
>>
>>
>> I think that any Amforth pre-processing code should syntactically look
>> very different from the surrounding Amforth code. Mixing Gforth with
>> Amforth may lead to confusion where the code actually executes.
>>
>> All Unix tools are easily available now in windows. We just need to
>> decide which tool is most suitable for adapting a generic Forth library
>> code for a particular AVR MCU. I see this tool utilized at Amforth
>> install stage. Perhaps it would unify those appl/ projects...
> 
> The easiest way would an implementation of [if] and friends
> ...
> \ older mcu's may need
> [undefined] TCCR0B [if] TCCR0 constant TCCR0B [then]
> [undefined] TIMSK0 [if] TIMSK constant TIMSK0 [then]
> ....
> 
> That would not even require any external tool at all
> 
> Volunteers welcome ;) (be aware: its not that easy
> as its seems to be). I just added
> http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/lib/ans94/tools/bracket-conditional.frt?view=log
> it does not work in interactive mode however.

That's based on a forth200x extension and I like it. Will you document
it (i.e., refcard) when it works in interactive mode as well?

A somewhat related question. Can this initialization and other
initializations be uninstalled (words removed) after execution to save
space?

Thank you, Enoch.










> 
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev

Re: [Amforth] amforth-shell.py idea

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

Am 13.10.2012 22:51, schrieb Enoch:
> On 10/13/2012 02:53 PM, Matthias Trute wrote:
>> Hi,
>>
>>> We do still have a problem how to deal with hardware idiosyncrasies as
>>> timer0.frt demonstrates. It should not be dealt with through the shell
>>> (re my ill thought #py idea).
>>>
>>> The generic frt code should include some preprocessing instructions to
>>> produce MCU specific code, m4 perhaps?
>>
>> A preprocessor would create a similiar dependency on
>> additional tools that (at least) Erich dislikes.
>>
>> m4 (or cpp) are tools for the unix people, but the
>> majority of the amforth users use windows (for whatever
>> reason....)
> 
> Because Atmel provides a great IDE for Windows free of charge :-)
> 
>>
>>> Once you decide on the standard people would follow :-)
>>
>> Hell, no! I wont make decisions for you ;)
>>
>> maybe a preprocessor in (g)forth can help us?
> 
> 
> I think that any Amforth pre-processing code should syntactically look
> very different from the surrounding Amforth code. Mixing Gforth with
> Amforth may lead to confusion where the code actually executes.
> 
> All Unix tools are easily available now in windows. We just need to
> decide which tool is most suitable for adapting a generic Forth library
> code for a particular AVR MCU. I see this tool utilized at Amforth
> install stage. Perhaps it would unify those appl/ projects...

The easiest way would an implementation of [if] and friends
...
\ older mcu's may need
[undefined] TCCR0B [if] TCCR0 constant TCCR0B [then]
[undefined] TIMSK0 [if] TIMSK constant TIMSK0 [then]
....

That would not even require any external tool at all

Volunteers welcome ;) (be aware: its not that easy
as its seems to be). I just added
http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/lib/ans94/tools/bracket-conditional.frt?view=log
it does not work in interactive mode however.

Matthias

Re: [Amforth] amforth-shell.py idea

[Enoch <ix...@ho...>]

On 10/13/2012 02:53 PM, Matthias Trute wrote:
> Hi,
> 
>> We do still have a problem how to deal with hardware idiosyncrasies as
>> timer0.frt demonstrates. It should not be dealt with through the shell
>> (re my ill thought #py idea).
>>
>> The generic frt code should include some preprocessing instructions to
>> produce MCU specific code, m4 perhaps?
> 
> A preprocessor would create a similiar dependency on
> additional tools that (at least) Erich dislikes.
> 
> m4 (or cpp) are tools for the unix people, but the
> majority of the amforth users use windows (for whatever
> reason....)

Because Atmel provides a great IDE for Windows free of charge :-)

> 
>> Once you decide on the standard people would follow :-)
> 
> Hell, no! I wont make decisions for you ;)
> 
> maybe a preprocessor in (g)forth can help us?


I think that any Amforth pre-processing code should syntactically look
very different from the surrounding Amforth code. Mixing Gforth with
Amforth may lead to confusion where the code actually executes.

All Unix tools are easily available now in windows. We just need to
decide which tool is most suitable for adapting a generic Forth library
code for a particular AVR MCU. I see this tool utilized at Amforth
install stage. Perhaps it would unify those appl/ projects...

Comments please.

Thanks, Enoch.
















> 
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev

Re: [Amforth] amforth-shell.py idea

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

Hi,

> We do still have a problem how to deal with hardware idiosyncrasies as
> timer0.frt demonstrates. It should not be dealt with through the shell
> (re my ill thought #py idea).
> 
> The generic frt code should include some preprocessing instructions to
> produce MCU specific code, m4 perhaps?

A preprocessor would create a similiar dependency on
additional tools that (at least) Erich dislikes.

m4 (or cpp) are tools for the unix people, but the
majority of the amforth users use windows (for whatever
reason....)

> Once you decide on the standard people would follow :-)

Hell, no! I wont make decisions for you ;)

maybe a preprocessor in (g)forth can help us?

Matthias

Re: [Amforth] amforth-shell.py idea

[Enoch <ix...@ho...>]

On 10/13/2012 11:29 AM, Matthias Trute wrote:
> Hi,
> 
>> What is your recommended practice?
> 
> Very simple: Use what you like most. All tools
> that I include with amforth are the ones I consider
> useful for others as well. I do not enforce any of
> them.
> 
> The shell has a few advantages over a  dumb terminal
> and I like to use it. YMMV.
> 
> Matthias

Matthias, I agree. I use it too now.

We do still have a problem how to deal with hardware idiosyncrasies as
timer0.frt demonstrates. It should not be dealt with through the shell
(re my ill thought #py idea).

The generic frt code should include some preprocessing instructions to
produce MCU specific code, m4 perhaps?

Once you decide on the standard people would follow :-)

Thanks, Enoch.

Re: [Amforth] amforth-shell.py idea

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

Hi,

> What is your recommended practice?

Very simple: Use what you like most. All tools
that I include with amforth are the ones I consider
useful for others as well. I do not enforce any of
them.

The shell has a few advantages over a  dumb terminal
and I like to use it. YMMV.

Matthias

Re: [Amforth] amforth-shell.py idea

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

Hi Enoch,

On 10/11/2012 09:03 PM, Enoch wrote:
> This brings me to a more fundamental question which you, as Amforth's
> BDFL, I feel, need to address.
> 
> Amforth-shell.py turns the use of frt "&34 constant PORTA" definitions
> in the code unnecessary as the shell script does these substitutions for
> you (and saves flash memory). It is great for educational purposes but
> it creates dependence on loading of the code through amforth-shell.py
> only. I think Forth tradition is against that, it was supposed to be
> self contained and operated through a simple terminal...
> 
> What is your recommended practice?

I'm having a similar opinion. amforth-shell.py is impressive, no
question. However, IMHO it blurs the line between "what _I_ know"
and "what the machine knows for me", a state which I'm not too
fond of. Your mileage may vary.

So according to "make one programm do one thing well" I have
created two little perl filters, one will recursively
expand all "include"s in a file and produce the expanded code, the
other is stripping comments and empty lines, just to reduce the
number of transferred bytes (it may destroy ." ..." strings though).
The I use amforth-upload.py to transfer the stripped file.

Since I'm very lazy, I have hacked up a Makefile snippet to do this
for me:

--- Makefile -----------------------------------------------------
...
TARGET=main
CONSOLE=/dev/ttyUSB0
...
upload_file:
        cat $(TARGET).fs | unfold_fs > $(TARGET).fs.unfold
        trim_fs $(TARGET).fs.unfold  > $(TARGET).fs.upload
upload: upload_file
        amforth-upload.py  -t $(CONSOLE) $(TARGET).fs.upload

--- unfold_fs -----------------------------------------------------
#!/usr/bin/perl
# 2007-12-08 EW
#
# filter, read all input, expand lines like
#   "^include filename$"
# with the content found in filename
#
# this is written unfold amforth projects before
# transferring them to the target controller.

use warnings;
use strict;
my $Prog=$0;
my $file="";

my $pattern='^[#]*include\s+(\S+)';
my $comment='\ ---';

my $verbose=0;

while (<>)
{
    if (m/$pattern/)
    {
	$file = "$1";
	print STDERR "  $file\n" if ($verbose);
	if (not -r $file)
	{
	    print STDERR "$Prog: file $file not found!\n";
	    exit 2;
	}
	print "$comment include begin $file\n";
	system("$Prog $file") == 0 or  die "failed.\n";
	print "$comment include end $file\n";
    }
    else
    {
	print $_;
    }
}
--- trim_fs -------------------------------------------------------
#!/usr/bin/perl
# 2007-12-08 EW
# trim_fs
#
# filter, remove comments, leading and trailing whitespace and empty lines 
#
# this is written to trim unfolded amforth projects

use warnings;
use strict;

while (<>)
{
    chomp;
    s/\\[ \t].*$//;	# remove line comments
    s/\( .* \)//;	# remove inline comments

    #s/^\s+//;		# delete leading whitespace / well no, keep indendation
    s/\s+$//;		# delete trailing whitespace
    s/\b\s+/ /g;	# compress white space after first word
    next if /^$/;	# delete empty lines

    print "$_\n";
}
-------------------------------------------------------------------

If you or anyone on the list likes this, feel free to use or adapt it to
your needs.

Cheers,
Erich

Re: [Amforth] amforth-shell.py idea

[Enoch <ix...@ho...>]

Hello Matthias,

It was a short Python hacking, it turned out that I did not like it
myself too :-)

#py simply triggers the eval code in the patched amforth-shell.py.
Yes, the code sent to the device is being modified by the shell
according to the python expression that is embedded in the frt code.

This brings me to a more fundamental question which you, as Amforth's
BDFL, I feel, need to address.

Amforth-shell.py turns the use of frt "&34 constant PORTA" definitions
in the code unnecessary as the shell script does these substitutions for
you (and saves flash memory). It is great for educational purposes but
it creates dependence on loading of the code through amforth-shell.py
only. I think Forth tradition is against that, it was supposed to be
self contained and operated through a simple terminal...

What is your recommended practice?

Thanks, Enoch.


On 10/11/2012 12:49 PM, Matthias Trute wrote:
> Enoch,
> 
>> Please find attached a patch to Keith's shell script for your
>> consideration. I took the lazy approach of using Python's eval() option
>> and it was quite easy:
> 
> I've difficulties to understand you approach. Do you change
> the forth code, that gets sent to the controller with the
> conditionals? The #py directive has what purpose? I'm puzzled...
> 
> Where do you store the mappings? Looks like you're using
> the script itself. IMHO not the best place to keep the data..
> 
> You introduce a return code in addition to the exception, why?
> Keith makes an intelligent use of exceptions in his code, I'd
> keep that design whenever possible.
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev

Re: [Amforth] amforth-shell.py idea

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

Enoch,

> Please find attached a patch to Keith's shell script for your
> consideration. I took the lazy approach of using Python's eval() option
> and it was quite easy:

I've difficulties to understand you approach. Do you change
the forth code, that gets sent to the controller with the
conditionals? The #py directive has what purpose? I'm puzzled...

Where do you store the mappings? Looks like you're using
the script itself. IMHO not the best place to keep the data..

You introduce a return code in addition to the exception, why?
Keith makes an intelligent use of exceptions in his code, I'd
keep that design whenever possible.

Matthias

Re: [Amforth] amforth-shell.py idea

[Enoch <ix...@ho...>]

Hello again Matthias,

Here's the patch at pastebin: http://pastebin.com/NbfGxU3C

Thanks, Enoch.


On 10/08/2012 01:36 PM, Matthias Trute wrote:
> Hi,
> 
>> On the at90can128, for example, one has to introduce "TCCR0 constant
>> TCCR0B" before uploading lib/hardware/time0.frt
>>
>> How about extending Keith's fantastic shell with conditional upload
>> constructs such as:
>>
>> #ifdev at90can128
>>    %00000000 TCCR0 c! \ stop timer
>> #else
>>    %00000000 TCCR0B c! \ stop timer
>> #endif
> 
> There are a few (~15 IIRC) more devices, that
> suffer the same problem. Your solution does
> not scale enough, unfortuatly.
> 
>> Any better idea?
> 
> Highly appricated!
> 
> I considered something like
> 
> #ifndef TCCR0B
>   #define TCCR0B TCCR0
> #endif
> 
> but who wants to maintain the matching rules? And who
> wants to check _in detail_ if they are really compatible
> with each other for every controller type (~120 by now)?
> I wont do it.
> 
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev

Re: [Amforth] amforth-shell.py idea

[Enoch <ix...@ho...>]

Hi Matthias,

Please find attached a patch to Keith's shell script for your
consideration. I took the lazy approach of using Python's eval() option
and it was quite easy:

Two variables:
avr - device name string
py - a truth value

1st method:

#py= avr=="at90can128"
#py? "%00000000 TCCR0 c!" if py else "%00000000 TCCR0B c!"

2nd method:

#py= TCCR0B
#py? "%00000000 TCCR0B c!" if py else "%00000000 TCCR0 c!"

If TCCR0B is a known register name py is True, if not py is False
(taking advantage of Keith's reg name substitutions).

Please comment.

Thank you, Enoch.


On 10/08/2012 01:36 PM, Matthias Trute wrote:
> Hi,
> 
>> On the at90can128, for example, one has to introduce "TCCR0 constant
>> TCCR0B" before uploading lib/hardware/time0.frt
>>
>> How about extending Keith's fantastic shell with conditional upload
>> constructs such as:
>>
>> #ifdev at90can128
>>    %00000000 TCCR0 c! \ stop timer
>> #else
>>    %00000000 TCCR0B c! \ stop timer
>> #endif
> 
> There are a few (~15 IIRC) more devices, that
> suffer the same problem. Your solution does
> not scale enough, unfortuatly.
> 
>> Any better idea?
> 
> Highly appricated!
> 
> I considered something like
> 
> #ifndef TCCR0B
>   #define TCCR0B TCCR0
> #endif
> 
> but who wants to maintain the matching rules? And who
> wants to check _in detail_ if they are really compatible
> with each other for every controller type (~120 by now)?
> I wont do it.
> 
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch

Re: [Amforth] amforth-shell.py idea

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

Hi,

> On the at90can128, for example, one has to introduce "TCCR0 constant
> TCCR0B" before uploading lib/hardware/time0.frt
> 
> How about extending Keith's fantastic shell with conditional upload
> constructs such as:
> 
> #ifdev at90can128
>    %00000000 TCCR0 c! \ stop timer
> #else
>    %00000000 TCCR0B c! \ stop timer
> #endif

There are a few (~15 IIRC) more devices, that
suffer the same problem. Your solution does
not scale enough, unfortuatly.

> Any better idea?

Highly appricated!

I considered something like

#ifndef TCCR0B
  #define TCCR0B TCCR0
#endif

but who wants to maintain the matching rules? And who
wants to check _in detail_ if they are really compatible
with each other for every controller type (~120 by now)?
I wont do it.

Matthias

[Amforth] amforth-shell.py idea

[Enoch <ix...@ho...>]

Hi,

On the at90can128, for example, one has to introduce "TCCR0 constant
TCCR0B" before uploading lib/hardware/time0.frt

How about extending Keith's fantastic shell with conditional upload
constructs such as:

#ifdev at90can128
   %00000000 TCCR0 c! \ stop timer
#else
   %00000000 TCCR0B c! \ stop timer
#endif

Any better idea?

Thanks, Enoch.

Re: [Amforth] Asm debugging, how?

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

Enoch,


> Pass 2...
> ../../core/words/brackettick.asm(6) : Warning : A .DB segment with an
> odd number of bytes is detected. A zero byte is added.
> ../../core/words/tick.asm(6) : Warning : A .DB segment with an odd
> number of bytes is detected. A zero byte is added.
> done

Strange. The zero padding bytes are definitly there.

    .dw $ff01
    .db "'",0

and

    .dw $0003
    .db "[']",0


Maybe the mixture of " and ' confuses avra. Could you check whether
the generated code is ok? (lst file)

Matthias

[Amforth] avra not producing working .hex files, was: Asm debugging, how?

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

Hi Enoch,

as Ian has mentioned, there is discussion on the
avr...@li... list, too.

avra is currently missing correct handling of
"forward references". -> change "jmp_" to "jmp" in
amforth.asm to work around that.

avra is also not using the parameter "ram_start",
which is given in the device information. See the
workaround given in 

http://sourceforge.net/mailarchive/forum.php?thread_name=50684CCD.9070001%40nassur.net&forum_name=avra-user

With these in place I was able to produce working .hex
files for atmega644p controllers (amforth-4.9).

Help to improve avra is certainly welcome.

Cheers,
Erich

On 10/02/2012 10:51 PM, Enoch wrote:
> Thanks for your work, Matthias. Enoch.
> 
> FYI, using the same code base:
> 
> Amforth with avrasm2.exe builds a functional code:
> 
> "AT90CAN128" memory use summary [bytes]:
> Segment   Begin    End      Code   Data   Used    Size   Use%
> ---------------------------------------------------------------
> [.cseg] 0x000000 0x01e7ca   1930   8558  10488  131072   8.0%
> [.dseg] 0x000100 0x0001f3      0    243    243    4096   5.9%
> [.eseg] 0x000000 0x000052      0     82     82    4096   2.0%
> 
> Assembly complete, 0 errors. 0 warnings
> 
> but not when using the Linux avra version:
> 
> avra -fI -I ../../Atmel/Appnotes2 -I ../../core -o iob4.hex -d iob4.obj
> -e iob4.eep.hex -l iob4.lst -m iob4.map iob4.asm
> AVRA: advanced AVR macro assembler Version 1.3.0 Build 2 (25 Sept 2012)
> Copyright (C) 1998-2010. Check out README file for more info
> 
> 
> Pass 2...
> ../../core/words/brackettick.asm(6) : Warning : A .DB segment with an
> odd number of bytes is detected. A zero byte is added.
> ../../core/words/tick.asm(6) : Warning : A .DB segment with an odd
> number of bytes is detected. A zero byte is added.
> done
> 
> 
> Assembly complete with no errors (2 warnings).
> Segment usage:
>     Code      :      4247 words (8494 bytes)
>     Data      :       243 bytes
>     EEPROM    :        82 bytes
> 
> 
> 
> On 10/02/2012 02:42 PM, Matthias Trute wrote:
>> Hi,
>>
>>> Working under Windows is not something most Linux guys (like me) desire.
>>> We would have preferred the asm code to be avr-gcc compatible for our
>>> avr-gdb and other tools pleasure.
>>
>> Tastes differ.
>>
>>> P/S Could you affiliate the project with an official git repository?
>>
>> Not currently. Subversion does what I want it to do.
>>
>>> That would make it easier to contribute code.
>>
>> I use git for my internal developments (including amforth), feel free to
>> send me your ideas/patches/...
>>
>>> github, for example, is free to open source projects.
>>
>> So is Sourceforge.
>>
>> Matthias
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
> 
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Asm debugging, how?

[Enoch <ix...@ho...>]

Thanks for your work, Matthias. Enoch.

FYI, using the same code base:

Amforth with avrasm2.exe builds a functional code:

"AT90CAN128" memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x000000 0x01e7ca   1930   8558  10488  131072   8.0%
[.dseg] 0x000100 0x0001f3      0    243    243    4096   5.9%
[.eseg] 0x000000 0x000052      0     82     82    4096   2.0%

Assembly complete, 0 errors. 0 warnings

but not when using the Linux avra version:

avra -fI -I ../../Atmel/Appnotes2 -I ../../core -o iob4.hex -d iob4.obj
-e iob4.eep.hex -l iob4.lst -m iob4.map iob4.asm
AVRA: advanced AVR macro assembler Version 1.3.0 Build 2 (25 Sept 2012)
Copyright (C) 1998-2010. Check out README file for more info


Pass 2...
../../core/words/brackettick.asm(6) : Warning : A .DB segment with an
odd number of bytes is detected. A zero byte is added.
../../core/words/tick.asm(6) : Warning : A .DB segment with an odd
number of bytes is detected. A zero byte is added.
done


Assembly complete with no errors (2 warnings).
Segment usage:
   Code      :      4247 words (8494 bytes)
   Data      :       243 bytes
   EEPROM    :        82 bytes



On 10/02/2012 02:42 PM, Matthias Trute wrote:
> Hi,
> 
>> Working under Windows is not something most Linux guys (like me) desire.
>> We would have preferred the asm code to be avr-gcc compatible for our
>> avr-gdb and other tools pleasure.
> 
> Tastes differ.
> 
>> P/S Could you affiliate the project with an official git repository?
> 
> Not currently. Subversion does what I want it to do.
> 
>> That would make it easier to contribute code.
> 
> I use git for my internal developments (including amforth), feel free to
> send me your ideas/patches/...
> 
>> github, for example, is free to open source projects.
> 
> So is Sourceforge.
> 
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev

Re: [Amforth] Asm debugging, how?

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

Hi,

> Working under Windows is not something most Linux guys (like me) desire.
> We would have preferred the asm code to be avr-gcc compatible for our
> avr-gdb and other tools pleasure.

Tastes differ.

> P/S Could you affiliate the project with an official git repository?

Not currently. Subversion does what I want it to do.

> That would make it easier to contribute code.

I use git for my internal developments (including amforth), feel free to
send me your ideas/patches/...

> github, for example, is free to open source projects.

So is Sourceforge.

Matthias

Re: [Amforth] Asm debugging, how?

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

Hi Enoch,

I'm out of my league here but you might look at the recent Avra-user threads on the subject of avra with amforth if you have not already.

Erich Waelde <ew....@na...> and Marcin Cieslak <sa...@sa...> are discussing this frequently and recently.

Some time ago I had good luck with Avra and amforth but since both amforth and Avra are under active development…

Ian

On 2012-10-01, at 4:19 PM, Enoch wrote:

> Working under Windows is not something most Linux guys (like me) desire.
> We would have preferred the asm code to be avr-gcc compatible for our
> avr-gdb and other tools pleasure.

Re: [Amforth] Asm debugging, how?

[Enoch <ix...@ho...>]

Thanks, Matthias.

I made some progress by switching over to AVR Studio 4 (as I have yet a
JTAG MkI). Conclusion, avra is buggy (at least my git patched at90can128
code) while avrasm2.exe seems to work.

Working under Windows is not something most Linux guys (like me) desire.
We would have preferred the asm code to be avr-gcc compatible for our
avr-gdb and other tools pleasure.

Anyway, my idea is to prepare Amforth as a boot section permanent code
in a product. Would enable the customer to easily run post production
tests, etc. Will report progress if there is any :-)

Thanks, Enoch.

P/S Could you affiliate the project with an official git repository?
That would make it easier to contribute code. github, for example, is
free to open source projects.


On 10/01/2012 01:33 PM, Matthias Trute wrote:
> Enoch,
> 
>> I passed the avra hurdle using git code with a small device.c patch. Now
>> loading the board I see it emitting gibberish ...
> 
> Did you check the serial line settings? amforth uses 9600 or 38400 8N1
> 
> 
>> Is there a way to debug under Linux?
> 
> debugging serial lines? or let amforth run under
> debugger control? Both is at least very difficult
> to impossible (IMHO). avarice is a command line
> tool to connect an JTAG enabled atmega to gdb. Never
> used it myself...
> 
> Matthias