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
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jim F. <ja...@wa...> - 2011-07-13 16:31:38
|
I'd like to install Amforth on an Atmel Butterfly I have, and am currently waiting for delivery of a USBasp programmer. I anticipate using the pre-built hex files supplied with the distribution, loading them with 'avrdude'. Are there any 'gotchas' I need to be aware of? In particular, I'm hazy about 'fuses' and 'lock bits' - will I need to change any of them from the existing butterfly default? I'd be grateful for any advice here, please. Jim |
|
From: Matthias T. <mt...@we...> - 2011-06-29 18:15:33
|
Hi, the month is almost over, its time for a new release ;=) Version 4.5 changes mostly internal things and documentation. The recognizers got there final API with addr/len strings (and the interpreter code looks much messier.). This string representation is now used internally as well. Amforth does not use counted strings and WORD or FIND any longer itself. The new era uses PARSE-NAME and FIND-NAME. DIGIT? has now the same stack effect as gforth has (and does not accept 1@ any longer as a hex number) The arduino's have a modified default memory layout, resulting in approx 1KB more free dictionary space for the 328p and better devices. The older 168er devices still work, but need some un-doing the changes. Everything else at the changelog at http://amforth.sf.net/ Have fun Matthias |
|
From: Matthias T. <mt...@we...> - 2011-06-22 18:42:14
|
Hi Andrew, > The list of arduino boards 'supported' include the Mega with the > ATMega 1280 part. My question is waht are the differences between > the 1280 and 2560 ? is it simply that the one has more flash than > the other ? and the amforth will work fine on the 2560 part ? Just got my 2561 board working again. Amforth runs fine on it. No known errors so far. Matthias |
|
From: Erich W. <ew....@na...> - 2011-06-19 18:59:12
|
Hi Matthias, thanks for your lightning fast response! >> seems that refcard.tex has gone missing in revision 1092 > > This file is easily generated with make-refcard. found it. > Furthermore > I did not update it at every checkin that may have changed > its content. Thus I deleted it from the repository. For releases > and website updates I make pdf's, they are much better readable. > IMHO. agreed. Cheers, Erich |
|
From: Matthias T. <mt...@we...> - 2011-06-19 18:43:51
|
Hi Erich, > seems that refcard.tex has gone missing in revision 1092 This file is easily generated with make-refcard. Furthermore I did not update it at every checkin that may have changed its content. Thus I deleted it from the repository. For releases and website updates I make pdf's, they are much better readable. IMHO. HTH Matthias |
|
From: Erich W. <ew....@na...> - 2011-06-19 17:54:25
|
Hello Matthias,
seems that refcard.tex has gone missing in revision 1092
1092 978 mtrute amforth-userguide.odt
! + C - 985 mtrute refcard.tex
> local edit, incoming delete upon update
1092 1068 mtrute TechnicalGuide
Cheers,
Erich
|
|
From: Matthias T. <mt...@we...> - 2011-06-19 14:22:02
|
Andrew, > I haven't bought any hardware, yet. So any suggestions would be welcome. The arduino mega 128 is fine. Matthias |
|
From: pito <pi...@vo...> - 2011-06-19 13:16:23
|
Andrew - may recommendation to you is atmega1284p: dil40 or smd, 128kB flash, 4kB eeprom, 16kB ram. No issues with amforth. P. ----- PŮVODNÍ ZPRÁVA ----- Od: "Andrew Holt" <and...@4a...> Komu: "Everything around amforth" <amf...@li...> Předmět: Re: [Amforth] newby question mega 2560 Datum: 19.6.2011 - 15:08:51 > Hi, > > I haven't bought any hardware, yet. So any > suggestions would be welcome. > > The Arduino boards look interesting because of the > 'standard' board size and availability of add-ons. > > Regards, > Andrew > > On 19 Jun 2011, at 12:21, Matthias Trute wrote: > > > Hi Andrew, > > > >> The list of arduino boards 'supported' > > > > a general remark: supported means: the code > > can be assembled and the controller > > produces a command prompt (at least sometimes > > and > > > for at least one release). If anything goes > > wrong, sorry. > > > >> include the Mega with the > >> ATMega 1280 part. My question is waht are the > >> differences between > >> >> the 1280 and 2560 ? > > > > The major difference is that the 256x devices > > use a 3byte > > > addressing schema for the flash. In contrast > > amforth uses > > > a 2byte address (remember: 16bit forth). > > > > Some time ago I adapted amforth to run on such a > > big > > > iron, but could not test it for a while. It > > should work > > > however.., You will have no advantage over a > > 128x > > > device: half of the flash memory cannot be used > > currently and there is a small speed penalty due > > to > > > higher overhead in the low level routines. > > > > In any case I'm very interested if you could > > test it > > > and report any success/failure. > > > > Matthias > > > > ------------------------------------------------------------------------------ > > > > > EditLive Enterprise is the world's most > > technically advanced content > > > authoring tool. Experience the power of Track > > Changes, Inline Image > > > Editing and ensure content is compliant with > > Accessibility Checking. > > > http://p.sf.net/sfu/ephox-dev2dev > > _______________________________________________ > > Amforth-devel mailing list > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > ============================= > Andrew Holt > > Email: and...@4a... > > De Omnibus Dubitandum > ============================= > > > > > ------------------------------------------------------------------------------ > > EditLive Enterprise is the world's most > technically advanced content > authoring tool. Experience the power of Track > Changes, Inline Image > Editing and ensure content is compliant with > Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > -- IHNED.cz je nový, přehlednější a rychlejší. Přesvědčte se na: www.ihned.cz |
|
From: Andrew H. <and...@4a...> - 2011-06-19 13:09:01
|
Hi, I haven't bought any hardware, yet. So any suggestions would be welcome. The Arduino boards look interesting because of the 'standard' board size and availability of add-ons. Regards, Andrew On 19 Jun 2011, at 12:21, Matthias Trute wrote: > Hi Andrew, > >> The list of arduino boards 'supported' > > a general remark: supported means: the code > can be assembled and the controller > produces a command prompt (at least sometimes and > for at least one release). If anything goes > wrong, sorry. > >> include the Mega with the >> ATMega 1280 part. My question is waht are the differences between >> the 1280 and 2560 ? > > The major difference is that the 256x devices use a 3byte > addressing schema for the flash. In contrast amforth uses > a 2byte address (remember: 16bit forth). > > Some time ago I adapted amforth to run on such a big > iron, but could not test it for a while. It should work > however.., You will have no advantage over a 128x > device: half of the flash memory cannot be used > currently and there is a small speed penalty due to > higher overhead in the low level routines. > > In any case I'm very interested if you could test it > and report any success/failure. > > Matthias > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ============================= Andrew Holt Email: and...@4a... De Omnibus Dubitandum ============================= |
|
From: Matthias T. <mt...@we...> - 2011-06-19 11:22:03
|
Hi Andrew, > The list of arduino boards 'supported' a general remark: supported means: the code can be assembled and the controller produces a command prompt (at least sometimes and for at least one release). If anything goes wrong, sorry. > include the Mega with the > ATMega 1280 part. My question is waht are the differences between > the 1280 and 2560 ? The major difference is that the 256x devices use a 3byte addressing schema for the flash. In contrast amforth uses a 2byte address (remember: 16bit forth). Some time ago I adapted amforth to run on such a big iron, but could not test it for a while. It should work however.., You will have no advantage over a 128x device: half of the flash memory cannot be used currently and there is a small speed penalty due to higher overhead in the low level routines. In any case I'm very interested if you could test it and report any success/failure. Matthias |
|
From: Andrew H. <and...@4a...> - 2011-06-19 09:42:04
|
Hi, I am new to Arduino and amforth (but not forth in general) The list of arduino boards 'supported' include the Mega with the ATMega 1280 part. My question is waht are the differences between the 1280 and 2560 ? is it simply that the one has more flash than the other ? and the amforth will work fine on the 2560 part ? Thanks, Andrew ============================= Andrew Holt Email: and...@4a... De Omnibus Dubitandum ============================= |
|
From: Erich W. <ew....@na...> - 2011-06-16 16:55:39
|
Hello, On 06/16/2011 02:49 PM, pao...@fa... wrote: > Hi guys, > I’m trying to compile a system for an ATMEGA16 board. <snip> > atmega16.asm(26): warning: Use of undefined or forward referenced symbol 'TXEN0' in .equ/.set > atmega16.asm(29): warning: Use of undefined or forward referenced symbol 'TXEN0' in .equ/.set > atmega16.asm(34): warning: Use of undefined or forward referenced symbol 'UCSZ00' in .equ/.set > ../../core\drivers/usart_0.asm(1): warning: Use of undefined or forward referenced symbol 'UBRR0L' in .equ/.set > ../../core\drivers/usart_0.asm(2): warning: Use of undefined or forward referenced symbol 'UBRR0H' in .equ/.set > ../../core\drivers/usart_0.asm(3): warning: Use of undefined or forward referenced symbol 'UCSR0C' in .equ/.set > ../../core\drivers/usart_0.asm(4): warning: Use of undefined or forward referenced symbol 'UCSR0B' in .equ/.set > ../../core\drivers/usart_0.asm(5): warning: Use of undefined or forward referenced symbol 'UCSR0A' in .equ/.set > ../../core\drivers/usart_0.asm(11): warning: Use of undefined or forward referenced symbol 'UDRIE0' in .equ/.set > ../../core\drivers/usart_0.asm(11): error: Invalid redefinition of 'UDRIE' > ../../core\drivers/usart_0.asm(12): warning: Use of undefined or forward referenced symbol 'RXC0' in .equ/.set > ../../core\drivers/usart_0.asm(13): warning: Use of undefined or forward referenced symbol 'UDRE0' in .equ/.set This looks familiar ... Make sure that the controller type is referenced corrctly in the makefile: MCU=atmega16 yes in the makefile, not in template.asm. The atmega-16 may need a few more lines in template.asm: 1. after the baud rate add the 5 ".equ ..." lines ; initial baud rate of terminal .equ BAUD = 115200 ; additional .equs for "old fashioned" mcu with usart, not usart0 .equ TXEN0 = TXEN .equ RXEN0 = RXEN .equ RXCIE0 = RXCIE .equ UCSZ00 = UCSZ0 .equ TXCIE0 = TXCIE 2. .include "drivers/usart.asm" -----------------------^^ remove the _0 here. This works for me on atmega-32. Good luck, Erich |
|
From: Matthias T. <mt...@we...> - 2011-06-16 13:46:45
|
Hi Paolo, > Hi guys, > Iâm trying to compile a system for an ATMEGA16 board. > It gives errors and Iâm not able to go forth. Let me know if the page http://amforth.sourceforge.net/recipes/usart-settings.html answers your question with the error messages. Your seconds problem that wine is not needed in the makefile under windows (which I susepct you're using) is too obvious ;=) Matthias |
|
From: <pao...@fa...> - 2011-06-16 12:49:39
|
Hi guys, I’m trying to compile a system for an ATMEGA16 board. It gives errors and I’m not able to go forth. I followed the procedure suggested in official docs: copy the template folder in apps to a new folder “atmega16” and then modify makefile and template.asm. Attached you’ll find my makefile and my modified template “atmega16.asm”. In the makefile, the line: AVRASM=wine $(DIR_ATMEL)/avrasm2.exe -I $(DIR_ATMEL)/Appnotes2 Produces the error: make (e=2): file not found. make: *** [atmega16.hex] Error 2 instead the line: AVRASM=$(DIR_ATMEL)/avrasm2.exe -I $(DIR_ATMEL)/Appnotes2 (without wine) launches avrasm2 (AVR Studio 4.18 SP3) that gives 1 error and 11 warnings. Here the listing of errors: atmega16.asm(26): warning: Use of undefined or forward referenced symbol 'TXEN0' in .equ/.set atmega16.asm(29): warning: Use of undefined or forward referenced symbol 'TXEN0' in .equ/.set atmega16.asm(34): warning: Use of undefined or forward referenced symbol 'UCSZ00' in .equ/.set ../../core\drivers/usart_0.asm(1): warning: Use of undefined or forward referenced symbol 'UBRR0L' in .equ/.set ../../core\drivers/usart_0.asm(2): warning: Use of undefined or forward referenced symbol 'UBRR0H' in .equ/.set ../../core\drivers/usart_0.asm(3): warning: Use of undefined or forward referenced symbol 'UCSR0C' in .equ/.set ../../core\drivers/usart_0.asm(4): warning: Use of undefined or forward referenced symbol 'UCSR0B' in .equ/.set ../../core\drivers/usart_0.asm(5): warning: Use of undefined or forward referenced symbol 'UCSR0A' in .equ/.set ../../core\drivers/usart_0.asm(11): warning: Use of undefined or forward referenced symbol 'UDRIE0' in .equ/.set ../../core\drivers/usart_0.asm(11): error: Invalid redefinition of 'UDRIE' ../../core\drivers/usart_0.asm(12): warning: Use of undefined or forward referenced symbol 'RXC0' in .equ/.set ../../core\drivers/usart_0.asm(13): warning: Use of undefined or forward referenced symbol 'UDRE0' in .equ/.set Assembly failed, 1 errors, 11 warnings make: *** [atmega16.hex] Error 1 I think you can reproduce yourself the error. Please help me. Thank you. |
|
From: Marcin C. <sa...@sa...> - 2011-06-10 20:08:43
|
>> Matthias Trute <mt...@we...> wrote: > Hi Marcin, > >> When compiling r1076 with avra: >> >> [exec] /usr/home/saper/sw/amforth/trunk/core/words/usart-rx-isr.asm(12) : Error : Found no label/variable/constant named XT_RXQ > ..... >> >> Didn't have time to look deeper into this, but maybe some include order >> is a problem. > > Erichs analysis direct to the "right" solution (bug fix in avra, since > the atmel assembler does not have any problem). For now I changed > the code in usart-rx-isr.asm to be similiar to the poll variant. > R1081 should work. [...] Thanks everyone, bugfixes are now committed to avra git master, so avra should assemble amforth without problems. .BYTE problem has also been fixed. //Marcin |
|
From: Matthias T. <mt...@we...> - 2011-06-10 18:49:56
|
hi, > it seems there is a potential issue when running place-rec more > times (e.g. you are unmarkering and loading again a library with > "float-rec place-rec"). place-rec does not check for duplicates. Its generally a good idea to not blindly activate recognizers during tests. > The list of recognisers grows and the items > then maybe do not point to recognisers which are valid. > A "rec-clean" word would be a nice to have option..P. probably even better: marker should be extended to deal with recognizers as well. Matthias |
|
From: pito <pi...@vo...> - 2011-06-10 18:34:43
|
Hi, it seems there is a potential issue when running place-rec more times (e.g. you are unmarkering and loading again a library with "float-rec place-rec"). The list of recognisers grows and the items then maybe do not point to recognisers which are valid. A "rec-clean" word would be a nice to have option..P. -- IHNED.cz je nový, přehlednější a rychlejší. Přesvědčte se na: www.ihned.cz |
|
From: Marcin C. <sa...@sa...> - 2011-06-10 18:32:48
|
>> Erich Waelde <ew....@na...> wrote: > Hi Marcin, > > On 06/10/2011 10:59 AM, Marcin Cieslak wrote: >> When compiling r1076 with avra: >> >> [exec] /usr/home/saper/sw/amforth/trunk/core/words/usart-rx-isr.asm(12) :\ > > Error : Found no label/variable/constant named XT_RXQ > > confirmed with r1077. > > There is no error, when using AvrAssembler2. > > XT_RXQ is a "variable", which is set to either XT_RXQ_ISR or XT_RXQ_POLL. > The setting takes place in trunk/core/dict_usart.inc and depends > on template.asm: > .set WANT_ISR_RX = 1 ; interrupt driven receive > > Interestingly, when setting WANT_ISR_RX = 0, > the error goes away, and XT_RXQ is set correctly to XT_RXQ_POLL. > > So this looks like avra did somehow ignore setting > XT_RXQ to XT_RXQ_ISR in the first case, from what I can see. Thank you, this helps a lot. I will try to fix this problem in avra. //Marcin |
|
From: Matthias T. <mt...@we...> - 2011-06-10 17:58:48
|
Hi Marcin, > When compiling r1076 with avra: > > [exec] /usr/home/saper/sw/amforth/trunk/core/words/usart-rx-isr.asm(12) : Error : Found no label/variable/constant named XT_RXQ ..... > > Didn't have time to look deeper into this, but maybe some include order > is a problem. Erichs analysis direct to the "right" solution (bug fix in avra, since the atmel assembler does not have any problem). For now I changed the code in usart-rx-isr.asm to be similiar to the poll variant. R1081 should work. The commits I've done in the meantime should not do any (more) harm. But they are huge and fundamental however, see homepage for details. Matthias |
|
From: Erich W. <ew....@na...> - 2011-06-10 14:10:08
|
Hi Marcin, On 06/10/2011 10:59 AM, Marcin Cieslak wrote: > When compiling r1076 with avra: > > [exec] /usr/home/saper/sw/amforth/trunk/core/words/usart-rx-isr.asm(12) :\ > Error : Found no label/variable/constant named XT_RXQ confirmed with r1077. There is no error, when using AvrAssembler2. XT_RXQ is a "variable", which is set to either XT_RXQ_ISR or XT_RXQ_POLL. The setting takes place in trunk/core/dict_usart.inc and depends on template.asm: .set WANT_ISR_RX = 1 ; interrupt driven receive Interestingly, when setting WANT_ISR_RX = 0, the error goes away, and XT_RXQ is set correctly to XT_RXQ_POLL. So this looks like avra did somehow ignore setting XT_RXQ to XT_RXQ_ISR in the first case, from what I can see. Hope this helps. Erich |
|
From: Marcin C. <sa...@sa...> - 2011-06-10 08:59:39
|
When compiling r1076 with avra: [exec] /usr/home/saper/sw/amforth/trunk/core/words/usart-rx-isr.asm(12) : Error : Found no label/variable/constant named XT_RXQ My duemilanove.asm (pretty much unchanged since 4.0): .include "macros.asm" .include "device.asm" .set WANT_AD_CONVERTER = 1 .set WANT_ANALOG_COMPARATOR = 1 .set WANT_CPU = 1 .set WANT_EEPROM = 1 .set WANT_EXTERNAL_INTERRUPT = 1 .set WANT_PORTB = 1 .set WANT_PORTC = 1 .set WANT_PORTD = 1 .set WANT_SPI = 1 .set WANT_TIMER_COUNTER_0 = 1 .set WANT_TIMER_COUNTER_1 = 1 .set WANT_TIMER_COUNTER_2 = 1 .set WANT_TWI = 1 .set WANT_USART0 = 1 .set WANT_WATCHDOG = 1 .equ TIBSIZE = $64 ; 80 characters is one line... .equ APPUSERSIZE = 10 ; size of application user area ; cpu clock in hertz .equ F_CPU = 16000000 ; baud rate of terminal .include "drivers/usart_0.asm" .equ BAUD = 19200 .equ USART_B_VALUE = (1<<TXEN0) | (1<<RXEN0) | (1<<RXCIE0) .equ USART_C_VALUE = (1<<UCSZ01) | ( 1<<UCSZ00) .set here = ramstart ; start address of HERE, grows upward .set rstackstart = RAMEND .set stackstart = RAMEND - 80 .set amforth_interpreter = max_dict_addr .set NUMWORDLISTS = 8 .include "amforth.asm" Didn't have time to look deeper into this, but maybe some include order is a problem. //Marcin |
|
From: Matthias T. <mt...@we...> - 2011-06-08 19:22:07
|
Hi Marcin, > Hello, > > I tried to compile amforth trunk with avra and I get: > > [exec] /usr/home/saper/sw/amforth/trunk/core/dict_usart.inc(7) : Error : Found no label/variable/constant named XT_USART_INIT_RX_ISR > [exec] /usr/home/saper/sw/amforth/trunk/core/dict_usart.inc(7) : Error : XT_USART_INIT_RX have already been defined as a label > > Indeed, XT_USART_INIT_RX_ISR does not seem to be defined anywhere > in the sourcecode. Is it only me? Not really, Fix is applied. Sorry. You may call it repository management regresseion... Matthias |
|
From: Erich W. <ew....@na...> - 2011-06-08 19:16:01
|
Hi, On 06/08/2011 09:10 PM, Marcin Cieslak wrote: > Hello, > > I tried to compile amforth trunk with avra and I get: > > [exec] /usr/home/saper/sw/amforth/trunk/core/dict_usart.inc(7) : Error : Found no label/variable/constant named XT_USART_INIT_RX_ISR > [exec] /usr/home/saper/sw/amforth/trunk/core/dict_usart.inc(7) : Error : XT_USART_INIT_RX have already been defined as a label > > Indeed, XT_USART_INIT_RX_ISR does not seem to be defined anywhere > in the sourcecode. Is it only me? Hm, the lines look like this one: .set XT_USART_INIT_RX = XT_USART_INIT_RX_ISR so maybe the right hand side is not defined??? Just wild guessing. Erich |
|
From: Marcin C. <sa...@sa...> - 2011-06-08 19:10:43
|
Hello,
I tried to compile amforth trunk with avra and I get:
[exec] /usr/home/saper/sw/amforth/trunk/core/dict_usart.inc(7) : Error : Found no label/variable/constant named XT_USART_INIT_RX_ISR
[exec] /usr/home/saper/sw/amforth/trunk/core/dict_usart.inc(7) : Error : XT_USART_INIT_RX have already been defined as a label
Indeed, XT_USART_INIT_RX_ISR does not seem to be defined anywhere
in the sourcecode. Is it only me?
//Marcin
|
|
From: Elliott C. <ec...@te...> - 2011-06-05 19:26:50
|
On 06/05/2011 01:45 PM, Erich Waelde wrote: > >> Thanks, Neal! Nice if there were one for the Uno. ;( >> > The only difference in handling between the duemilanove > and the uno is the name of the serial device, on Linux > at least: > > /dev/ttyUSB<number> (duemilanove) > /dev/ttyACM<number> (uno) > > as I have posted to the list before (21.March.2011) > > > Cheers, > Erich > Second thought: It would seem that that under Windows I can pretend that my Uno is a duemilanove, as the name of the serial device is not mentioned in duemilanove.asm. -- Elliott Chapin http://clients.teksavvy.com/~echapin |
8 messages has been excluded from this view by a project administrator.
