Menu
▾
▴
amforth-devel — Development discussion and user support
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(6) |
Mar
(41) |
Apr
(23) |
May
(11) |
Jun
(2) |
Jul
|
Aug
|
Sep
(9) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2008 |
Jan
(6) |
Feb
(1) |
Mar
(23) |
Apr
(18) |
May
(21) |
Jun
(13) |
Jul
(34) |
Aug
(5) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(4) |
| 2009 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(10) |
May
(1) |
Jun
(11) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
(13) |
| 2010 |
Jan
(10) |
Feb
(4) |
Mar
(28) |
Apr
(3) |
May
(38) |
Jun
(22) |
Jul
(92) |
Aug
(154) |
Sep
(218) |
Oct
(45) |
Nov
(20) |
Dec
(1) |
| 2011 |
Jan
(33) |
Feb
(15) |
Mar
(32) |
Apr
(33) |
May
(48) |
Jun
(35) |
Jul
(7) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
|
Dec
(7) |
| 2012 |
Jan
(56) |
Feb
(11) |
Mar
(6) |
Apr
|
May
(128) |
Jun
(59) |
Jul
(21) |
Aug
(16) |
Sep
(24) |
Oct
(39) |
Nov
(12) |
Dec
(12) |
| 2013 |
Jan
(14) |
Feb
(61) |
Mar
(97) |
Apr
(46) |
May
(13) |
Jun
(23) |
Jul
(12) |
Aug
(25) |
Sep
(9) |
Oct
(81) |
Nov
(73) |
Dec
(45) |
| 2014 |
Jan
(36) |
Feb
(57) |
Mar
(20) |
Apr
(41) |
May
(43) |
Jun
(11) |
Jul
(14) |
Aug
(32) |
Sep
(9) |
Oct
(27) |
Nov
(21) |
Dec
(6) |
| 2015 |
Jan
(14) |
Feb
(23) |
Mar
(1) |
Apr
(19) |
May
(40) |
Jun
(11) |
Jul
(1) |
Aug
(2) |
Sep
(14) |
Oct
(10) |
Nov
(9) |
Dec
(13) |
| 2016 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
|
May
(4) |
Jun
(13) |
Jul
(8) |
Aug
(3) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(7) |
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(3) |
Jul
(6) |
Aug
|
Sep
(2) |
Oct
(54) |
Nov
(47) |
Dec
(53) |
| 2019 |
Jan
(23) |
Feb
(24) |
Mar
(19) |
Apr
(15) |
May
(5) |
Jun
(34) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(7) |
Apr
(7) |
May
(5) |
Jun
(15) |
Jul
(22) |
Aug
(28) |
Sep
(13) |
Oct
(9) |
Nov
(17) |
Dec
(13) |
| 2021 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
(9) |
May
(21) |
Jun
(9) |
Jul
|
Aug
(6) |
Sep
(16) |
Oct
|
Nov
(1) |
Dec
(6) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(21) |
Oct
(5) |
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: pito <pi...@vo...> - 2010-08-17 08:50:28
|
Hi, let me ask following - why the write to avr flash in amforth uses i when i is used in other context as well. Why not agree e.g.: f - flash internal - f!, f@ ff - flash external - ff!, ff@ e - eprom internal - e!, e@ ee - eprom external - ee!, ee@ i - index j - index c - char Pito. |
|
From: Marcin C. <sa...@sa...> - 2010-08-17 02:05:20
|
Below please find definitions of c?, i? and ? - I find
them useful while exploring amforth (and AVR) interactively.
--Marcin
; ( addr -- ) Numeric IO
; R( -- )
; output single character from the address
VE_CQUESTION:
.dw $ff02
.db "c?"
.dw VE_HEAD
.set VE_HEAD = VE_CQUESTION
XT_CQUESTION:
.dw DO_COLON
PFA_CQUESTION:
.dw XT_CFETCH
.dw XT_DOT
.dw XT_EXIT
; : c? ( addr -- ) c@ . ;
; ( addr -- ) Numeric IO
; R( -- )
; output single word from the address in flash
VE_IQUESTION:
.dw $ff02
.db "i?"
.dw VE_HEAD
.set VE_HEAD = VE_IQUESTION
XT_IQUESTION:
.dw DO_COLON
PFA_IQUESTION:
.dw XT_IFETCH
.dw XT_DOT
.dw XT_EXIT
; : i? ( addr -- ) i@ . ;
; ( addr -- ) Numeric IO
; R( -- )
; output single cell from the address
VE_QUESTION:
.dw $ff01
.db "?",0
.dw VE_HEAD
.set VE_HEAD = VE_QUESTION
XT_QUESTION:
.dw DO_COLON
PFA_QUESTION:
.dw XT_FETCH
.dw XT_DOT
.dw XT_EXIT
; : ? ( addr -- ) @ . ;
|
|
From: Marcin C. <sa...@sa...> - 2010-08-17 01:38:24
|
Hello,
I have prepared some double-length words for your convenience:
Probably some could be more optimized.
--Marcin
; ( d -- ) Compiler
; R( -- )
; create a named constant
VE_2CONSTANT:
.dw $ff09
.db "2constant",0
.dw VE_HEAD
.set VE_HEAD = VE_2CONSTANT
XT_2CONSTANT:
.dw DO_COLON
PFA_2CONSTANT:
.dw XT_DOCREATE
.dw XT_COMPILE
.dw PFA_DO2VARIABLE
.dw XT_SWAP
.dw XT_COMMA
.dw XT_COMMA
.dw XT_EXIT
; ( d -- ) Stack
; R( -- )
; drop TOS
VE_2DROP:
.dw $ff05
.db "2drop",0
.dw VE_HEAD
.set VE_HEAD = VE_2DROP
XT_2DROP:
.dw PFA_2DROP
PFA_2DROP:
loadtos
loadtos
jmp DO_NEXT
; ( d1 -- d1 d1 ) Stack
; R( -- )
; stack manipulation
VE_2DUP:
.dw $ff04
.db "2dup"
.dw VE_HEAD
.set VE_HEAD = VE_2DUP
XT_2DUP:
.dw PFA_2DUP
PFA_2DUP:
savetos
ldd tosl, Y+2
ldd tosh, Y+3
savetos
ldd tosl, Y+2
ldd tosh, Y+3
jmp DO_NEXT
; ( addr -- d ) Memory
; R( -- )
; read 2 cells from RAM (or IO or CPU register)
; byte order is little-endian 44 33 22 11 -> 11223344.
VE_2FETCH:
.dw $ff02
.db "2@"
.dw VE_HEAD
.set VE_HEAD = VE_2FETCH
XT_2FETCH:
.dw PFA_2FETCH
PFA_2FETCH:
movw zl, tosl
ld tosl, z+
ld tosh, z+
savetos
ld tosl, z+
ld tosh, z+
jmp DO_NEXT
; ( d addr -- ) Memory
; R( -- )
; write 32bit to RAM memory (or IO or CPU registers)
; words are stored little-endian, so 12345678. becomes
; 78 56 34 12
VE_2STORE:
.dw $ff02
.db "2!"
.dw VE_HEAD
.set VE_HEAD = VE_2STORE
XT_2STORE:
.dw PFA_2STORE
PFA_2STORE:
movw zl, tosl
loadtos
std Z+2, tosl
std Z+3, tosh
loadtos
std Z+0, tosl
std Z+1, tosh
loadtos
jmp DO_NEXT
; ( -- ) Compiler
; R( -- )
; create a variable entry and allocate RAM space for it
VE_2VARIABLE:
.dw $ff09
.db "2variable",0
.dw VE_HEAD
.set VE_HEAD = VE_2VARIABLE
XT_2VARIABLE:
.dw DO_COLON
PFA_2VARIABLE:
.dw XT_HERE
.dw XT_CONSTANT
.dw XT_DOLITERAL
.dw 4
.dw XT_ALLOT
.dw XT_EXIT
; ( -- addr )
; R( -- )
; puts content of parameter field (2 cells) to TOS
;VE_DO2VARIABLE:
; .dw $ff0b
; .db "(2variable)",0
; .dw VE_HEAD
; .set VE_HEAD = VE_DO2VARIABLE
XT_DO2VARIABLE:
.dw PFA_DO2VARIABLE
PFA_DO2VARIABLE:
savetos
movw zl, wl
adiw zl,1
readflashcell tosl,tosh
savetos
movw zl, wl
adiw zl,2
readflashcell tosl,tosh
jmp DO_NEXT
|
|
From: pito <pi...@vo...> - 2010-08-16 16:20:34
|
it was suuposed, but not available...p. ----- PŮVODNÍ ZPRÁVA ----- Od: an...@ki... Komu: amf...@li... Předmět: Re: [Amforth-devel] Atmega 1284p Datum: 16.8.2010 - 12:25:58 > Lol > > It was supposed to be mainstream about 2 years > ago. Check out the forums > on AVR Freaks. > > Got some on order, just waiting delivery, then we > can have a play. > > > > On 16/08/10 08:19, pito wrote: > > Matthias, > > mind an average windoze user cannot run the > > provided python files > > > (I've tried python 3.x and 2.7 as well). It > > would be great to find > > > an python expert who is able to port the stuff > > to windoze python.. > > > And yes, the 1284P is DIL40 and 44smd drop in > > replacement for 32 and > > > 644. My guess is it will be the mainstream for > > the next 2y. > > > Pito. > > > > ----- PŮVODNÍ ZPRÁVA ----- > > Od: "Matthias Trute" <mt...@we...> > > Komu: "Everything around amforth" > > <amf...@li...> > > Předmět: Re: [Amforth-devel] Atmega 1284p > > Datum: 15.8.2010 - 9:46:26 > > > >> Pito, > >> > >>> Hi, There is the atmega1284p available (128k > >>> flash, 16k ram, dil40) > >>>> - drop in replacement of 32, 64 - so quite > >>>> sexy > >>>> >>> chip. Do you plan to > >>>> support it? P. > >> > >> amforth has a utility named pd2amforth that > >> creates the device > >> specific driver files. All of the currently > >> delivered controller > >> files (core/devices/*) are generated with that > >> tool. I excpect no > >> problems with that new controller, it should > >> work. > >> >> Formal support is > >> unlikly, I cannot buy each controller type and > >> test it myself, sorry. > >> > >> Matthias > >> > >> > >> > >> ------------------------------------------------------------------------------ > >> > >> >>> This SF.net email is sponsored by > >> > >> Make an app they can't live without > >> Enter the BlackBerry Developer Challenge > >> http://p.sf.net/sfu/RIM-dev2dev > >> _______________________________________________ > >> Amforth-devel mailing list > >> Amf...@li... > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >> > > > > > > > ------------------------------------------------------------------------------ > > > > > This SF.net email is sponsored by > > > > Make an app they can't live without > > Enter the BlackBerry Developer Challenge > > http://p.sf.net/sfu/RIM-dev2dev > > _______________________________________________ > > Amforth-devel mailing list > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: <an...@ki...> - 2010-08-16 10:26:06
|
Lol It was supposed to be mainstream about 2 years ago. Check out the forums on AVR Freaks. Got some on order, just waiting delivery, then we can have a play. On 16/08/10 08:19, pito wrote: > Matthias, > mind an average windoze user cannot run the provided python files > (I've tried python 3.x and 2.7 as well). It would be great to find > an python expert who is able to port the stuff to windoze python.. > And yes, the 1284P is DIL40 and 44smd drop in replacement for 32 and > 644. My guess is it will be the mainstream for the next 2y. > Pito. > > ----- PŮVODNÍ ZPRÁVA ----- > Od: "Matthias Trute" <mt...@we...> > Komu: "Everything around amforth" > <amf...@li...> > Předmět: Re: [Amforth-devel] Atmega 1284p > Datum: 15.8.2010 - 9:46:26 > >> Pito, >> >>> Hi, There is the atmega1284p available (128k >>> flash, 16k ram, dil40) >>>> - drop in replacement of 32, 64 - so quite sexy >>> chip. Do you plan to >>>> support it? P. >> >> amforth has a utility named pd2amforth that >> creates the device >> specific driver files. All of the currently >> delivered controller >> files (core/devices/*) are generated with that >> tool. I excpect no >> problems with that new controller, it should work. >> Formal support is >> unlikly, I cannot buy each controller type and >> test it myself, sorry. >> >> Matthias >> >> >> >> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Amforth-devel mailing list >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: pito <pi...@vo...> - 2010-08-16 07:19:32
|
Matthias, mind an average windoze user cannot run the provided python files (I've tried python 3.x and 2.7 as well). It would be great to find an python expert who is able to port the stuff to windoze python.. And yes, the 1284P is DIL40 and 44smd drop in replacement for 32 and 644. My guess is it will be the mainstream for the next 2y. Pito. ----- PŮVODNÍ ZPRÁVA ----- Od: "Matthias Trute" <mt...@we...> Komu: "Everything around amforth" <amf...@li...> Předmět: Re: [Amforth-devel] Atmega 1284p Datum: 15.8.2010 - 9:46:26 > Pito, > > > Hi, There is the atmega1284p available (128k > > flash, 16k ram, dil40) > > > - drop in replacement of 32, 64 - so quite sexy > > chip. Do you plan to > > > support it? P. > > amforth has a utility named pd2amforth that > creates the device > specific driver files. All of the currently > delivered controller > files (core/devices/*) are generated with that > tool. I excpect no > problems with that new controller, it should work. > Formal support is > unlikly, I cannot buy each controller type and > test it myself, sorry. > > Matthias > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Marcin C. <sa...@sa...> - 2010-08-15 20:23:42
|
Hello, as the FreeBSD user I decided to give avra a try.
It was necessary to add some patches to the assembler and
one dubious change to amforth, but it works very well,
and even .hex files are the same when produced by avra
and the Atmel tool.
I have posted patches to the newest avra (trunk, they might
work with 1.3.0 release) on Sourceforge:
3044547 Error:: ldi can only use a high register (r16 - r31)
https://sourceforge.net/tracker/?func=detail&aid=3044547&group_id=55499&atid=477233
3044545 movw y, z causes Error:: No register associated with y and z
https://sourceforge.net/tracker/?func=detail&aid=3044545&group_id=55499&atid=477233
3044541 .ifndef does not work (Can't redefine constant, use .SET)
https://sourceforge.net/tracker/?func=detail&aid=3044541&group_id=55499&atid=477233
As per suggestion I am using Atmel include files taked from the latest
AVR Studio (I place them in /usr/local/libdata/avra and modify avr-build.xml
accordingly).
The only (trivial) issue left is that avra checks all code ranges
produced by the assembler and complains if overlap occurs.
Atmel assembler does not care and happily produces two lines
in HEX file for the same range.
This happens when the serial rx or tx via IRQ is enabled,
core/devices/atmega328p/device.asm produces:
.org $024
rcall isr ; USART Rx Complete
.org $026
rcall isr ; USART, Data Register Empty
and core/drivers/usart-isr-[rt]x.asm produce:
.org URXCaddr (or .org UDREaddr)
jmp_ usart_rx_isr
I have enclosed a silly patch (irq.patch) that encloses them
info .ifdefs to avoid producing overlapping assembly.
I am not sure this is the right way to handle it, though.
Enclosed please find also patches to solve flash size
exceeded problem when producing .hex files for arduino.
One question by the way: At amforth_interpreter (0x3800 in case of
328p) we start the inner interpreter (label DO_DODOES).
Wouldn't that make sense to to have an additional "jmp_ amforthstart"
there as well? This would probably allow booting Amforth independent
of the BOOTRST fuse setting.
And finally, there is a patch attached for ant files to
call avra. I am flashing one Arduino board (ATmega 328p
Duemilanove) with another one (ATmega168 Freeduino) via
In-circuit Serial Programming.
--Marcin
|
|
From: <an...@ki...> - 2010-08-15 11:04:17
|
Yup just got the info and compared info. These are drop in's. I will see if I can find a supplier for the DIL package option. Well spotted Pito. You are a star. Just revised my board layouts and building a prototype. (I will socket it this time). When I am happy with the board layout I will publish it via my home web site and probably via RepRap too. Cheers Andy kirby On 15/08/10 11:49, an...@ki... wrote: > If it is available as a DIL 40 and a drop in for the 644p. I don't mind > getting a couple and trying them in the minimalist board I have designed > and built that emulates the Sanguino. > > > > On 15/08/10 08:46, Matthias Trute wrote: >> Pito, >> >>> Hi, There is the atmega1284p available (128k flash, 16k ram, dil40) >>> - drop in replacement of 32, 64 - so quite sexy chip. Do you plan to >>> support it? P. >> >> amforth has a utility named pd2amforth that creates the device >> specific driver files. All of the currently delivered controller >> files (core/devices/*) are generated with that tool. I excpect no >> problems with that new controller, it should work. Formal support is >> unlikly, I cannot buy each controller type and test it myself, sorry. >> >> Matthias >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Amforth-devel mailing list >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: <an...@ki...> - 2010-08-15 10:49:46
|
If it is available as a DIL 40 and a drop in for the 644p. I don't mind getting a couple and trying them in the minimalist board I have designed and built that emulates the Sanguino. On 15/08/10 08:46, Matthias Trute wrote: > Pito, > >> Hi, There is the atmega1284p available (128k flash, 16k ram, dil40) >> - drop in replacement of 32, 64 - so quite sexy chip. Do you plan to >> support it? P. > > amforth has a utility named pd2amforth that creates the device > specific driver files. All of the currently delivered controller > files (core/devices/*) are generated with that tool. I excpect no > problems with that new controller, it should work. Formal support is > unlikly, I cannot buy each controller type and test it myself, sorry. > > Matthias > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Matthias T. <mt...@we...> - 2010-08-15 07:46:35
|
Pito, > Hi, There is the atmega1284p available (128k flash, 16k ram, dil40) > - drop in replacement of 32, 64 - so quite sexy chip. Do you plan to > support it? P. amforth has a utility named pd2amforth that creates the device specific driver files. All of the currently delivered controller files (core/devices/*) are generated with that tool. I excpect no problems with that new controller, it should work. Formal support is unlikly, I cannot buy each controller type and test it myself, sorry. Matthias |
|
From: <an...@ki...> - 2010-08-14 21:00:31
|
As far as I was aware the largest (Memory device) in a DIL package was the 644p. If there is one better I would be interested. Especially if it is a drop in for the 644p but having more memory etc. Haven't seen one yet though. That is why Arduino Mega which is a 1280 although it is a surface mount only package. I am all ears do tell. Cheers Andy Kirby On 14/08/10 21:18, pito wrote: > Hi, There is the atmega1284p available (128k flash, 16k ram, dil40) > - drop in replacement of 32, 64 - so quite sexy chip. Do you plan to > support it? P. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: pito <pi...@vo...> - 2010-08-14 20:19:00
|
Hi, There is the atmega1284p available (128k flash, 16k ram, dil40) - drop in replacement of 32, 64 - so quite sexy chip. Do you plan to support it? P. |
|
From: pito <pi...@vo...> - 2010-08-14 20:13:31
|
Hi Erich, my idea was to stop FTDI (or PC when none usb is used) during critical activities amforth does. Without any special tools like python apps. So ideally I need to know the points I have to pull CTS of the FTDI high. One is the flashing. The second would be the parsing. And so on. I am sure by this kind of handshake you may eliminate special tools. My goal is 115k baud with any terminal programme. Other issue is to have a small rx buffer implemented. However, the cooperation of experts is required.. Pito ----- PŮVODNÍ ZPRÁVA ----- Od: "Erich Waelde" <ew....@na...> Komu: "Everything around amforth" <amf...@li...> Předmět: Re: [Amforth-devel] Serial - CTS - word compilation Datum: 13.8.2010 - 20:48:02 > Hello Pito, > > On 08/13/2010 02:17 PM, pito wrote: > > ... > > > > However, when using Terraterm, HW handshake, no > > delays, no waiting > > > on 'ok', it does not work. The question is > > whether amforth needs to > > > stop receiving after each character in order to > > process it, and - > > > whether there is a input buffer, as the FTDI may > > shoot few bytes > > > (from its buffer)even CTS is pulled high - so > > one need tu pull CTS > > > high before the input buffer is full. > > So it is not so easy as I assumed...Pito. > > Well, the character need to be stored and are > echoed back. > On receiving CRLF amforth will start to parse the > received line > and execute it accordingly. After that a new > prompt is issued. > > This is the reason, why amforth-upload.py waits > for the echoed > character to be received, and after a CRLF waits > for the ok prompt. > This is a handshake of sorts. > > > >... > >> I hope the code is correct.. > >> When upload e.g. the _sieve_ you can see how > >> the > >> >> amforth flashes. > >> Quite surprised - so many flashes to see.. So > >> you > >> >> do not buffer the > >> whole word to be compiled but do flashes line > >> by > >> > If you look into the code, you will find that the > inner workings > of i! will check, whether there are any bits, > which will go from > 0 (zero) to 1 (one). IFF that is the case, the > correspondig block > is copied to a separate area and updated, the > original block is > erased and then rewritten. "block" refers to a > logical chunk of > flash memory. This is as good as it can get in > order to write > into flash, but not loosing too much time by > rewriting every > block every time. > > > Cheers, > Erich > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Erich W. <ew....@na...> - 2010-08-13 18:48:16
|
Hello Pito, On 08/13/2010 02:17 PM, pito wrote: > ... > > However, when using Terraterm, HW handshake, no delays, no waiting > on 'ok', it does not work. The question is whether amforth needs to > stop receiving after each character in order to process it, and - > whether there is a input buffer, as the FTDI may shoot few bytes > (from its buffer)even CTS is pulled high - so one need tu pull CTS > high before the input buffer is full. > So it is not so easy as I assumed...Pito. Well, the character need to be stored and are echoed back. On receiving CRLF amforth will start to parse the received line and execute it accordingly. After that a new prompt is issued. This is the reason, why amforth-upload.py waits for the echoed character to be received, and after a CRLF waits for the ok prompt. This is a handshake of sorts. >... >> I hope the code is correct.. >> When upload e.g. the _sieve_ you can see how the >> amforth flashes. >> Quite surprised - so many flashes to see.. So you >> do not buffer the >> whole word to be compiled but do flashes line by If you look into the code, you will find that the inner workings of i! will check, whether there are any bits, which will go from 0 (zero) to 1 (one). IFF that is the case, the correspondig block is copied to a separate area and updated, the original block is erased and then rewritten. "block" refers to a logical chunk of flash memory. This is as good as it can get in order to write into flash, but not loosing too much time by rewriting every block every time. Cheers, Erich |
|
From: Erich W. <ew....@na...> - 2010-08-13 18:39:39
|
Hi Ken, On 08/13/2010 01:55 AM, ken...@al... wrote: > Thank you. The new fuse values got my BBB (a "freeduino" clone of the > arduino duemilanove) working. I will have to go back and see if I still > have to use polling input rather than the rx isr. using polling or isr communication is, as far as I can tell, more a matter of taste than anything else. Some folks have strong opinions on this subject. I have used both successfully. YMMV. Cheers, Erich |
|
From: Erich W. <ew....@na...> - 2010-08-13 18:34:09
|
Hi Christian,
On 08/13/2010 09:35 AM, Christian Kellermann wrote:
> Hi Erich!
>
> * Erich Waelde<ew....@na...> [100812 19:26]:
>> With help from Matthias it was found that the fuse settings were causing this.
>>
>> Using
>>
>> avrdude: reading hfuse memory: 0xd9
>> avrdude: reading lfuse memory: 0xff
>> avrdude: reading efuse memory: 0x05
>>
>> everything works as expected.
>> Please note that the above settings are different from what is found in
>> releases/4.0/appl/arduino/readme.txt
>
> Many thanks for debugging this! In which way apart from the fuses
> does your setup differ from the default one in the release/subversion
> repository?
use the files found in releases/4.0/appl/arduino
and move the line
.include "dict_minimum.inc"
from dict_appl_core.inc to dict_appl.inc
create a makefile (stolen from appl/template :-)
Please find a diff appended.
Cheers,
Erich
diff -Naur ../amforth/releases/4.0/appl/arduino/dict_appl_core.inc arduino//dict_appl_core.inc
--- ../amforth/releases/4.0/appl/arduino/dict_appl_core.inc 2010-07-02 21:16:37.000000000 +0200
+++ arduino//dict_appl_core.inc 2010-08-13 20:25:35.000000000 +0200
@@ -6,8 +6,6 @@
.include "words/istore_nrww.asm"
.include "words/ifetch.asm"
-.include "dict_minimum.inc"
-
.include "words/d-2star.asm"
.include "words/d-plus.asm"
.include "words/d-minus.asm"
@@ -31,4 +29,4 @@
.include "dict_compiler.inc"
.include "words/show-wordlist.asm"
-.include "device.inc"
\ No newline at end of file
+.include "device.inc"
diff -Naur ../amforth/releases/4.0/appl/arduino/dict_appl.inc arduino//dict_appl.inc
--- ../amforth/releases/4.0/appl/arduino/dict_appl.inc 2010-07-02 21:16:37.000000000 +0200
+++ arduino//dict_appl.inc 2010-08-13 20:25:48.000000000 +0200
@@ -2,3 +2,5 @@
; they may be moved to the core dictionary if needed
.include "dict_usart.inc"
+.include "dict_minimum.inc"
+
diff -Naur ../amforth/releases/4.0/appl/arduino/makefile arduino//makefile
--- ../amforth/releases/4.0/appl/arduino/makefile 1970-01-01 01:00:00.000000000 +0100
+++ arduino//makefile 2010-08-13 20:23:46.000000000 +0200
@@ -0,0 +1,87 @@
+# simple makefile for building the
+# template project.
+
+# sometimes the login shell causes trouble
+SHELL=/bin/bash
+
+# --- edit these values ------------------------------------
+# Name of your application (useful, if you rename template.asm)
+TARGET=duemilanove
+
+# versions before 2.1 may produce some warnings
+# but should produce a running system. You should
+# _always_ use the trunk.
+
+AMFORTH=../../amforth/releases/4.0/core
+#AMFORTH=../../core
+
+# the MCU should be identical to the device
+# setting in template.asm
+MCU=atmega328p
+
+# set the fuses according to your MCU
+LFUSE=0xFF
+HFUSE=0xD9
+# some MCU have this one, see write-fuses target below
+EFUSE=0x05
+
+# serial port
+CONSOLE=/dev/ttyUSB0
+
+# directories
+DIR_ATMEL=~/wine/AvrAssembler2
+
+# programms / flags
+SP12=-c sp12 -i 10 -P /dev/parport0
+USB=-c avr911 -P /dev/ttyUSB3
+PP=-c stk200 -P /dev/parport0
+JTAG=-c jtag2 -P /dev/ttyUSB2
+BURNER=$(SP12)
+AVRDUDE=avrdude
+AVRDUDE_FLAGS=-q $(BURNER) -p $(MCU)
+
+AVRA=avra -I $(DIR_ATMEL)/Appnotes2
+
+AVRASM=wine $(DIR_ATMEL)/avrasm2.exe -I $(DIR_ATMEL)/Appnotes
+
+# ----------------------------------------------------------
+
+INCLUDE=-I $(AMFORTH) -I $(AMFORTH)/devices/$(MCU)
+
+default: $(TARGET).hex
+
+erase:
+ $(AVRDUDE) $(AVRDUDE_FLAGS) -e
+
+marker:
+ amforth-upload.py -t ${CONSOLE} lib/misc.frt lib/bitnames.frt lib/ans94/marker.frt devices/atmega328p.frt
+
+install: $(TARGET).hex
+ $(AVRDUDE) $(AVRDUDE_FLAGS) -e -U flash:w:$(TARGET).hex:i -U eeprom:w:$(TARGET).eep.hex:i
+
+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
+
+$(TARGET).hex: $(TARGET).asm $(AMFORTH)/*.asm $(AMFORTH)/words/*.asm $(AMFORTH)/devices/$(MCU)/*.asm
+# $(AVRA) $(INCLUDE) --listmac -l $(TARGET).lst -m $(TARGET).map $(TARGET).asm
+ $(AVRASM) $(INCLUDE) -fI -v0 -e $(TARGET).eep.hex -l $(TARGET).lst $(TARGET).asm
+
+$(TARGET).back:
+ $(AVRDUDE) $(AVRDUDE_FLAGS) -U flash:r:$(TARGET).hex:i -U eeprom:r:$(TARGET).eep.hex:i
+
+clean:
+ rm -f $(TARGET).hex
+ rm -f $(TARGET).eep.hex
+ rm -f $(TARGET).lst
+ rm -f $(TARGET).map
+ rm -f $(TARGET).cof
+ rm -f $(TARGET).obj
+
+write-fuse:
+ $(AVRDUDE) $(AVRDUDE_FLAGS) -U efuse:w:$(EFUSE):m -U hfuse:w:$(HFUSE):m -U lfuse:w:$(LFUSE):m
+
+read-fuse:
+ $(AVRDUDE) $(AVRDUDE_FLAGS) -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h
|
|
From: pito <pi...@vo...> - 2010-08-13 12:18:03
|
Hi, I've tried the CTS stuff with amforth but not succesfully yet (as I can remeber with that basic it worked ..). I did following (pls mind the reverse CTS against my previuos post)> PORTB 0 portpin: LED ( LED flashes when amforth flashes the flash) PORTD 2 portpin: CTS ( FTDI CTS: when HIGH it indicates to FTDI to stop) : i_cts! CTS pin_output LED pin_output LED high CTS high (i!) LED low CTS low ; ' i_cts! is i! However, when using Terraterm, HW handshake, no delays, no waiting on 'ok', it does not work. The question is whether amforth needs to stop receiving after each character in order to process it, and - whether there is a input buffer, as the FTDI may shoot few bytes (from its buffer)even CTS is pulled high - so one need tu pull CTS high before the input buffer is full. So it is not so easy as I assumed...Pito. ----- PŮVODNÍ ZPRÁVA ----- Od: "pito" <pi...@vo...> Komu: mt...@we..., amf...@li... Předmět: Re: [Amforth-devel] Serial - CTS - word compilation Datum: 13.8.2010 - 11:22:02 > Matthias, thanks for the hint! I immediately (as a > first step) did > the visualization of the flash writes (an blue LED > attached via 1k > to PB.0 and ground, so when PB.0 is high it lits): > > PORTB 0 portpin: PB.0 > > : i_see! PB.0 pin_output PB.0 high (i!) PB.0 low ; > > ' i_see! is i! > > I hope the code is correct.. > When upload e.g. the _sieve_ you can see how the > amforth flashes. > Quite surprised - so many flashes to see.. So you > do not buffer the > whole word to be compiled but do flashes line by > line.. > P. > > ----- PŮVODNÍ ZPRÁVA ----- > Od: "Matthias Trute" <mt...@we...> > Komu: "Everything around amforth" > <amf...@li...> > Předmět: Re: [Amforth-devel] Serial - CTS - word > compilation > Datum: 13.8.2010 - 8:00:29 > > > Hi, > > > > > > > The routine which flashes the flash with a new > > > compiled word shall > > > > simply at very beginning put the CTS signal > > > > to > > > > > > LOW and when finished > > > > put back to HIGH. > > > > Its easy to do since i! is a deferred word to > > (i!). You may define > > your own word which pre and post process > > anything > > > you want and call > > (i1) inside. > > > > In addition you can add a plausibility check for > > the addresses as well > > and increase the robustness at all. > > > > If you send me your code I may include it as an > > example. > > > > > > Matthias > > > > > > > > ------------------------------------------------------------------------------ > > > > > > This SF.net email is sponsored by > > > > Make an app they can't live without > > Enter the BlackBerry Developer Challenge > > http://p.sf.net/sfu/RIM-dev2dev > > _______________________________________________ > > Amforth-devel mailing list > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: pito <pi...@vo...> - 2010-08-13 09:22:10
|
Matthias, thanks for the hint! I immediately (as a first step) did the visualization of the flash writes (an blue LED attached via 1k to PB.0 and ground, so when PB.0 is high it lits): PORTB 0 portpin: PB.0 : i_see! PB.0 pin_output PB.0 high (i!) PB.0 low ; ' i_see! is i! I hope the code is correct.. When upload e.g. the _sieve_ you can see how the amforth flashes. Quite surprised - so many flashes to see.. So you do not buffer the whole word to be compiled but do flashes line by line.. P. ----- PŮVODNÍ ZPRÁVA ----- Od: "Matthias Trute" <mt...@we...> Komu: "Everything around amforth" <amf...@li...> Předmět: Re: [Amforth-devel] Serial - CTS - word compilation Datum: 13.8.2010 - 8:00:29 > Hi, > > > > The routine which flashes the flash with a new > > compiled word shall > > > simply at very beginning put the CTS signal to > > LOW and when finished > > > put back to HIGH. > > Its easy to do since i! is a deferred word to > (i!). You may define > your own word which pre and post process anything > you want and call > (i1) inside. > > In addition you can add a plausibility check for > the addresses as well > and increase the robustness at all. > > If you send me your code I may include it as an > example. > > > Matthias > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Christian K. <ck...@pe...> - 2010-08-13 08:17:09
|
Hi Erich! * Erich Waelde <ew....@na...> [100812 19:26]: > With help from Matthias it was found that the fuse settings were causing this. > > Using > > avrdude: reading hfuse memory: 0xd9 > avrdude: reading lfuse memory: 0xff > avrdude: reading efuse memory: 0x05 > > everything works as expected. > Please note that the above settings are different from what is found in > releases/4.0/appl/arduino/readme.txt Many thanks for debugging this! In which way apart from the fuses does your setup differ from the default one in the release/subversion repository? Kind regards, Christian |
|
From: Matthias T. <mt...@we...> - 2010-08-13 06:00:39
|
Hi, > The routine which flashes the flash with a new compiled word shall > simply at very beginning put the CTS signal to LOW and when finished > put back to HIGH. Its easy to do since i! is a deferred word to (i!). You may define your own word which pre and post process anything you want and call (i1) inside. In addition you can add a plausibility check for the addresses as well and increase the robustness at all. If you send me your code I may include it as an example. Matthias |
|
From: <ken...@al...> - 2010-08-12 23:55:39
|
Thank you. The new fuse values got my BBB (a "freeduino" clone of the arduino duemilanove) working. I will have to go back and see if I still have to use polling input rather than the rx isr. Regards, Ken On Thu, 12 Aug 2010 19:24 +0200, "Erich Waelde" <ew....@na...> wrote: > For the records: > > With help from Matthias it was found that the fuse settings were causing > this. > > Using > > avrdude: reading hfuse memory: 0xd9 > avrdude: reading lfuse memory: 0xff > avrdude: reading efuse memory: 0x05 > > everything works as expected. > Please note that the above settings are different from what is found in > releases/4.0/appl/arduino/readme.txt > > > Cheers, > Erich > > > > ver > amforth 3.8 ATmega328P ok > > words > i@ (i!) i! e@ e! not s>d up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +! > rshift lshift 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log > 2 d< d> 0> u> u< true 0 0< > < 0= = <> r@ >r r> rot drop over swap ?dup > dup c@ c! ! @ execute exit -int +int fill show-wordlist order ge > t-order get-current environment? environment end-code code abort abort" > [char] immediate recurse user constant variable [ ] ; :noname : > does> create ?do leave +loop loop do again until repeat while begin then > else if literal int! applturnkey +usart baud tx? tx rx? rx is R > defer Edefer words s" ." .s u. dinvert d- d+ d2* init-user ee>ram ee-user > tib d2/ cmove dnegate dabs d>s j * defer@ defer! icompare find > search-wordlist to value unused noop ver ?stack interpret depth rp0 sp > sp0 cold pause quit place word /string source cscan parse 2swap > >number number char refill accept cskip throw catch handler ' type count spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r > d.r sign #> #s # <# hold hld within max min abs mod / negate u/mod */ > /mod */mod turnkey heap edp bl hex decimal bin ['] , compile ( \ a > llot here /key key? key emit? emit pad #tib >in cell+ cells base state > f_cpu ok > > : one 1 ; > ok > > 1 2 3 .s > 0 2217 3 > 1 2219 2 > 2 2221 1 > ok > > one > ok > > .s > 0 2215 1 > 1 2217 3 > 2 2219 2 > 3 2221 1 > ok > > > > On 08/07/2010 08:45 PM, Erich Waelde wrote: > > Hello, > > > > playing with an duemilanove board (atmega328p). > > > > I'm building this from files in amforth/releases/4.0/app/template > > not from the arduino directory. This setup is big enough to just > > work (tested on atmega32). > > > > So with the following changes to template.asm > > diff -wu template.asm ../../amforth/releases/4.0/appl/template/template.asm > > --- template.asm 2010-08-07 20:31:40.000000000 +0200 > > +++ ../../amforth/releases/4.0/appl/template/template.asm 2010-07-02 21:16:39.000000000 +0200 > > @@ -12,19 +12,12 @@ > > ; files include the *def.inc from atmel internally. > > .include "device.asm" > > > > -; fixes for atmega328p > > -.equ TXEN = TXEN0 > > -.equ UCSZ0 = UCSZ00 > > -.equ RXEN = RXEN0 > > -.equ RXCIE = RXCIE0 > > - > > - > > ; amforth needs two essential parameters > > ; cpu clock in hertz, 1MHz is factory default > > -.equ F_CPU = 16000000 > > +.equ F_CPU = 8000000 > > > > ; initial baud rate of terminal > > -.include "drivers/usart_0.asm" > > +.include "drivers/usart.asm" > > .equ BAUD = 9600 > > .equ USART_B_VALUE = (1<<TXEN) | (1<<RXEN) | (1<<RXCIE) > > .equ USART_C_VALUE = (3<<UCSZ0) > > > > > > and > > MCU=atmega328p > > in makefile, I can successfully build an amforth, upload it to the controller, > > and talk to it: > > > > > ok > > > > > ok > > > ver > > amforth 4.0 ATmega328P ok > > > words > > i@ (i!) i! e@ e! not s>d up! up@>< cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log > > 2 d< d> 0> u> u< true 0 0< > < 0= =<> r@>r r> rot drop over swap ?dup dup c@ c! ! @ execute exit -int +int show-wordlist +usart baud t > > x? tx rx? rx order get-order get-current environment? environment end-code code abort abort" [char] immediate recurse user constant vari > > able [ ] ; :noname : does> create ?do leave +loop loop do again until repeat while begin then else if literal int! applturnkey is Rdefer > > Edefer words s" ." .s u. dinvert d- d+ d2* init-user ee>ram ee-user tib d2/ cmove dnegate dabs d>s j * defer@ defer! icompare find sear > > ch-wordlist to value unused noop ver ?stack interpret depth rp0 sp sp0 cold pause quit place word /string source cscan parse 2swap>numb > > er number char refill accept cskip throw catch handler ' type count spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r s > > ign #> #s #<# hold hld within max min abs mod / negate u/mod */ /mod */mod turnkey bl hex decimal bin ['] , compile ( \ allot here edp > > dp /key key? key emit? emit pad #tib>in cell+ cells base state f_cpu ok > > > > > > HOWEVER, after trying to create a new word, it stops working: > > > > > : one 1 ; > > ?? -13 10 > > > 1 .s > > ?? -13 5 > > > .s > > ?? -13 3 > > > .s > > ?? -13 3 > > > 1 > > ok > > > . > > ok > > > depth > > ?? -13 6 > > > > This looks to me like the pointer to the wordlist has gone off into the wild. > > Comparing template.asm to arduino/duemilanove.asm does not show suspicious > > differences (see below). > > > > More ideas? > > Erich > > > > > > diff -wu template.asm ../../amforth/releases/4.0/appl/arduino/duemilanove.asm | less > > --- template.asm 2010-08-07 20:31:40.000000000 +0200 > > +++ ../../amforth/releases/4.0/appl/arduino/duemilanove.asm 2010-07-02 21:16:37.000000000 +0200 > > @@ -1,48 +1,23 @@ > > -; This is a template for an amforth project. > > -; > > -; The order of the entries (esp the include order) must not be > > -; changed since it is very important that the settings are in the > > -; right order > > -; > > -; first is to include the macros from the amforth > > -; directory > > .include "macros.asm" > > - > > -; include the amforth device definition file. These > > -; files include the *def.inc from atmel internally. > > .include "device.asm" > > > > -; fixes for atmega328p > > -.equ TXEN = TXEN0 > > -.equ UCSZ0 = UCSZ00 > > -.equ RXEN = RXEN0 > > -.equ RXCIE = RXCIE0 > > - > > + .equ HLDSIZE = $10 ; 16 bit cellsize with binary representation > > + .equ TIBSIZE = $64 ; 80 characters is one line... > > + .equ APPUSERSIZE = 0 ; size of application user area > > > > -; amforth needs two essential parameters > > -; cpu clock in hertz, 1MHz is factory default > > +; cpu clock in hertz > > .equ F_CPU = 16000000 > > - > > -; initial baud rate of terminal > > +; baud rate of terminal > > .include "drivers/usart_0.asm" > > .equ BAUD = 9600 > > -.equ USART_B_VALUE = (1<<TXEN) | (1<<RXEN) | (1<<RXCIE) > > -.equ USART_C_VALUE = (3<<UCSZ0) > > - > > - > > -.equ HLDSIZE = $10 ; 16 bit cellsize with binary representation > > -.equ TIBSIZE = $64 ; ANS94 needs at least 80 characters per line > > -.equ APPUSERSIZE = 0 ; size of application specific user area in bytes > > - > > -; addresses of various data segments > > -.set here = ramstart ; initial HERE at compile time, grows upward > > -.set rstackstart = RAMEND ; start address of return stack, grows downward > > -.set stackstart = RAMEND - 80 ; start address of data stack, grows downward > > -.equ amforth_interpreter = max_dict_addr ; the same value as NRWW_START_ADDR > > -; change only if you know what to you do > > -.equ NUMWORDLISTS = 8 ; number of word lists in the searh order, at least 8 > > +.equ USART_B_VALUE = (1<<TXEN0) | (1<<RXEN0) | (1<<RXCIE0) > > +.equ USART_C_VALUE = (1<<UCSZ01) | ( 1<<UCSZ00) > > > > -.equ want_fun = 0 ; in case of an error out print an additional line with an caret indicating the error position > > +.set here = ramstart ; start address of HERE, grows upward > > +.set rstackstart = RAMEND > > +.set stackstart = RAMEND - 80 > > +.set amforth_interpreter = max_dict_addr > > > > -; include the whole source tree. > > +.set NUMWORDLISTS = 8 > > +.equ want_fun = 0 > > .include "amforth.asm" > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by > > > > Make an app they can't live without > > Enter the BlackBerry Developer Challenge > > http://p.sf.net/sfu/RIM-dev2dev > > _______________________________________________ > > Amforth-devel mailing list > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: pito <pi...@vo...> - 2010-08-12 22:12:41
|
Hi, I've seen in an atmel Basic implementation (and I've tried - it works) a feature which may help amforth with the required delay during the flashing the new word - to use CTS signal. The routine which flashes the flash with a new compiled word shall simply at very beginning put the CTS signal to LOW and when finished put back to HIGH. The LOW on CTS tells the PC side not to send data. So no delays needs to be set in terminal. As the most of users use FTDI USB-RS232: one pin of atmega (defined as output) shall be connected to CTS. The DTR<->DSR at atmega side connected together. Pito |
|
From: Erich W. <ew....@na...> - 2010-08-12 17:25:57
|
For the records: With help from Matthias it was found that the fuse settings were causing this. Using avrdude: reading hfuse memory: 0xd9 avrdude: reading lfuse memory: 0xff avrdude: reading efuse memory: 0x05 everything works as expected. Please note that the above settings are different from what is found in releases/4.0/appl/arduino/readme.txt Cheers, Erich > ver amforth 3.8 ATmega328P ok > words i@ (i!) i! e@ e! not s>d up! up@ >< cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log 2 d< d> 0> u> u< true 0 0< > < 0= = <> r@ >r r> rot drop over swap ?dup dup c@ c! ! @ execute exit -int +int fill show-wordlist order ge t-order get-current environment? environment end-code code abort abort" [char] immediate recurse user constant variable [ ] ; :noname : does> create ?do leave +loop loop do again until repeat while begin then else if literal int! applturnkey +usart baud tx? tx rx? rx is R defer Edefer words s" ." .s u. dinvert d- d+ d2* init-user ee>ram ee-user tib d2/ cmove dnegate dabs d>s j * defer@ defer! icompare find search-wordlist to value unused noop ver ?stack interpret depth rp0 sp sp0 cold pause quit place word /string source cscan parse 2swap >number number char refill accept cskip throw catch handler ' type count spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r sign #> #s # <# hold hld within max min abs mod / negate u/mod */ /mod */mod turnkey heap edp bl hex decimal bin ['] , compile ( \ a llot here /key key? key emit? emit pad #tib >in cell+ cells base state f_cpu ok > : one 1 ; ok > 1 2 3 .s 0 2217 3 1 2219 2 2 2221 1 ok > one ok > .s 0 2215 1 1 2217 3 2 2219 2 3 2221 1 ok On 08/07/2010 08:45 PM, Erich Waelde wrote: > Hello, > > playing with an duemilanove board (atmega328p). > > I'm building this from files in amforth/releases/4.0/app/template > not from the arduino directory. This setup is big enough to just > work (tested on atmega32). > > So with the following changes to template.asm > diff -wu template.asm ../../amforth/releases/4.0/appl/template/template.asm > --- template.asm 2010-08-07 20:31:40.000000000 +0200 > +++ ../../amforth/releases/4.0/appl/template/template.asm 2010-07-02 21:16:39.000000000 +0200 > @@ -12,19 +12,12 @@ > ; files include the *def.inc from atmel internally. > .include "device.asm" > > -; fixes for atmega328p > -.equ TXEN = TXEN0 > -.equ UCSZ0 = UCSZ00 > -.equ RXEN = RXEN0 > -.equ RXCIE = RXCIE0 > - > - > ; amforth needs two essential parameters > ; cpu clock in hertz, 1MHz is factory default > -.equ F_CPU = 16000000 > +.equ F_CPU = 8000000 > > ; initial baud rate of terminal > -.include "drivers/usart_0.asm" > +.include "drivers/usart.asm" > .equ BAUD = 9600 > .equ USART_B_VALUE = (1<<TXEN) | (1<<RXEN) | (1<<RXCIE) > .equ USART_C_VALUE = (3<<UCSZ0) > > > and > MCU=atmega328p > in makefile, I can successfully build an amforth, upload it to the controller, > and talk to it: > > > ok > > > ok > > ver > amforth 4.0 ATmega328P ok > > words > i@ (i!) i! e@ e! not s>d up! up@>< cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift 1- 1+ xor or and 2* 2/ invert um* um/mod m* + - log > 2 d< d> 0> u> u< true 0 0< > < 0= =<> r@>r r> rot drop over swap ?dup dup c@ c! ! @ execute exit -int +int show-wordlist +usart baud t > x? tx rx? rx order get-order get-current environment? environment end-code code abort abort" [char] immediate recurse user constant vari > able [ ] ; :noname : does> create ?do leave +loop loop do again until repeat while begin then else if literal int! applturnkey is Rdefer > Edefer words s" ." .s u. dinvert d- d+ d2* init-user ee>ram ee-user tib d2/ cmove dnegate dabs d>s j * defer@ defer! icompare find sear > ch-wordlist to value unused noop ver ?stack interpret depth rp0 sp sp0 cold pause quit place word /string source cscan parse 2swap>numb > er number char refill accept cskip throw catch handler ' type count spaces space cr icount itype s, digit? ud/mod ud.r ud. . d. .r d.r s > ign #> #s #<# hold hld within max min abs mod / negate u/mod */ /mod */mod turnkey bl hex decimal bin ['] , compile ( \ allot here edp > dp /key key? key emit? emit pad #tib>in cell+ cells base state f_cpu ok > > > HOWEVER, after trying to create a new word, it stops working: > > > : one 1 ; > ?? -13 10 > > 1 .s > ?? -13 5 > > .s > ?? -13 3 > > .s > ?? -13 3 > > 1 > ok > > . > ok > > depth > ?? -13 6 > > This looks to me like the pointer to the wordlist has gone off into the wild. > Comparing template.asm to arduino/duemilanove.asm does not show suspicious > differences (see below). > > More ideas? > Erich > > > diff -wu template.asm ../../amforth/releases/4.0/appl/arduino/duemilanove.asm | less > --- template.asm 2010-08-07 20:31:40.000000000 +0200 > +++ ../../amforth/releases/4.0/appl/arduino/duemilanove.asm 2010-07-02 21:16:37.000000000 +0200 > @@ -1,48 +1,23 @@ > -; This is a template for an amforth project. > -; > -; The order of the entries (esp the include order) must not be > -; changed since it is very important that the settings are in the > -; right order > -; > -; first is to include the macros from the amforth > -; directory > .include "macros.asm" > - > -; include the amforth device definition file. These > -; files include the *def.inc from atmel internally. > .include "device.asm" > > -; fixes for atmega328p > -.equ TXEN = TXEN0 > -.equ UCSZ0 = UCSZ00 > -.equ RXEN = RXEN0 > -.equ RXCIE = RXCIE0 > - > + .equ HLDSIZE = $10 ; 16 bit cellsize with binary representation > + .equ TIBSIZE = $64 ; 80 characters is one line... > + .equ APPUSERSIZE = 0 ; size of application user area > > -; amforth needs two essential parameters > -; cpu clock in hertz, 1MHz is factory default > +; cpu clock in hertz > .equ F_CPU = 16000000 > - > -; initial baud rate of terminal > +; baud rate of terminal > .include "drivers/usart_0.asm" > .equ BAUD = 9600 > -.equ USART_B_VALUE = (1<<TXEN) | (1<<RXEN) | (1<<RXCIE) > -.equ USART_C_VALUE = (3<<UCSZ0) > - > - > -.equ HLDSIZE = $10 ; 16 bit cellsize with binary representation > -.equ TIBSIZE = $64 ; ANS94 needs at least 80 characters per line > -.equ APPUSERSIZE = 0 ; size of application specific user area in bytes > - > -; addresses of various data segments > -.set here = ramstart ; initial HERE at compile time, grows upward > -.set rstackstart = RAMEND ; start address of return stack, grows downward > -.set stackstart = RAMEND - 80 ; start address of data stack, grows downward > -.equ amforth_interpreter = max_dict_addr ; the same value as NRWW_START_ADDR > -; change only if you know what to you do > -.equ NUMWORDLISTS = 8 ; number of word lists in the searh order, at least 8 > +.equ USART_B_VALUE = (1<<TXEN0) | (1<<RXEN0) | (1<<RXCIE0) > +.equ USART_C_VALUE = (1<<UCSZ01) | ( 1<<UCSZ00) > > -.equ want_fun = 0 ; in case of an error out print an additional line with an caret indicating the error position > +.set here = ramstart ; start address of HERE, grows upward > +.set rstackstart = RAMEND > +.set stackstart = RAMEND - 80 > +.set amforth_interpreter = max_dict_addr > > -; include the whole source tree. > +.set NUMWORDLISTS = 8 > +.equ want_fun = 0 > .include "amforth.asm" > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Leon M. <leo...@gm...> - 2010-08-11 01:08:39
|
Awesome -- I'm all set then. Thanks again for explaining all this. -Leon |
|
From: Matthias T. <mt...@we...> - 2010-08-10 12:40:39
|
Leon, > The description of HERE reads "address of the next free dictionary > cell" -- which sounds like the old version. So is the code bleeding > edge but not the comments? Have you ever seen a valid and correct comment in source code? ;=) just fixed it, thank you. > So the html is based off the sources, which has definitions that are > essentially compiled by hand? Yes. > But if I were defining VARIABLE > interactively, ':' would take care of adding (LITERAL) for me? The (literal) is included automatically (and needs to get smarter somehow for dealing with double cell numbers, see Pitos bug with the 1.). > Is the "(CREATE) COMPILE COMPILE" in the definition of VARIABLE > another artifact of being compiled by hand? There is no compile compile... ? And never has been in variable.asm? the sequence "compile compile" can be the result of a "postpone compile" in real forth code. > If I were defining > VARIABLE interactively, I would be able to use CREATE? sure. The current definition is as follows: : variable here constant 2 allot ; Matthias |
8 messages has been excluded from this view by a project administrator.
