amforth-devel — Development discussion and user support

Re: [Amforth-devel] Amforth(9600), ZTerm(19200) why?

[avr f. <avr...@gm...>]

http://dev.emcelettronica.com/why-avrs-eeprom-will-be-erased-randomly

I think I will explain my problem with this article and move on. =/


On Mon, Jun 23, 2008 at 12:15 AM, avr feedback <avr...@gm...> wrote:
> Ok. First. Thanks for your reply.
>
> On Sun, Jun 22, 2008 at 10:31 PM, Matthias Trute <mt...@we...> wrote:
>> btw: do you have a more usual name?
>
> Mat
>
>> > 1. Why is my Arduino losing memory after turning it off.
>> Well, RAM contents is usually lost when the power goes off ;=)
>
> ok, What I was trying to say was. It does not answer my usb-serial
> connection after some disconnects and reconnects. :>
> It always works after a fresh upload.
>
>> >  It could also be
>> > that the internal state is damage.
>> What do you mean with "internal state"? There are a few candidates
>> for this label.
>
> After power it off and on, 4-5 times strange things happens.
> After a while. Some garbage character appear. Then some more
> characters. Usually after a power cycle, trying to bring it back to
> known state. Then I lose it totally. So my coding session always ends
> with uploading amforth again. Which is a pain. My wish was to never
> have to upload amforth again. I can replicate this problem. It always
> appear when I connect and disconnect with minicom ~4-5 times.
> The garbage characters reminds me of the garbage I saw when I first
> had the wrong baud rate.
>
>> > When I try to connect second time. It's not answering or garbage appear in
>> > the terminal. I'm using default fuses. With baudrate 9600.
>> What default fuses? Atmel factory defaults or arduino default?
>
> This is working acceptable, but breaks after reconnecting with mincom
> (or ZTerm) ~
> 4-5. Like described.
> LFUSE=0x5f HFUSE=0xdf EFUSE=0xf9
>
>> If Atmel default, try setting the fuses to maximize the frequency
>> since 1MHz with the internal oszillator is usually non-working
>> setup. If arduino defaults please let us know what they are.
>
> I'm trying atmel defaults. I lost my arduino defaults.
>
> (What does "Start up time PWRDN/RESET 64K CK/ 14 CK + 4,1 ms" mean?
> This is kind of cryptic to me.)
>
>>
>> My Atmega168 works fine, but is not part of an arduino ...
>>
>> br
>> Matthias
>
> Are you using usb? I'm starting to think it is the usb-serial driver I
> installed initially.
> I hope everyone have patience with my knowledge level.(*noob*) =/
>
> /Mat
>

[Amforth-devel] 16 bit PWM issues

[Bernard M. <bme...@gm...>]

Hi All,

Can someone tell me what step I have missed in initializing one of the 16bit
timers to output on PB5?

-------------------------- code snippet ----------------------------------
marker _pwm_

hex

\ Register defines
37 constant DDRB
4a constant OCR1A
4f constant TCCR1A
4e constant TCCR1B
4c constant TCNT1
4b constant ICR1
57 constant TIMSK

\ bit defines
DDRB  5 portpin: PB5

\ Two useful words
\ or! ors value to contents of RAM address
: or! ( n addr -- ) dup c@ rot or swap c! ;

\ high! is like ! but writes high byte first!
: high! ( n addr -- ) over 8 rshift over 1+ c! c! ;

\ init 16 bit timer1
: +pwm    ( n -- ) \ takes a starting freq parameter
    PB5 high \ Set OC1A/PB5 for output
    0 TCCR1B c! \ stop pwm
    dup OCR1A high! \ set TOP
    1 rshift ICR1 high! \ duty = 50%
    81 TCCR1A c! \ set phase & freq correct mode, OCR1A TOP
    12 TCCR1B c! \ divide clk by 8, start pwm
;
----------------------------- end code snippet -----------------------------

The LED that is on that pwm output either lights or is off depending on the
parameter fed to +pwm. I cannot get the light to flash, even with higher
pre-scale settings than shown above. (I don't have access to a scope at the
moment to check if anything at all is happening ..)

Thanks,
Bernie

[Amforth-devel] A2D problems with ATmega128

[Bernard M. <bme...@gm...>]

Hi All,

I am having a problem getting the A2D subsytem working on the ATmega128. I
have used a modified version of the lcd.frt supplied, but in use I am
getting a number that is the same returned for all channels, and applying a
voltage to the A2D input has no effect (Port F pins).

If I change the scaler parameter for +adc, then I get different numbers, but
still not reading the inputs. Is there somethink else that connects the pins
to the A2D module, I can't see it in the manual, and the example code
doesn't show any extra setup to configure the pins.

I also note that in the "waitadc"  word, I had to wait for ADSR to go low,
not wait for ADIF to go high, as in the example code, otherwise that word
would just hang .. also don't know why the original code starts the a2d
convertor twice?

The code is below, so please have a look and let me know if I am doing
anything incorrect ..

Many Thanks,
Bernard.

PS: The other change I made to the original code "butterfly example" was to
remove references to the VCP pin.

-------------------------------------------------------- Code follows
--------------------------------------------------
\ ADC Routines
---------------------------------------------------------------------------------------------


marker _adc_

hex

\ Register defines
26 constant ADCSRA
25 constant ADCH
24 constant ADCL
27 constant ADMUX

ADCSRA 7 portpin: ADEN
ADCSRA 6 portpin: ADSC

\ Init the ADC sub system
: +adc ( scaler channel -- )
    ADMUX c!          ( -- scaler )
    log2  2 max   \ lowest 3 bits but at least 2
    1 7 lshift or \ msb
    ADCSRA c!
;

\ wait until the adc is finished
: waitadc ( -- )
    begin
        ADCSRA c@
    [ hex ] 40 and 0=
    until
;

\ fetch the value of the initialized adc channel
: adc@ ( -- adc )
    ADEN high         ( -- )
    ADSC high \ start converter
    waitadc         ( -- )
    0               ( -- 0 )
    8 0 do          ( -- n )
    ADSC high     ( -- n )
    waitadc     ( -- n )
    ADCL c@    ADCH c@ 8 lshift + ( -- n adc_i )
    +           ( -- n )
    loop            ( -- n )
    3 rshift        ( -- adc )
;

Re: [Amforth-devel] Amforth(9600), ZTerm(19200) why?

[avr f. <avr...@gm...>]

Ok. First. Thanks for your reply.

On Sun, Jun 22, 2008 at 10:31 PM, Matthias Trute <mt...@we...> wrote:
> btw: do you have a more usual name?

Mat

> > 1. Why is my Arduino losing memory after turning it off.
> Well, RAM contents is usually lost when the power goes off ;=)

ok, What I was trying to say was. It does not answer my usb-serial
connection after some disconnects and reconnects. :>
It always works after a fresh upload.

> >  It could also be
> > that the internal state is damage.
> What do you mean with "internal state"? There are a few candidates
> for this label.

After power it off and on, 4-5 times strange things happens.
After a while. Some garbage character appear. Then some more
characters. Usually after a power cycle, trying to bring it back to
known state. Then I lose it totally. So my coding session always ends
with uploading amforth again. Which is a pain. My wish was to never
have to upload amforth again. I can replicate this problem. It always
appear when I connect and disconnect with minicom ~4-5 times.
The garbage characters reminds me of the garbage I saw when I first
had the wrong baud rate.

> > When I try to connect second time. It's not answering or garbage appear in
> > the terminal. I'm using default fuses. With baudrate 9600.
> What default fuses? Atmel factory defaults or arduino default?

This is working acceptable, but breaks after reconnecting with mincom
(or ZTerm) ~
4-5. Like described.
LFUSE=0x5f HFUSE=0xdf EFUSE=0xf9

> If Atmel default, try setting the fuses to maximize the frequency
> since 1MHz with the internal oszillator is usually non-working
> setup. If arduino defaults please let us know what they are.

I'm trying atmel defaults. I lost my arduino defaults.

(What does "Start up time PWRDN/RESET 64K CK/ 14 CK + 4,1 ms" mean?
This is kind of cryptic to me.)

>
> My Atmega168 works fine, but is not part of an arduino ...
>
> br
> Matthias

Are you using usb? I'm starting to think it is the usb-serial driver I
installed initially.
I hope everyone have patience with my knowledge level.(*noob*) =/

/Mat

Re: [Amforth-devel] Amforth(9600), ZTerm(19200) why?

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

avr feedback wrote:

btw: do you have a more usual name?
> ok. thanks. :)Now I have a harder question.
> 1. Why is my Arduino losing memory after turning it off.
Well, RAM contents is usually lost when the power goes off ;=)
>  It could also be
> that the internal state is damage.
What do you mean with "internal state"? There are a few candidates
for this label.
> When I try to connect second time. It's not answering or garbage appear in
> the terminal. I'm using default fuses. With baudrate 9600.
What default fuses? Atmel factory defaults or arduino default?
If Atmel default, try setting the fuses to maximize the frequency
since 1MHz with the internal oszillator is usually non-working
setup. If arduino defaults please let us know what they are.

My Atmega168 works fine, but is not part of an arduino ...
>
> Background:
> This forth image is based on the svn repository.
> And uses AVRMacPack to compile.
That should not do any harm since assembly is
way too low level for optimizers and friends.

br
Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIXraa9bEHdGEMFjMRAtJgAKCkL4A82R/INVipZRXuEHyNzhrJSACgkXMK
DHB0nwaZamAH2OJIXEtu/5Q=
=bx1h
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Amforth(9600), ZTerm(19200) why?

[avr f. <avr...@gm...>]

ok. thanks. :)Now I have a harder question.
1. Why is my Arduino losing memory after turning it off. It could also be
that the internal state is damage.
When I try to connect second time. It's not answering or garbage appear in
the terminal. I'm using default fuses. With baudrate 9600.


Background:
This forth image is based on the svn repository.
And uses AVRMacPack to compile.


On Sun, Jun 15, 2008 at 8:40 PM, Christian Berger <
cas...@ca...> wrote:

> On Sunday 15 June 2008 20:26:19 avr feedback wrote:
> > When Amforth it set to 9600 and ZTerm to 19200. It works. why?
>
> I guess your Arduino runs at 16 MHz but you told the assembler that your
> controller is running at 8MHz.
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] Heap pointer in EEPROM, Why?

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

hi,

> why is the heap pointer stored in EEPROM?

It is the pointer to the first unused ram address. There
may be words in the dictionary that uses ram below it and they
depend on the absolute address.

> I probably miss something, but wouldn't it be more logical to store that
> in
> RAM as its contents are irrelevant after the RAM has been deleted?

No, the content of the RAM is lost, but not it's structure.

The words that allocated RAM will use it again at the same addresses
(that those words need to store somewhere, e.g. as a variable entry
in the dictonary).

bye
Matthias

Re: [Amforth-devel] Amforth(9600), ZTerm(19200) why?

[Christian B. <cas...@ca...>]

On Sunday 15 June 2008 20:26:19 avr feedback wrote:
> When Amforth it set to 9600 and ZTerm to 19200. It works. why?

I guess your Arduino runs at 16 MHz but you told the assembler that your 
controller is running at 8MHz.

[Amforth-devel] Amforth(9600), ZTerm(19200) why?

[avr f. <avr...@gm...>]

Hello.

I just got it working. But I can't understand one thing.

Why do I need faster baud rate in ZTerm compared to Amforth baud rate
settings?

When Amforth it set to 9600 and ZTerm to 19200. It works. why?

I just got my Arduino this week. So I'm learning..

---
Background: This is how I got it working
Tools: Mac, VMware Fusion, Studio4.14(589) in WindowsXP, ZTerm on mac

Amforth
1. Get amforth compiling clean. (change temp6->zl and temp7->zh)
2. Change ADCaddr -> ADCCaddr
3. Comment out r30 and r31 in macros.asm.
3. Set Baud rate = 9600
4. Change .include to device/atmega168.asm
5. Compile, f7.

Uploading hex and eep files.
1. Arduino have a extern crystal. (CKSEL=1111,SUT=00)
2. LFUSE=0xCF, HFUSE=0xDF, EFUSE=0xF8 (
http://palmavr.sourceforge.net/cgi-bin/fc.cgi)
3. LockBit=0xCF

Connecting with ZTerm
1. Connect USB cable direct to Arduino
2. Disconnect AVRISP mkII from Arduino
3. ZTerm 19200N81, no local echo, no Xon/Xoff, no Hardware handshake
   vt100, ZModem protocol for send and receive.

[Amforth-devel] Heap pointer in EEPROM, Why?

[Christian B. <cas...@ca...>]

Servus,

why is the heap pointer stored in EEPROM?
I probably miss something, but wouldn't it be more logical to store that in 
RAM as its contents are irrelevant after the RAM has been deleted?

Servus
  Casandro

Re: [Amforth-devel] Heap?

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

Christian Berger wrote:
> Servus,
> 
> are there any plans to have a heap like in C?

Simple and short answer: No.

The longer answer is, that a heap management needs both code size
and RAM size which is both (sometimes very) limited. Therefore I
do not wrote a sophisticated memory management subsystem. ALLOT
is all that exists.

But feel free to implement it.

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIU6219bEHdGEMFjMRAmR/AKCuMnvhA7JSm455iOHHtVK7nEYOPgCfZaXm
4WjSti6e2q8jcdu39nlWihM=
=ZFSr
-----END PGP SIGNATURE-----

[Amforth-devel] Heap?

[Christian B. <cas...@ca...>]

Servus,

are there any plans to have a heap like in C?

Maybe the simplest way would be to do it like most C implementations do it:

  v            v
YZ0123456....YZ0123456...

The pointers point at the start of the memory region the programm uses. 
(0123...) Just before that point, there is a word (YZ) which is there for 
memory management. That word contains the size of the memory region and a 
flag indicating wether it's in use or not.

So we would need 3 words:
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Heap-Allocation.html

In short:
allocate       u -- a-addr wior
This word should search through the heap for free memory. It starts by the 
first pointer, which is somewhere stored in the system. It follows the size 
information until it found a free block which is large enought for the size 
requested. If the block is larger than the requested size it will be split 
into two. If there are not enought bytes to make a new block, the current one 
will be made bigger. If an error occurs, it will be reported in wior.

free       a-addr -- wior
This word looks for the next blocks, if those are free, it merges them with 
the current block. The current block is then set to be unused.
This simple routine will run into problems if memory is freed in the wrong 
direction. Then it will not be able to merge free blocks as it is unable to 
look towards low memory regions. Maybe a special word "clean-up" might be 
good. Or we could have an allocate which checks for successive free blocks.
Free will fail on blocks which are marked unused.

resize       a-addr1 u -- a-addr2 wior
This word would essentially allocate a new block of size u, copy the data from 
the old block and free the old block. Maybe optimisations could be done to 
expand the block towards lower memory regions even if the conventional 
allocate/free combination would not work.

Another word we should have, which is not included in gforth is:
sizeof	 	a-addr1 -- u
This word checks the pointer and returns the size of the block at its 
position. 
This would help us prevent many buffer overrun problems of C.



Dynamic memory would enable us to do lots of things. For example the video 
output could save on space. For example it could have a line pointer table 
which stores pointers for each (text) line of the display. Empty lines could 
just have a 0-entry in that table. Double width lines could just take up half 
the memory. Graphic lines could use more memory, etc. Overall we might save 
quite a bit of memory.

Servus
  Casandro

Re: [Amforth-devel] Video quod vadis

[Christian B. <cas...@ca...>]

Am Samstag 24 Mai 2008 21:50:35 schrieb Matthias Trute:
> Christian Berger wrote:

> It would be nice if the keyboard words would work with EKEY from
> the forth200x words. That would make code page changes very easy too.

I should look into that. As I mentioned before, I'm not really that fluently 
with Forth.

> > Hmm, maybe we could have block read and write commands. But for that we'd
> > need memory allocation words.
>
> ALLOT exists ;=)

I also need to look into that. It would be great if one had something simmilar 
to the memory handling C does, only working.

> 800 bytes is less than a single ANS block, and power is not essential as
> long as a tv device is concerned ;=)

Well if you have 2048 bytes of RAM on your device total, it is a problem. 
Besides for the ethernet interface you'd still need the SPI, which is already 
used by the video. And Ethernet is _really_ expensive. It costs more than the 
rest of the system, including an additional large screen television set for 
output to larger crowds.
And a normal large TV-set only takes about 10 watts peak, probably a lot less 
with white text on black background. Small non-direct view screens even take 
less power.

> btw: On tuxgraphics there is an atmega88 with an ethernet interface and
> a webserver running on it.

Of course, there have been many projects involving ethernet and TCP/IP. So far 
most only support IPv4.

Well I'll need to look into it. Maybe there's a way to implement Ethernet with 
very little external hardware. Yes, I know there are single chip Ethernet 
interfaces around.

> > My idea would be to have a
> > tiny stripped down networking protocoll which can work with tiny buffers.
>
> Sound like you are looking for CAN.

CAN is so bloated and expensive. I2C on the contrary is widely availiable in 
microcontrollers and easy to implement in software.
Well OK, I admit it, I don't really like CAN. :)

> Bye
> Matthias

Servus
  Casandro

Re: [Amforth-devel] Video quod vadis

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Berger wrote:

> Well there is nothing new other what is on here. Yes, it now supports the 
> @-key. I'm still not very happy about the keyboard routines.
> http://www.mikrocontroller.net/topic/94193

It would be nice if the keyboard words would work with EKEY from
the forth200x words. That would make code page changes very easy too.

> Hmm, maybe we could have block read and write commands. But for that we'd need 
> memory allocation words.

ALLOT exists ;=)

>>> If you add some kind of networking via I2C you can send a kind of e-mail.
>> There is even a ethernet connection possible (with IP etc). Hardware
>> exists.
> 
> TCP/IP needs a _lot_ of memory (800 bytes) and ethernet is not only rather 
> expensive, but it also takes quite a lot of power.

800 bytes is less than a single ANS block, and power is not essential as
long as a tv device is concerned ;=)

btw: On tuxgraphics there is an atmega88 with an ethernet interface and
a webserver running on it.

> My idea would be to have a 
> tiny stripped down networking protocoll which can work with tiny buffers.

Sound like you are looking for CAN.

Bye
Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIOHGL9bEHdGEMFjMRAtCUAJ9jWqJnp6UIflbDuqfELTrKLVYATQCeKrE1
VSp4HYEFfwBQ1xKEdlgrkvs=
=o9/d
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Video quod vadis

[Christian B. <cas...@ca...>]

Am Freitag 23 Mai 2008 21:12:04 schrieb Matthias Trute:
> Hi Christian,

> If you have any updates, you can send them to me (directly).

Well there is nothing new other what is on here. Yes, it now supports the 
@-key. I'm still not very happy about the keyboard routines.
http://www.mikrocontroller.net/topic/94193

> I'm happy to sit-and-wait and nitpick the cherries ;=)

Good :)

> (Standard-) blocks are somewhat difficult since they need a lot of RAM
> for the buffer(s). IMHO blocks can only be used with external RAM and/or
> a modified RAM - Fetch/Store to emulate a MMU with paging.

Hmm, maybe we could have block read and write commands. But for that we'd need 
memory allocation words.

With memory allocation, it would also be possible to have a more dynamic video 
display. For example we could have an empty image to need less memory than a 
full one. Just like the popular ZX80 homecomputer does.

> > Seriously if you can edit blocks, and send them to a printer
>
> I doubt that a windows el-cheapo GDI printer will ever work ;=)

I doubt GDI printers are still around. Most now have either PCL or Postscript 
or some Linux-only stuff.

> Postscript OTOH may work well, esp for a forth system ...

True, we could have parallel processing. :)

> > If you add some kind of networking via I2C you can send a kind of e-mail.
>
> There is even a ethernet connection possible (with IP etc). Hardware
> exists.

TCP/IP needs a _lot_ of memory (800 bytes) and ethernet is not only rather 
expensive, but it also takes quite a lot of power. My idea would be to have a 
tiny stripped down networking protocoll which can work with tiny buffers. I2C 
can already do quite a bit of what we want. For example it already forces the 
slave to acknownledge the bytes. A master could just send bytes until the 
slave doesn't acknownledge anymore.
As I2C is multi-master we can essentially use it like Ethernet.
We can still define a "gateway-protocoll" in which you can contact 
a "router-node" and tell it to forward your connection.

> Bye
> Matthias

Servus
  Casandro

Re: [Amforth-devel] Video quod vadis

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Christian,

Christian Berger wrote:
> Servus, (=bavarian for hello and goodbye)
> 
> as you may know I have written some video routines for amforth (currently 
> seperate).

If you have any updates, you can send them to me (directly).

> I now wonder what direction we should go with them. There are already some 
> routines hidden in the repository.

I'm happy to sit-and-wait and nitpick the cherries ;=)

> If we would then also have the block commands, amforth would be on its way 
> towards a fully functional desktop operating system. :)

(Standard-) blocks are somewhat difficult since they need a lot of RAM
for the buffer(s). IMHO blocks can only be used with external RAM and/or
a modified RAM - Fetch/Store to emulate a MMU with paging.

> Seriously if you can edit blocks, and send them to a printer

I doubt that a windows el-cheapo GDI printer will ever work ;=)
Postscript OTOH may work well, esp for a forth system ...

> If you add some kind of networking via I2C you can send a kind of e-mail.

There is even a ethernet connection possible (with IP etc). Hardware
exists.

Bye
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFINxcE9bEHdGEMFjMRAjVzAJ4hVFUPKL/pxMlssrkC/A3iTuSdOwCgw+UJ
VW/FLwsl5w3B5IFLQ7rnbFQ=
=qUM2
-----END PGP SIGNATURE-----

[Amforth-devel] Video quod vadis

[Christian B. <cas...@ca...>]

Servus, (=bavarian for hello and goodbye)

as you may know I have written some video routines for amforth (currently 
seperate).
I now wonder what direction we should go with them. There are already some 
routines hidden in the repository.
My personal vision is to have video output at 64x16 plus a status line 
(technically possible) so we can display forth blocks directly. This would 
save a lot of memory. 
If we would then also have the block commands, amforth would be on its way 
towards a fully functional desktop operating system. :)
Seriously if you can edit blocks, and send them to a printer, you can already 
write letters with your system. Now add a simple database, and you can do 
mass-mailings.
If you add some kind of networking via I2C you can send a kind of e-mail.

What do you think?

Servus
  Casandro

Re: [Amforth-devel] amforth-uptload.py tool

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

Hi,

just for the records:
> I'd recommend setserial. minicom IIRC resets the serial settings when
> shutting down.

You can prevent minicom from "initializing the modem" by 
using the "-o" Option. Check the documentation for details.

You can exit from minicom without resetting the serial 
interface with "C-A Q".


Cheers,
Erich

Re: [Amforth-devel] amforth-uptload.py tool

[Bernard M. <bme...@gm...>]

Hi Mathias,

Thanks for that. I used stty to set the serial baud rate, as it is not very
apparent how to do that with setserial reading the manpage.

The atmega128 system works great now, I have used the macros.asm file that
you checked in the other day to sort out the temp7 issue. I will email the
atmega128.asm file to your address for inclusion in future releases.

Cheers,
Bernard

On Fri, May 9, 2008 at 6:02 PM, Matthias Trute <mt...@we...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bernard,
>
> > 1. I use the utility as "amforth-upload.py filename.frt" (where
> filename.frt
> > is the forth code), is this correct,  the -h help returned indicates this
> is
> > all you do.
>
> I add the -t parameter for the port every time (even for ttyS0) to be
> sure to send the files to the correct port.
>
> > 2. If this utility  uses the serial device /dev/ttyS0, how  does it set
> up
> > the baud rate, there is no facility in the script to do that.
> > (I tried using minicom to set up the baud rate for the port, then use the
> > -f(force) option with the script, but still nothing ....
>
> I'd recommend setserial. minicom IIRC resets the serial settings when
> shutting down. The upload utility itself does not change the serial
> settings.
>
> Bye
> Matthias
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFII+jr9bEHdGEMFjMRAjxOAKDIETGZdp4hxaoiBXoI7vhAiHtnmwCgm30k
> IOrxEI69rcSU9q9ai7VKPj8=
> =+WO8
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] amforth-uptload.py tool

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernard,

> 1. I use the utility as "amforth-upload.py filename.frt" (where filename.frt
> is the forth code), is this correct,  the -h help returned indicates this is
> all you do.

I add the -t parameter for the port every time (even for ttyS0) to be
sure to send the files to the correct port.

> 2. If this utility  uses the serial device /dev/ttyS0, how  does it set up
> the baud rate, there is no facility in the script to do that.
> (I tried using minicom to set up the baud rate for the port, then use the
> -f(force) option with the script, but still nothing ....

I'd recommend setserial. minicom IIRC resets the serial settings when
shutting down. The upload utility itself does not change the serial
settings.

Bye
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFII+jr9bEHdGEMFjMRAjxOAKDIETGZdp4hxaoiBXoI7vhAiHtnmwCgm30k
IOrxEI69rcSU9q9ai7VKPj8=
=+WO8
-----END PGP SIGNATURE-----

[Amforth-devel] amforth-uptload.py tool

[Bernard M. <bme...@gm...>]

Hi All,

I am trying to use the above tool to download some forth (.frt) files to my
target atmel128  based board.

When I try to use this utility (Linux box, standard port /dev/ttyS0) it just
does nothing, no error messages .. nothing, have to CTL-C to get out.

Some questions:

1. I use the utility as "amforth-upload.py filename.frt" (where filename.frt
is the forth code), is this correct,  the -h help returned indicates this is
all you do.
2. If this utility  uses the serial device /dev/ttyS0, how  does it set up
the baud rate, there is no facility in the script to do that.
(I tried using minicom to set up the baud rate for the port, then use the
-f(force) option with the script, but still nothing ....

Hopefully someone has used this utility can tell me what I am doing wrong ..


Thanks,
Bernard

Re: [Amforth-devel] at90can128

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

Hi all,

> I'm currently trying to set up Amforth on an AT90CAN128 evaluation board,
> and was very thankful for your input yesterday.

That was helpful indeed. Thanks to all that found it out. The reason
that amforth does not work on 128KB flash controllers is that
temp7 is mapped to zl. My strong believe that the warning the
assembler produces can be ignored was based upon the fact
that amforth works fine on smaller atmegas. This and that I did not
tested the final release on the atmega128 but a intermediate version
with the 2.7 version prompt led to the confusion. Sorry about that.


> Changing temp7 to temp5 in the macro definitions only does part of the
> trick.

Well, it does not really solves the problem. This evening I'll
commit a change into the repository that solves the problem (hopefully,
I'll _do_ the test on my can128).

> compile a definition as simple as this:
>
>    : test 1 2 + . ;

This particular problem is in the division routines. They use
all the tempx registers, so mixing temp5 with temp7 disruptes the
division completly. And division is used in number conversion...

> I'm a bit perplexed on why the colon compiler code should work on an
> ATmega32.

The problem is not related with the colon compiler.


Bye
Matthias

Re: [Amforth-devel] at90can128

[Stefan H. <ste...@ya...>]

Oops. Have to correct myself.

The ATMega32 and the AT90CAN32 are different in a number of ways, judging from a diff I made between the device definitions in the AVRA library. So, as a working model I hazard to guess that the AT90CAN32 will not work with amforth, too, but the ATmega32 should be.

Can anyone confirm whether the ATmega128 works?

Have a nice day,

Stefan


      E-Mails jetzt auf Ihrem Handy.
www.yahoo.de/go

Re: [Amforth-devel] at90can128

[Stefan H. <ste...@ya...>]

Hello, Lars and Bernard, and hi rest,

I'm currently trying to set up Amforth on an AT90CAN128 evaluation board, and was very thankful for your input yesterday.

Changing temp7 to temp5 in the macro definitions only does part of the trick. While it /does/ provide for a pleasant command prompt which works normally, the colon compiler does hang or not terminate when trying to compile a definition as simple as this:

   : test 1 2 + . ;

I tried to increase the delay between characters, inter-line-delay does not come into account as its only one line. Perhaps there's still a problem with temp6 or further registers that are already mapped to different purposes for the AT90CANxxx and ATmega128 (and probably the ATmega64).

I'm a bit perplexed on why the colon compiler code should work on an ATmega32. As far as I understood, the AT90CANxxx are the same as the corresponding ATmegaxxx, with the CAN hardware added. And that the ATmega{32,64,128} differ only in Flash, EPROM and RAM size. For an AVR Butterfly, everything works like a charm.

Have a nice day,

Stefan



      Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: 
http://de.yahoo.com/set

Re: [Amforth-devel] Amforth-devel Digest, Vol 10, Issue 1 / ATmega256

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guten Morgen Matthias.

Am 06.05.2008 um 22:11 schrieb amforth-devel- 
re...@li...:
...
> The 128KB boundary may
> fall too, but currently I have only some vague ideas how to do it and
> (more important) no hardware to play with.

Hm, hast du ein Board um einen ATmega2560 oder ATmega2561 zu stecken?  
Oder müsste auch ein Board her?

Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIIUgwJ3DLQCvSXtcRAsP9AJ9/FgNYEKopUKz17cjIHkwLczi4WACffdqQ
1GQdmbWAdQlhxWO3kTHW+gw=
=dlrB
-----END PGP SIGNATURE-----