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: David K. <dvd...@po...> - 2020-12-10 09:29:58
|
>>>>> "Tristan" == Tristan Williams <ho...@tj...> writes: > Hello AmForthers, With the season's TV not to everybody's taste and > ownership of the remote control contested, having an alternative > activity is a good idea. Over the decades there have been many good > Forth papers written, but finding approachable, self-contained ones is > not always easy (for me at least). Whilst it has been mentioned on the > mailing list before, here is one of my favourites > Finite State Machines in Forth (J.V. Noble 1995) > http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html > Do you have any papers/articles to share? Lots of papers here: https://informatics.tuwien.ac.at/people/anton-ertl#publications E.g. https://publik.tuwien.ac.at/files/publik_277357.pdf https://publik.tuwien.ac.at/files/publik_256658.pdf https://publik.tuwien.ac.at/files/PubDat_247890.pdf ... Maybe not properly self-contained, though you could try to traverse the graph of references given in each paper :) cheers, David |
From: Tristan W. <ho...@tj...> - 2020-12-10 09:03:06
|
Hello AmForthers, With the season's TV not to everybody's taste and ownership of the remote control contested, having an alternative activity is a good idea. Over the decades there have been many good Forth papers written, but finding approachable, self-contained ones is not always easy (for me at least). Whilst it has been mentioned on the mailing list before, here is one of my favourites Finite State Machines in Forth (J.V. Noble 1995) http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html Do you have any papers/articles to share? Best wishes, Tristan https://sourceforge.net/p/amforth/mailman/search/?q=fsm common/lib/fsm.frt examples/fsm.frt |
From: Tristan W. <ho...@tj...> - 2020-12-05 17:38:17
|
A very minor item. avr8 has bm-set, bm-clear and bm-toggle as assembler words but does not appear to have bm-test. This is not a big thing as it is easily defined in forth as : bm-test ( c a -- c ) c@ and ; However, I've made myself an assembler version so I have a matching set. It seems only very marginally faster than the forth one above. ; ( bitmask byte-addr -- byte ) ; MCU ; return (byte at addr) AND bitmask VE_BM_TEST: .dw $ff07 .db "bm-test" .dw VE_HEAD .set VE_HEAD = VE_BM_TEST XT_BM_TEST: .dw PFA_BM_TEST PFA_BM_TEST: movw zl, tosl loadtos ld temp0, Z and tosl, temp0 clr tosh ; zero high byte of TOS jmp_ DO_NEXT msp430 is missing bm-toggle and arm, risc-v have none of them. It also seemed a reasonable opportunity to try out tester-amforth.frt I could well be using it incorrectly. Corrections welcomed. \ #include tester-amforth.frt variable v $ffff v ! \ some passes and fails to see what it looks like \ should pass t{ $ff v bm-test -> $ff }t \ should pass t{ $1 v bm-test -> $1 }t \ should pass t{ $0 v bm-test -> $0 }t \ should pass t{ $ffff v bm-test -> $ff }t \ should fail t{ $ffff v bm-test -> $ffff }t \ should pass t{ $ff00 v bm-test -> $00 }t \ should fail t{ $ff00 v bm-test -> $ff00 }t \ Not sure if this is an approved way of using t{ ... }t \ should pass for all values : test.1 #256 0 ?do i v ! #256 0 ?do t{ i v bm-test -> j $ff and i and }t loop loop ; \ intentionally broken word : bm-broken ( mask a -- n ) 2dup c@ dup 23 = rot rot = and if drop drop 0 else bm-test then ; \ should fail only once when i=j=23 : test.2 #256 0 ?do i v ! #256 0 ?do j 23 = if i . cr then t{ i v bm-broken -> j $ff and i and }t loop loop ; Best wishes, Tristan |
From: David K. <dvd...@po...> - 2020-11-30 12:36:46
|
Hi, thanks to all of you for your helpful replies. Was a little swamped with work and didn't find time to revisit the amForth-on-Pong problem... But with your comments so far, I think I'll give up on that idea. Luckily I now have a half-assembled Uzebox with some first vital signs (including a working grayscale video output), maybe this platform will prove to be more tolerant WRT my amForth ambitions (but maybe not before New Year). >>>>> "Erich" == Erich Wälde <ew....@na...> writes: [..] > Arduboy features a atmega32u4. AmForth does not have support for the > USB interface, should that be important. Good to know, but it looks lika arduboy does not use the physical UART pins [3], so maybe amForth could "just work" using those (at least if you assemble your arduboy yourself anyway). > uzebox features an atmega644 controller. Now that I use routinely and > it has plenty of space. Yes, time invested in getting amForth onto Uzebox will be better spent than trying to make the Atmega-8 port work. Partitioning the memory and adding some inter-call code may even provide a simple way to integrate "official" C/assembler board-support code (i.e. video, sound & controller interface) with amForth. Something like this [1-2] comes to my mind. Uzebox does not have a serial connector by default, but the corresponding pins are unused, so no obstacles there. > Dear David, you picked a new time sink, it seems. :-) Unfortunately, a new time sink picked me :) At least this is making Playstations and Nintendo Switches look very boring in comparison :) cheers, David [1] http://www.complang.tuwien.ac.at/anton/euroforth/ef10/papers/ertl.pdf [2] https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2010-04.pdf ; see definition of "call1" [3] https://aws1.discourse-cdn.com/standard14/uploads/arduboy/original/2X/0/0f375e1fd71a1f596d9d182cec7916bceacc50fd.png |
From: Erich W. <ew....@na...> - 2020-11-25 18:58:22
|
Hallo David, long time no see :) well, unfortunately ... I have tried to assemble amforth-6.9 for atmega8. The uart thing is quite simple to fix, as has been pointed out: in template.asm: -.include "drivers/usart_0.asm" +.include "drivers/usart.asm" And you made some progress on the "Overlap in .cseg". cont. below ... David Kuehling writes: > Hi, > > I've been trying to get AmForth onto this Atmega 8 based platform: > > https://www.elektronik-labor.de/Lernpakete/Pingong.html > https://www.elektronik-labor.de/Elo/ELO.html > > Which is sold cheaply as a toy: > > https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843 > > Already soldered the ISP connector and a serial TTL cable. However, > AmForth (v6.9) does not seem to compile for Atmega8 in its current > version. Copying the template directory and editing makefile to say > "MCU=atmega8", I'm getting a lot of compiler errors that indicate an > overflow of the RWW dictionary space: > > ../../avr8\amforth-interpreter.asm(4): error: Overlap in .cseg: addr=0xc00 conflicts with 0x7a:0xc58 > ../../avr8\amforth-interpreter.asm(5): error: Overlap in .cseg: addr=0xc01 conflicts with 0x7a:0xc58 > [..] > > If I randomly comment out words in avr/appl_2k.inc, I get a little > further. However, then compilation errs out in the UART driver code and > complains about stuff in macros.asm: > > ../../avr8\drivers/usart_0.asm(1): error: Undefined symbol: UBRR0L > ../../avr8\drivers/usart_0.asm(2): error: Undefined symbol: UBRR0H > ../../avr8\drivers/usart_0.asm(3): error: Undefined symbol: UCSR0C > ../../avr8\drivers/usart_0.asm(4): error: Undefined symbol: UCSR0B > ../../avr8\drivers/usart_0.asm(5): error: Undefined symbol: UCSR0A > ../../avr8\drivers/usart_0.asm(12): error: Undefined symbol: RXC0 > ../../avr8\drivers/usart_0.asm(13): error: Undefined symbol: UDRE0 > ../../avr8\drivers/usart_0.asm(14): error: Undefined symbol: TXEN0 > ../../avr8\drivers/usart_0.asm(15): error: Undefined symbol: RXEN0 > ../../avr8\drivers/usart_0.asm(16): error: Undefined symbol: RXCIE0 > ../../avr8\drivers/usart_0.asm(17): error: Undefined symbol: UDRIE0 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > > And this is even before I try to resolve all the problems arising from > the words that I commented out. > > Maybe the Atmega8-specific code has been bit-rotting without being used > for too long already? What do you think are my chances to make this > work again? Any ideas what's wrong about the Uart drivers and how to > strip down AmForth to fit into 8 kB of flash? Or has AmForth just > gotten too old and fat over the years to render this undertaking > unachievable? Bitrot is maybe the wrong word for this. AmForth has grown in features and thus in size. 8 kiB flash is imho too small. It was too small for a long time already, because you really need a few kB free space for your own programm, right? Maybe starting with AmForth-4.x is more successful? You may be able to just get it to work, but then what? I would like to see, what needs to be stripped out until it fits. But I guess it is really not worth the effort. Just for the sake of the argument I tried AmForth-4.0 (release 2010-07-01). It does not assemble, even though there is only 1 overlap conflict. Sigh. The atmega8 has worked, but I have no idea which release made it fail the size constraints. Maybe I should place a more prominent warning on the webpage. Currently we have this: webpage> AmForth for the AVR8 needs 8 to 12 KB Flash memory, 80 webpage> bytes EEPROM, and 200 bytes RAM for the core system. > (I did some experiments with an Arduino Uno clone first, and had no > problem compiling and setting up AmForth on it.) > > Maybe the Arduboy [1] would be better suited to AmForth, but it's also > more costly and complex to program. I'm also eyeing the uzebox [2], but > getting its video driver into AmForth would be a daunting > endevour. Arduboy features a atmega32u4. AmForth does not have support for the USB interface, should that be important. uzebox features an atmega644 controller. Now that I use routinely and it has plenty of space. Dear David, you picked a new time sink, it seems. :-) Cheers, Erich > > cheers, > > David > > [1] https://www.reichelt.de/arduboy-arduino-kompatibles-miniaturspielsystem-ard-arduboy-p254388.html?&trstct=pos_0&nbc=1 > [2] http://belogic.com/uzebox/index.asp -- May the Forth be with you ... |
From: Tristan W. <ho...@tj...> - 2020-11-25 06:41:42
|
Hello David, The ping-pong[1] looks interesting! You are correct the ATMega8 does present some challenges for AmForth 6.9 This issue came up on the mailing list earlier this year. > Any ideas what's wrong about the Uart drivers https://sourceforge.net/p/amforth/mailman/message/37085124/ > and how to strip down AmForth to fit into 8 kB of flash? Or has > AmForth just gotten too old and fat over the years to render this > undertaking unachievable? https://sourceforge.net/p/amforth/mailman/message/37085843/ I think also that the ATMega8 may be missing some assembly instructions that are now relied upon by the current build. Whether it is technically possible to put AmForth 6.9 on a diet such that it would fit in 8k flash I don't know, but faced with the task, I would try to do it on an ATMega328p first. >From a quick look at the ping-pong manual[3] I think it uses the internal RC oscillator as the system clock as I couldn't see a crystal or resonator. Sadly, the manual does not show a nicely socket-ed DIP-28 ATMega8. Otherwise replacing it physically with an ATMega328[2] might have been an option to consider. Best wishes, Tristan [1] https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843 [2] https://www.avrfreaks.net/forum/difference-between-atmega8-and-atmega328 [3] https://files2.elv.com/public/14/1448/144843/Internet/144843_manual.pdf On 23Nov20 23:17, David Kuehling wrote: > Hi, > > I've been trying to get AmForth onto this Atmega 8 based platform: > > https://www.elektronik-labor.de/Lernpakete/Pingong.html > https://www.elektronik-labor.de/Elo/ELO.html > > Which is sold cheaply as a toy: > > https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843 > > Already soldered the ISP connector and a serial TTL cable. However, > AmForth (v6.9) does not seem to compile for Atmega8 in its current > version. Copying the template directory and editing makefile to say > "MCU=atmega8", I'm getting a lot of compiler errors that indicate an > overflow of the RWW dictionary space: > > ../../avr8\amforth-interpreter.asm(4): error: Overlap in .cseg: addr=0xc00 conflicts with 0x7a:0xc58 > ../../avr8\amforth-interpreter.asm(5): error: Overlap in .cseg: addr=0xc01 conflicts with 0x7a:0xc58 > [..] > > If I randomly comment out words in avr/appl_2k.inc, I get a little > further. However, then compilation errs out in the UART driver code and > complains about stuff in macros.asm: > > ../../avr8\drivers/usart_0.asm(1): error: Undefined symbol: UBRR0L > ../../avr8\drivers/usart_0.asm(2): error: Undefined symbol: UBRR0H > ../../avr8\drivers/usart_0.asm(3): error: Undefined symbol: UCSR0C > ../../avr8\drivers/usart_0.asm(4): error: Undefined symbol: UCSR0B > ../../avr8\drivers/usart_0.asm(5): error: Undefined symbol: UCSR0A > ../../avr8\drivers/usart_0.asm(12): error: Undefined symbol: RXC0 > ../../avr8\drivers/usart_0.asm(13): error: Undefined symbol: UDRE0 > ../../avr8\drivers/usart_0.asm(14): error: Undefined symbol: TXEN0 > ../../avr8\drivers/usart_0.asm(15): error: Undefined symbol: RXEN0 > ../../avr8\drivers/usart_0.asm(16): error: Undefined symbol: RXCIE0 > ../../avr8\drivers/usart_0.asm(17): error: Undefined symbol: UDRIE0 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > > And this is even before I try to resolve all the problems arising from > the words that I commented out. > > Maybe the Atmega8-specific code has been bit-rotting without being used > for too long already? What do you think are my chances to make this > work again? Any ideas what's wrong about the Uart drivers and how to > strip down AmForth to fit into 8 kB of flash? Or has AmForth just > gotten too old and fat over the years to render this undertaking > unachievable? > > (I did some experiments with an Arduino Uno clone first, and had no > problem compiling and setting up AmForth on it.) > > Maybe the Arduboy [1] would be better suited to AmForth, but it's also > more costly and complex to program. I'm also eyeing the uzebox [2], but > getting its video driver into AmForth would be a daunting endevour. > > cheers, > > David > > [1] https://www.reichelt.de/arduboy-arduino-kompatibles-miniaturspielsystem-ard-arduboy-p254388.html?&trstct=pos_0&nbc=1 > [2] http://belogic.com/uzebox/index.asp > -- > GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg > Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: tur b. <mai...@gm...> - 2020-11-25 00:43:37
|
David looks like preamble.Inc is not finding device.asm in devices/atmega8 could be to many folders in path. I have used avrstudio4 and enter the avr8/devices/atmega8 in its additional path setting, you may need to look up the serial the chip has and set that in the config file On Mon, 23 Nov 2020 22:18 David Kuehling, <dvd...@po...> wrote: > Hi, > > I've been trying to get AmForth onto this Atmega 8 based platform: > > https://www.elektronik-labor.de/Lernpakete/Pingong.html > https://www.elektronik-labor.de/Elo/ELO.html > > Which is sold cheaply as a toy: > > > https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843 > > Already soldered the ISP connector and a serial TTL cable. However, > AmForth (v6.9) does not seem to compile for Atmega8 in its current > version. Copying the template directory and editing makefile to say > "MCU=atmega8", I'm getting a lot of compiler errors that indicate an > overflow of the RWW dictionary space: > > ../../avr8\amforth-interpreter.asm(4): error: Overlap in .cseg: addr=0xc00 > conflicts with 0x7a:0xc58 > ../../avr8\amforth-interpreter.asm(5): error: Overlap in .cseg: addr=0xc01 > conflicts with 0x7a:0xc58 > [..] > > If I randomly comment out words in avr/appl_2k.inc, I get a little > further. However, then compilation errs out in the UART driver code and > complains about stuff in macros.asm: > > ../../avr8\drivers/usart_0.asm(1): error: Undefined symbol: UBRR0L > ../../avr8\drivers/usart_0.asm(2): error: Undefined symbol: UBRR0H > ../../avr8\drivers/usart_0.asm(3): error: Undefined symbol: UCSR0C > ../../avr8\drivers/usart_0.asm(4): error: Undefined symbol: UCSR0B > ../../avr8\drivers/usart_0.asm(5): error: Undefined symbol: UCSR0A > ../../avr8\drivers/usart_0.asm(12): error: Undefined symbol: RXC0 > ../../avr8\drivers/usart_0.asm(13): error: Undefined symbol: UDRE0 > ../../avr8\drivers/usart_0.asm(14): error: Undefined symbol: TXEN0 > ../../avr8\drivers/usart_0.asm(15): error: Undefined symbol: RXEN0 > ../../avr8\drivers/usart_0.asm(16): error: Undefined symbol: RXCIE0 > ../../avr8\drivers/usart_0.asm(17): error: Undefined symbol: UDRIE0 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 > > And this is even before I try to resolve all the problems arising from > the words that I commented out. > > Maybe the Atmega8-specific code has been bit-rotting without being used > for too long already? What do you think are my chances to make this > work again? Any ideas what's wrong about the Uart drivers and how to > strip down AmForth to fit into 8 kB of flash? Or has AmForth just > gotten too old and fat over the years to render this undertaking > unachievable? > > (I did some experiments with an Arduino Uno clone first, and had no > problem compiling and setting up AmForth on it.) > > Maybe the Arduboy [1] would be better suited to AmForth, but it's also > more costly and complex to program. I'm also eyeing the uzebox [2], but > getting its video driver into AmForth would be a daunting endevour. > > cheers, > > David > > [1] > https://www.reichelt.de/arduboy-arduino-kompatibles-miniaturspielsystem-ard-arduboy-p254388.html?&trstct=pos_0&nbc=1 > [2] http://belogic.com/uzebox/index.asp > -- > GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg > Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: David K. <dvd...@po...> - 2020-11-23 22:18:10
|
Hi, I've been trying to get AmForth onto this Atmega 8 based platform: https://www.elektronik-labor.de/Lernpakete/Pingong.html https://www.elektronik-labor.de/Elo/ELO.html Which is sold cheaply as a toy: https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843 Already soldered the ISP connector and a serial TTL cable. However, AmForth (v6.9) does not seem to compile for Atmega8 in its current version. Copying the template directory and editing makefile to say "MCU=atmega8", I'm getting a lot of compiler errors that indicate an overflow of the RWW dictionary space: ../../avr8\amforth-interpreter.asm(4): error: Overlap in .cseg: addr=0xc00 conflicts with 0x7a:0xc58 ../../avr8\amforth-interpreter.asm(5): error: Overlap in .cseg: addr=0xc01 conflicts with 0x7a:0xc58 [..] If I randomly comment out words in avr/appl_2k.inc, I get a little further. However, then compilation errs out in the UART driver code and complains about stuff in macros.asm: ../../avr8\drivers/usart_0.asm(1): error: Undefined symbol: UBRR0L ../../avr8\drivers/usart_0.asm(2): error: Undefined symbol: UBRR0H ../../avr8\drivers/usart_0.asm(3): error: Undefined symbol: UCSR0C ../../avr8\drivers/usart_0.asm(4): error: Undefined symbol: UCSR0B ../../avr8\drivers/usart_0.asm(5): error: Undefined symbol: UCSR0A ../../avr8\drivers/usart_0.asm(12): error: Undefined symbol: RXC0 ../../avr8\drivers/usart_0.asm(13): error: Undefined symbol: UDRE0 ../../avr8\drivers/usart_0.asm(14): error: Undefined symbol: TXEN0 ../../avr8\drivers/usart_0.asm(15): error: Undefined symbol: RXEN0 ../../avr8\drivers/usart_0.asm(16): error: Undefined symbol: RXCIE0 ../../avr8\drivers/usart_0.asm(17): error: Undefined symbol: UDRIE0 ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8 And this is even before I try to resolve all the problems arising from the words that I commented out. Maybe the Atmega8-specific code has been bit-rotting without being used for too long already? What do you think are my chances to make this work again? Any ideas what's wrong about the Uart drivers and how to strip down AmForth to fit into 8 kB of flash? Or has AmForth just gotten too old and fat over the years to render this undertaking unachievable? (I did some experiments with an Arduino Uno clone first, and had no problem compiling and setting up AmForth on it.) Maybe the Arduboy [1] would be better suited to AmForth, but it's also more costly and complex to program. I'm also eyeing the uzebox [2], but getting its video driver into AmForth would be a daunting endevour. cheers, David [1] https://www.reichelt.de/arduboy-arduino-kompatibles-miniaturspielsystem-ard-arduboy-p254388.html?&trstct=pos_0&nbc=1 [2] http://belogic.com/uzebox/index.asp -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F |
From: Erich W. <ew....@na...> - 2020-11-23 20:47:11
|
Dear AmForthers, Monday evening doing a little AmForth related stuff, how is that? Full disclosure: I am using emacs/org-mode. So I created a habit for Monday. And boy those red colored bars saying "not done" become annoying quickly. So better do something :) Contemplating the Test Cases Thing > 2020-11-02 I wrote: > 3. Add testing scripts --- I have a set of scripts for that, but I > have not run this stuff yet. However, in my opinion adding a > working test suite is far more important at the moment, than > anything else. > > This includes preparing some hardware with 4 relevant target boards > in order to simplify the process. Turns out that the set of scripts isn't all that great. So: What would I like to achieve? There will be a ./test/ directory, which holds the test cases and the files to programm my available target hw for the tests. : cd test : make targets # shall produce firmware for target boards : make install $target # flash the particular target board : make test $target # calls the runner on a given list of test cases The result should be something like this: : make test $target : . loading tester on $target, ok. : . 0/12 test/common/test-A.frt, ok : . 1/19 test/common/test-B.frt, 1 error : 1 error in 21 tests The verbatim output goes to runner.log or something such. *configuration* - which target board do I want to use? - which programmer and its paramters do I have? - which details for the serial (or other?) connection? *terminology* - unit-under-test :: this is the function (asm of forth word) to be tested. : : unit-under-test ( stack -- effect ) : definition : ; These live in the directories arm, avr8, common, msp430, risc-v, shared ... these trees should remain unchanged imho. - test case :: this is a statement to load unit-under-test and its possible dependencies, plus a collection of "t{ ... }t" statements to exercise unit-under-test: : #include unit-under-test.fs : t{ stack function changed stack }t Other forms of test procedures should be possible as long as they produce output, which can be understood by the runner. There are dragons lurking here when it comes to #include or #require. - runner :: this is a script which can talk to a target board (via serial), feed a testcase file, collect the resulting output and extract the results - tester :: this is an implementation of the Hayes tester. It defines 't{' '}t' and a few more words. - firmware :: for every target board to be used, we require a well equipped AmForth firmware. I expect this firmware to be somewhat special and separate from the examples in the ./appl/ subdirectory. There are possible complications known as setup/teardown. Markers could possibly help. On the other hand, I have not yet exhausted the flash or RAM of a atmega-644a. *possible tree layout* : amforth/trunk : ... : +-- test/ : +-- Makefile \ top of magic : +-- M.programmer.mk \ make vars to specify my programmer : +-- M.connection.mk \ make vars to specify serial connection : +-- bin/ \ any tools : | +-- runner.pl : | : +-- tester/ \ place for tester words? optional? : | : +-- firmware/ : | +-- avr8-at644p/ : | | +-- Makefile : | | +-- dict_appl_core.inc : | | +-- dict_appl.inc \ includes dict_local.inc : | | +-- dict_local.inc \ all additional words to load in this context : | | +-- testfirmware.asm \ top level definition for target firmware : | | +-- words/ : | | +-- applturnkey.asm \ project specific : | | : | +-- $target-$controller/ : | | +-- Makefile : | | +-- ... : | ... : | : +-- cases/ : | +-- common/ \ testcases for all target boards : | | +-- stack-test.frt : | | ... : | | : | +-- avr8/ \ testcases for specific target boards : | | +-- ... : | ... : | : +-- logs/ \ place for logfiles? Assuming that Mr.Someone has installed the relevant tools, editing the M.*.mk files should be enough to - produce firmware for at least one target - install the firmware on said target - load and evaluate the available tests All of this in a few lines of shell commands. Does that sound like a plausible plan? Next step: create this structure for one target and a few test cases and see, how we fare. Cheers, Erich -- May the Forth be with you ... |
From: Erich W. <ew....@na...> - 2020-11-16 20:55:07
|
Hello Carsten, Carsten Strotmann writes: > please find attached two patches for the amForth website > source, ARM pages. thank you for the patches. I have committed them and updated the web site --- not without deleting it first, sigh. > My editor (Emacs) cleans the whitespace, if that is an issue, > I'll remove that and resend. Not a problem. Cheers, Erich > > Greetings > > Carsten > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: 0001-Adding-information-that-amForth-targets-32bit-ARM.patch > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: 0002-Fixed-a-typo.patch > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel -- May the Forth be with you ... |
From: Carsten S. <ca...@st...> - 2020-11-06 12:27:13
|
Hi Erich, please find attached two patches for the amForth website source, ARM pages. My editor (Emacs) cleans the whitespace, if that is an issue, I'll remove that and resend. Greetings Carsten -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Adding-information-that-amForth-targets-32bit-ARM.patch -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Fixed-a-typo.patch |
From: Carsten S. <ca...@st...> - 2020-11-04 13:33:58
|
Hi, On 3 Nov 2020, at 21:47, Ian Jefferson wrote: > Some good points here: > >> On Nov 3, 2020, at 4:33 AM, fr...@fr... wrote: >> >> - Gradual or "big bang" migration? >> Should SVN and GIT run in parallel for some time, or is >> it OK to have a single big bang migration? Big bang is >> a lot easier… >> > > Big Bang. We are too small and under staffed (current Army of Erich!) > to maintain stuff in parallel. Given the opportunity we can all grab > working copies before the transition. A good thought here Frank. > +1 >> - Do you want to completely ignore GitHub? >> GitHub is the go-to place for open source software. >> Google does heavy indexing there. If you want AmForth >> to reach a large community, then you have to publish >> there. However, it doesn't need to the the primary repo... > > Another wise comment Frank. There is something eventually even I > could maintain for the community! Keeping things as open to the main > stream opensource crowd is a good thought even if the day to day is > managed elsewhere and when. I use both sourcehut and GitHub, I prefer sourcehut but I agree that amForth should have a presence on Github as well. There are already various forks of amForth on Github, as well as amForth related code. Being on Github is important to be visible. And yes, an automated sync between sr.ht and GitHub could be possible. A repo on GitHub should be "official", e.g. the same people that run the main repo (Erich at the moment) should also have control there, even if someone from the community operates the repo and the sync. This prevents that the two repos will diverge later. Greetings Carsten |
From: Carsten S. <ca...@st...> - 2020-11-04 13:22:32
|
Hello Dieter, On 3 Nov 2020, at 20:07, di...@sc... wrote: > I gave it a try and started a svn2git conversion on my machine with > the command: > svn2git https://svn.code.sf.net/p/amforth/code --branches releases > This takes about 10 minutes, depending on host power and network > connection. > This converts the trunk to themaster branch and converts all the > releases tree to branches. > The result looks quite well to me. thank you. I've cloned your git repo and indeed it looks good to me (but I'm not a big expert on "git", but I see the different commits and diffs) Greetings Carsten |
From: Ian J. <ij...@sa...> - 2020-11-03 20:47:37
|
Some good points here: > On Nov 3, 2020, at 4:33 AM, fr...@fr... wrote: > > - Gradual or "big bang" migration? > Should SVN and GIT run in parallel for some time, or is > it OK to have a single big bang migration? Big bang is > a lot easier… > Big Bang. We are too small and under staffed (current Army of Erich!) to maintain stuff in parallel. Given the opportunity we can all grab working copies before the transition. A good thought here Frank. > - Do you want to completely ignore GitHub? > GitHub is the go-to place for open source software. > Google does heavy indexing there. If you want AmForth > to reach a large community, then you have to publish > there. However, it doesn't need to the the primary repo... Another wise comment Frank. There is something eventually even I could maintain for the community! Keeping things as open to the main stream opensource crowd is a good thought even if the day to day is managed elsewhere and when. Ian |
From: <di...@sc...> - 2020-11-03 20:02:54
|
Hi all, I think I introduced myself already, but that was years ago. I first played around with forth in the 80s, but never had a chance to use it properly for a real project. Maybe this changes now, because due to corona I am working part-time now.. On the svn2git topic: I gave it a try and started a svn2git conversion on my machine with the command: svn2git https://svn.code.sf.net/p/amforth/code --branches releases This takes about 10 minutes, depending on host power and network connection. This converts the trunk to themaster branch and converts all the releases tree to branches. The result looks quite well to me. I have uploaded it to a private server, you can have a look at: fo...@ho...:amforth.git The password is the name of this project in uppercase, a dot, and 0x7d6 in decimal. If you like, I could also upload it to gitlab or github. Kind regards, Dieter Am Di., Nov. 3, 2020 10:34 schrieb fr...@fr...: Hi! Point 5 is huge and needs to be broken into smaller steps. I would appreciate any response, and if you could include, which target you are using, all the better. We (http://www.project-open.com/ (http://www.project-open.com/)) are in the process of moving from CVS to GIT for the next ]project-open[ V5.1 release. The process is the same for SVN, the tool is actually called svn2git... We decided to host our repos on a private GitLab instance because: - GitLab allows us to setup permissions for "packages" (see below). That's important for us, because customer specific packages contain code that is not public. - GitLab is open source. - The GitLab founders are credible with their open source philosophy and the business model seems viable. We also publish on GitHub for PR reasons. It's free... Previously, our code was kept in a CVS repository. We installed GitLab in a VM and moved the CVS repository to the same CentOS VM that is running GitLab. Every night we now run "cvs2git" which is originally from http://cvs2svn.tigris.org/cvs2svn.html (http://cvs2svn.tigris.org/cvs2svn.html) but now available for example here: https://github.com/mhagger/cvs2svn (https://github.com/mhagger/cvs2svn) We have configured cvs2git to push the CVS changes both to GitHub and our private GitLab repos. This has worked without problems for quite some time, many repositories (our product consists of ~200 "packages" which are represented by separate repos) and very large repositories (we've got ~4 million LoC in total). Our next ]po[ V5.1 release will be based on GIT. We like that we can work with GIT on the "customer" side, while still using CVS as the upstream/master repository for some time. CVS is still referenced by many integration links, so we can't just break this. I believe the AmForth community should take several decisions: - Gradual or "big bang" migration? Should SVN and GIT run in parallel for some time, or is it OK to have a single big bang migration? Big bang is a lot easier... - Do you want to completely ignore GitHub? GitHub is the go-to place for open source software. Google does heavy indexing there. If you want AmForth to reach a large community, then you have to publish there. However, it doesn't need to the the primary repo... convert the releases/N.M directories This seems to be quite difficult to me. Maybe just keep these directories during the initial migration and delete them in the following releases? Keep up the good work! Cheers! Frank On 2/11/20 20:36, Erich Wälde wrote: Dear AmForthers, some time ago (2020-08-02), Mark Roth suggested to come up with a "road map". Now while mapping unknown territory is a challenge of sorts, it might be not that difficult in this case. This my personal point of view, it might change anytime without prior notice. 1. Accumulate all commits since Jan 2019 and call it *release 6.9* That I have done. :) 2. Document the exact steps that were needed to create "a release". Well yes, I have these lines, but not in shape and maybe not complete. It should be added to the repository nonetheless. 3. Add testing scripts --- I have a set of scripts for that, but I have not run this stuff yet. However, in my opinion adding a working test suite is far more important at the moment, than anything else. This includes preparing some hardware with 4 relevant target boards in order to simplify the process. 4. Call this *release 7.0* 5. Convert and Move Repository Currently it looks like I would have to convert the svn repository to a git repository with a tool like svn2git. This is a process I would like to avoid, so if someone knows how to convert the repository "server side", or even how to export the complete svn repository on sourceforge into a big file ... all hints are kindly appreciated. I would then move to sourcehut.org. Why? - I do have an account there already - sourcehut offers accounts for a very reasonable amount of money. - sourchut works without javascript! Can you believe this? No? Try it. For me this is a major step in the correct direction. [1] - I would order and pay for a new project account - I would like to add at least two collaborators with full access from day one. Volunteers? This is going to include more things than just converting the repository: - possibly convert the releases/N.M directories into branches - create a new space for the webpage - automate generation of the webpage, serverside if possible - document how to locally generate the documentation --- well, the stuff you have to install before "cd doc; make all". - look into the use of javascript and possible ways to reduce that, should it be desirable - create an archive for (some of) the old tarballs - archive and transfer the mailing list content - create a new mailing list - automate the generation of a release - document the release process - start using the bugtracker (preferably with connection to the mailing list) - test the branch-edit-pull.request-merge workflow - possibly convert "Opinion" into a prober blog? - setup a redirection notice on sourceforge, close everything else down. - possibly dissolve amforth/community into a ./contrib/ subdirectory, test the stuff again and document it better https://sourceforge.net/p/amforth/community/HEAD/tree/ (https://sourceforge.net/p/amforth/community/HEAD/tree/) And this list is not complete. 6. Call this *release 8.0* 7. Remove arm msp430 riscv for the sake of simplicity -- unless someone speaks up to offer help. Carsten has offered support for arm and riscv --- Thank you! msp430 anyone? 8. Fix and automate the creation of the reference cards - include ALL available WORDs (not only the ones in a particular build) - include the exact file path(s), where WORD is defined - possibly add a Forth equivalent (.asm WORDS) - possibly a pointer to a worked example In order to achieve that I would rework the existing perl script AND add any missing file headers, possibly in a new/enhanced format. If we get this far, then imho we have /advanced considerably/. Does this sound like a worthwile plan? I'm sure there are other ideas and suggestions. Point 5 is huge and needs to be broken into smaller steps. I would appreciate any response, and if you could include, which target you are using, all the better. Still reading? Thank you for your precious time. Happy forthing, Erich [1] I'm using torbrowser most of the time. I'm using firefox to work at amforth.sourceforge.net. However, NoScript or uMatrix do an excellent job, but break the sf.net webpage routinely. I do not see all the buttons and what not unless I really switch off NoScript. This is not, what I prefer. _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ (http://amforth.sf.net/) Amf...@li... (mailto:Amf...@li...) https://lists.sourceforge.net/lists/listinfo/amforth-devel (https://lists.sourceforge.net/lists/listinfo/amforth-devel) |
From: <fr...@fr...> - 2020-11-03 09:34:08
|
Hi! > Point 5 is huge and needs to be broken into smaller steps. > > I would appreciate any response, and if you could > include, which target you are using, all the better. We (http://www.project-open.com/) are in the process of moving from CVS to GIT for the next ]project-open[ V5.1 release. The process is the same for SVN, the tool is actually called svn2git... We decided to host our repos on a private GitLab instance because: - GitLab allows us to setup permissions for "packages" (see below). That's important for us, because customer specific packages contain code that is not public. - GitLab is open source. - The GitLab founders are credible with their open source philosophy and the business model seems viable. We also publish on GitHub for PR reasons. It's free... Previously, our code was kept in a CVS repository. We installed GitLab in a VM and moved the CVS repository to the same CentOS VM that is running GitLab. Every night we now run "cvs2git" which is originally from http://cvs2svn.tigris.org/cvs2svn.html but now available for example here: https://github.com/mhagger/cvs2svn We have configured cvs2git to push the CVS changes both to GitHub and our private GitLab repos. This has worked without problems for quite some time, many repositories (our product consists of ~200 "packages" which are represented by separate repos) and very large repositories (we've got ~4 million LoC in total). Our next ]po[ V5.1 release will be based on GIT. We like that we can work with GIT on the "customer" side, while still using CVS as the upstream/master repository for some time. CVS is still referenced by many integration links, so we can't just break this. I believe the AmForth community should take several decisions: - Gradual or "big bang" migration? Should SVN and GIT run in parallel for some time, or is it OK to have a single big bang migration? Big bang is a lot easier... - Do you want to completely ignore GitHub? GitHub is the go-to place for open source software. Google does heavy indexing there. If you want AmForth to reach a large community, then you have to publish there. However, it doesn't need to the the primary repo... > convert the releases/N.M directories This seems to be quite difficult to me. Maybe just keep these directories during the initial migration and delete them in the following releases? Keep up the good work! Cheers! Frank On 2/11/20 20:36, Erich Wälde wrote: > Dear AmForthers, > > some time ago (2020-08-02), Mark Roth suggested to come up with a > "road map". Now while mapping unknown territory is a challenge of > sorts, it might be not that difficult in this case. > > This my personal point of view, it might change anytime without prior > notice. > > 1. Accumulate all commits since Jan 2019 and call it *release 6.9* > That I have done. :) > > 2. Document the exact steps that were needed to create "a release". > Well yes, I have these lines, but not in shape and maybe not > complete. It should be added to the repository nonetheless. > > 3. Add testing scripts --- I have a set of scripts for that, but I > have not run this stuff yet. However, in my opinion adding a > working test suite is far more important at the moment, than > anything else. > > This includes preparing some hardware with 4 relevant target boards > in order to simplify the process. > > 4. Call this *release 7.0* > > 5. Convert and Move Repository > > Currently it looks like I would have to convert the svn repository > to a git repository with a tool like svn2git. This is a process I > would like to avoid, so if someone knows how to convert the > repository "server side", or even how to export the complete svn > repository on sourceforge into a big file ... all hints are kindly > appreciated. > > I would then move to sourcehut.org. Why? > > - I do have an account there already > - sourcehut offers accounts for a very reasonable amount of money. > - sourchut works without javascript! Can you believe this? No? Try it. > For me this is a major step in the correct direction. [1] > - I would order and pay for a new project account > - I would like to add at least two collaborators with full access > from day one. Volunteers? > > This is going to include more things than just converting the > repository: > > - possibly convert the releases/N.M directories into branches > - create a new space for the webpage > - automate generation of the webpage, serverside if possible > - document how to locally generate the documentation --- well, the > stuff you have to install before "cd doc; make all". > - look into the use of javascript and possible ways to reduce that, > should it be desirable > - create an archive for (some of) the old tarballs > - archive and transfer the mailing list content > - create a new mailing list > - automate the generation of a release > - document the release process > - start using the bugtracker (preferably with connection to the > mailing list) > - test the branch-edit-pull.request-merge workflow > - possibly convert "Opinion" into a prober blog? > - setup a redirection notice on sourceforge, close everything else > down. > - possibly dissolve amforth/community into a ./contrib/ > subdirectory, test the stuff again and document it better > https://sourceforge.net/p/amforth/community/HEAD/tree/ > > And this list is not complete. > > 6. Call this *release 8.0* > > 7. Remove arm msp430 riscv for the sake of simplicity -- unless > someone speaks up to offer help. > > Carsten has offered support for arm and riscv --- Thank you! > > msp430 anyone? > > 8. Fix and automate the creation of the reference cards > > - include ALL available WORDs (not only the ones in a particular > build) > - include the exact file path(s), where WORD is defined > - possibly add a Forth equivalent (.asm WORDS) > - possibly a pointer to a worked example > > In order to achieve that I would rework the existing perl script > AND add any missing file headers, possibly in a new/enhanced > format. > > > If we get this far, then imho we have /advanced considerably/. > > > > > Does this sound like a worthwile plan? > > I'm sure there are other ideas and suggestions. > > Point 5 is huge and needs to be broken into smaller steps. > > > I would appreciate any response, and if you could > include, which target you are using, all the better. > > > Still reading? > Thank you for your precious time. > > Happy forthing, > Erich > > > > [1] I'm using torbrowser most of the time. I'm using firefox to > work at amforth.sourceforge.net. However, NoScript or uMatrix do > an excellent job, but break the sf.net webpage routinely. I do > not see all the buttons and what not unless I really switch off > NoScript. This is not, what I prefer. > |
From: Ian J. <ij...@sa...> - 2020-11-03 01:39:37
|
Hi Erich, I’m probably another year out to offer any help if I’m even still capable… although I think I could muddle through and contribute some system admin type help with the irksome repositories. It seems to me that embedded hardware is vibrantly healthy and with the pressures IoT and of energy management low power etc. may stay that way. I’m curious therefore about the future of the current Atmel platform vs some of the other chips out there. Should amforth keep its name or has it evolved to something else than Atmel Forth? As for the plan it sounds great to me. I am especially the part about realizing that having a plan makes us better prepared for change not resistant to it. “it might change anytime without prior notice” . Thank you again for stepping in on this project. I hope to return to forth when I unpack my Oscilloscope and bench power supply wherever they went. May the forth be with all the AMForthers - or any other corny positive greeting I can offer in this very strange and ugly year. Ian > On Nov 2, 2020, at 2:36 PM, Erich Wälde <ew....@na...> wrote: > > > Dear AmForthers, > > some time ago (2020-08-02), Mark Roth suggested to come up with a > "road map". Now while mapping unknown territory is a challenge of > sorts, it might be not that difficult in this case. > > This my personal point of view, it might change anytime without prior > notice. > > 1. Accumulate all commits since Jan 2019 and call it *release 6.9* > That I have done. :) > > 2. Document the exact steps that were needed to create "a release". > Well yes, I have these lines, but not in shape and maybe not > complete. It should be added to the repository nonetheless. > > 3. Add testing scripts --- I have a set of scripts for that, but I > have not run this stuff yet. However, in my opinion adding a > working test suite is far more important at the moment, than > anything else. > > This includes preparing some hardware with 4 relevant target boards > in order to simplify the process. > > 4. Call this *release 7.0* > > 5. Convert and Move Repository > > Currently it looks like I would have to convert the svn repository > to a git repository with a tool like svn2git. This is a process I > would like to avoid, so if someone knows how to convert the > repository "server side", or even how to export the complete svn > repository on sourceforge into a big file ... all hints are kindly > appreciated. > > I would then move to sourcehut.org. Why? > > - I do have an account there already > - sourcehut offers accounts for a very reasonable amount of money. > - sourchut works without javascript! Can you believe this? No? Try it. > For me this is a major step in the correct direction. [1] > - I would order and pay for a new project account > - I would like to add at least two collaborators with full access > from day one. Volunteers? > > This is going to include more things than just converting the > repository: > > - possibly convert the releases/N.M directories into branches > - create a new space for the webpage > - automate generation of the webpage, serverside if possible > - document how to locally generate the documentation --- well, the > stuff you have to install before "cd doc; make all". > - look into the use of javascript and possible ways to reduce that, > should it be desirable > - create an archive for (some of) the old tarballs > - archive and transfer the mailing list content > - create a new mailing list > - automate the generation of a release > - document the release process > - start using the bugtracker (preferably with connection to the > mailing list) > - test the branch-edit-pull.request-merge workflow > - possibly convert "Opinion" into a prober blog? > - setup a redirection notice on sourceforge, close everything else > down. > - possibly dissolve amforth/community into a ./contrib/ > subdirectory, test the stuff again and document it better > https://sourceforge.net/p/amforth/community/HEAD/tree/ > > And this list is not complete. > > 6. Call this *release 8.0* > > 7. Remove arm msp430 riscv for the sake of simplicity -- unless > someone speaks up to offer help. > > Carsten has offered support for arm and riscv --- Thank you! > > msp430 anyone? > > 8. Fix and automate the creation of the reference cards > > - include ALL available WORDs (not only the ones in a particular > build) > - include the exact file path(s), where WORD is defined > - possibly add a Forth equivalent (.asm WORDS) > - possibly a pointer to a worked example > > In order to achieve that I would rework the existing perl script > AND add any missing file headers, possibly in a new/enhanced > format. > > > If we get this far, then imho we have /advanced considerably/. > > > > > Does this sound like a worthwile plan? > > I'm sure there are other ideas and suggestions. > > Point 5 is huge and needs to be broken into smaller steps. > > > I would appreciate any response, and if you could > include, which target you are using, all the better. > > > Still reading? > Thank you for your precious time. > > Happy forthing, > Erich > > > > [1] I'm using torbrowser most of the time. I'm using firefox to > work at amforth.sourceforge.net. However, NoScript or uMatrix do > an excellent job, but break the sf.net webpage routinely. I do > not see all the buttons and what not unless I really switch off > NoScript. This is not, what I prefer. > > -- > May the Forth be with you ... > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
From: Matt L. <ma...@te...> - 2020-11-02 22:10:55
|
I would love to see native Forth on the ESP8266 boards. With 4mb of storage that my boards have, it would be really handy. -- Matt On 11/2/20 3:36 PM, Tristan Williams wrote: > Hello Erich, AmForthers, > >> Does this sound like a worthwile plan? > Yes, very much so. > > I would be interested in progressing further with AmForth for > RISC-V. The existing AmForth target board HiFive1 has been > discontinued [1] - though there is the upgraded HiFive1 Rev B [2]. > > Are there any views on which RISC-V board(s) should be considered for > AmForth? > > I like the idea of converting "opinion" into a proper blog, perhaps > extending it to some more general Forth ideas/resources. > > Best wishes, > Tristan > > [1] https://www.sifive.com/boards/hifive1 > [2] https://www.sifive.com/boards/hifive1-rev-b > > On 02Nov20 20:36, Erich Wälde wrote: >> Dear AmForthers, >> >> some time ago (2020-08-02), Mark Roth suggested to come up with a >> "road map". Now while mapping unknown territory is a challenge of >> sorts, it might be not that difficult in this case. >> >> This my personal point of view, it might change anytime without prior >> notice. >> >> 1. Accumulate all commits since Jan 2019 and call it *release 6.9* >> That I have done. :) >> >> 2. Document the exact steps that were needed to create "a release". >> Well yes, I have these lines, but not in shape and maybe not >> complete. It should be added to the repository nonetheless. >> >> 3. Add testing scripts --- I have a set of scripts for that, but I >> have not run this stuff yet. However, in my opinion adding a >> working test suite is far more important at the moment, than >> anything else. >> >> This includes preparing some hardware with 4 relevant target boards >> in order to simplify the process. >> >> 4. Call this *release 7.0* >> >> 5. Convert and Move Repository >> >> Currently it looks like I would have to convert the svn repository >> to a git repository with a tool like svn2git. This is a process I >> would like to avoid, so if someone knows how to convert the >> repository "server side", or even how to export the complete svn >> repository on sourceforge into a big file ... all hints are kindly >> appreciated. >> >> I would then move to sourcehut.org. Why? >> >> - I do have an account there already >> - sourcehut offers accounts for a very reasonable amount of money. >> - sourchut works without javascript! Can you believe this? No? Try it. >> For me this is a major step in the correct direction. [1] >> - I would order and pay for a new project account >> - I would like to add at least two collaborators with full access >> from day one. Volunteers? >> >> This is going to include more things than just converting the >> repository: >> >> - possibly convert the releases/N.M directories into branches >> - create a new space for the webpage >> - automate generation of the webpage, serverside if possible >> - document how to locally generate the documentation --- well, the >> stuff you have to install before "cd doc; make all". >> - look into the use of javascript and possible ways to reduce that, >> should it be desirable >> - create an archive for (some of) the old tarballs >> - archive and transfer the mailing list content >> - create a new mailing list >> - automate the generation of a release >> - document the release process >> - start using the bugtracker (preferably with connection to the >> mailing list) >> - test the branch-edit-pull.request-merge workflow >> - possibly convert "Opinion" into a prober blog? >> - setup a redirection notice on sourceforge, close everything else >> down. >> - possibly dissolve amforth/community into a ./contrib/ >> subdirectory, test the stuff again and document it better >> https://sourceforge.net/p/amforth/community/HEAD/tree/ >> >> And this list is not complete. >> >> 6. Call this *release 8.0* >> >> 7. Remove arm msp430 riscv for the sake of simplicity -- unless >> someone speaks up to offer help. >> >> Carsten has offered support for arm and riscv --- Thank you! >> >> msp430 anyone? >> >> 8. Fix and automate the creation of the reference cards >> >> - include ALL available WORDs (not only the ones in a particular >> build) >> - include the exact file path(s), where WORD is defined >> - possibly add a Forth equivalent (.asm WORDS) >> - possibly a pointer to a worked example >> >> In order to achieve that I would rework the existing perl script >> AND add any missing file headers, possibly in a new/enhanced >> format. >> >> >> If we get this far, then imho we have /advanced considerably/. >> >> >> >> >> Does this sound like a worthwile plan? >> >> I'm sure there are other ideas and suggestions. >> >> Point 5 is huge and needs to be broken into smaller steps. >> >> >> I would appreciate any response, and if you could >> include, which target you are using, all the better. >> >> >> Still reading? >> Thank you for your precious time. >> >> Happy forthing, >> Erich >> >> >> >> [1] I'm using torbrowser most of the time. I'm using firefox to >> work at amforth.sourceforge.net. However, NoScript or uMatrix do >> an excellent job, but break the sf.net webpage routinely. I do >> not see all the buttons and what not unless I really switch off >> NoScript. This is not, what I prefer. >> >> -- >> May the Forth be with you ... >> >> >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
From: Tristan W. <ho...@tj...> - 2020-11-02 21:36:39
|
Hello Erich, AmForthers, > Does this sound like a worthwile plan? Yes, very much so. I would be interested in progressing further with AmForth for RISC-V. The existing AmForth target board HiFive1 has been discontinued [1] - though there is the upgraded HiFive1 Rev B [2]. Are there any views on which RISC-V board(s) should be considered for AmForth? I like the idea of converting "opinion" into a proper blog, perhaps extending it to some more general Forth ideas/resources. Best wishes, Tristan [1] https://www.sifive.com/boards/hifive1 [2] https://www.sifive.com/boards/hifive1-rev-b On 02Nov20 20:36, Erich Wälde wrote: > > Dear AmForthers, > > some time ago (2020-08-02), Mark Roth suggested to come up with a > "road map". Now while mapping unknown territory is a challenge of > sorts, it might be not that difficult in this case. > > This my personal point of view, it might change anytime without prior > notice. > > 1. Accumulate all commits since Jan 2019 and call it *release 6.9* > That I have done. :) > > 2. Document the exact steps that were needed to create "a release". > Well yes, I have these lines, but not in shape and maybe not > complete. It should be added to the repository nonetheless. > > 3. Add testing scripts --- I have a set of scripts for that, but I > have not run this stuff yet. However, in my opinion adding a > working test suite is far more important at the moment, than > anything else. > > This includes preparing some hardware with 4 relevant target boards > in order to simplify the process. > > 4. Call this *release 7.0* > > 5. Convert and Move Repository > > Currently it looks like I would have to convert the svn repository > to a git repository with a tool like svn2git. This is a process I > would like to avoid, so if someone knows how to convert the > repository "server side", or even how to export the complete svn > repository on sourceforge into a big file ... all hints are kindly > appreciated. > > I would then move to sourcehut.org. Why? > > - I do have an account there already > - sourcehut offers accounts for a very reasonable amount of money. > - sourchut works without javascript! Can you believe this? No? Try it. > For me this is a major step in the correct direction. [1] > - I would order and pay for a new project account > - I would like to add at least two collaborators with full access > from day one. Volunteers? > > This is going to include more things than just converting the > repository: > > - possibly convert the releases/N.M directories into branches > - create a new space for the webpage > - automate generation of the webpage, serverside if possible > - document how to locally generate the documentation --- well, the > stuff you have to install before "cd doc; make all". > - look into the use of javascript and possible ways to reduce that, > should it be desirable > - create an archive for (some of) the old tarballs > - archive and transfer the mailing list content > - create a new mailing list > - automate the generation of a release > - document the release process > - start using the bugtracker (preferably with connection to the > mailing list) > - test the branch-edit-pull.request-merge workflow > - possibly convert "Opinion" into a prober blog? > - setup a redirection notice on sourceforge, close everything else > down. > - possibly dissolve amforth/community into a ./contrib/ > subdirectory, test the stuff again and document it better > https://sourceforge.net/p/amforth/community/HEAD/tree/ > > And this list is not complete. > > 6. Call this *release 8.0* > > 7. Remove arm msp430 riscv for the sake of simplicity -- unless > someone speaks up to offer help. > > Carsten has offered support for arm and riscv --- Thank you! > > msp430 anyone? > > 8. Fix and automate the creation of the reference cards > > - include ALL available WORDs (not only the ones in a particular > build) > - include the exact file path(s), where WORD is defined > - possibly add a Forth equivalent (.asm WORDS) > - possibly a pointer to a worked example > > In order to achieve that I would rework the existing perl script > AND add any missing file headers, possibly in a new/enhanced > format. > > > If we get this far, then imho we have /advanced considerably/. > > > > > Does this sound like a worthwile plan? > > I'm sure there are other ideas and suggestions. > > Point 5 is huge and needs to be broken into smaller steps. > > > I would appreciate any response, and if you could > include, which target you are using, all the better. > > > Still reading? > Thank you for your precious time. > > Happy forthing, > Erich > > > > [1] I'm using torbrowser most of the time. I'm using firefox to > work at amforth.sourceforge.net. However, NoScript or uMatrix do > an excellent job, but break the sf.net webpage routinely. I do > not see all the buttons and what not unless I really switch off > NoScript. This is not, what I prefer. > > -- > May the Forth be with you ... > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Erich W. <ew....@na...> - 2020-11-02 19:37:04
|
Dear AmForthers, some time ago (2020-08-02), Mark Roth suggested to come up with a "road map". Now while mapping unknown territory is a challenge of sorts, it might be not that difficult in this case. This my personal point of view, it might change anytime without prior notice. 1. Accumulate all commits since Jan 2019 and call it *release 6.9* That I have done. :) 2. Document the exact steps that were needed to create "a release". Well yes, I have these lines, but not in shape and maybe not complete. It should be added to the repository nonetheless. 3. Add testing scripts --- I have a set of scripts for that, but I have not run this stuff yet. However, in my opinion adding a working test suite is far more important at the moment, than anything else. This includes preparing some hardware with 4 relevant target boards in order to simplify the process. 4. Call this *release 7.0* 5. Convert and Move Repository Currently it looks like I would have to convert the svn repository to a git repository with a tool like svn2git. This is a process I would like to avoid, so if someone knows how to convert the repository "server side", or even how to export the complete svn repository on sourceforge into a big file ... all hints are kindly appreciated. I would then move to sourcehut.org. Why? - I do have an account there already - sourcehut offers accounts for a very reasonable amount of money. - sourchut works without javascript! Can you believe this? No? Try it. For me this is a major step in the correct direction. [1] - I would order and pay for a new project account - I would like to add at least two collaborators with full access from day one. Volunteers? This is going to include more things than just converting the repository: - possibly convert the releases/N.M directories into branches - create a new space for the webpage - automate generation of the webpage, serverside if possible - document how to locally generate the documentation --- well, the stuff you have to install before "cd doc; make all". - look into the use of javascript and possible ways to reduce that, should it be desirable - create an archive for (some of) the old tarballs - archive and transfer the mailing list content - create a new mailing list - automate the generation of a release - document the release process - start using the bugtracker (preferably with connection to the mailing list) - test the branch-edit-pull.request-merge workflow - possibly convert "Opinion" into a prober blog? - setup a redirection notice on sourceforge, close everything else down. - possibly dissolve amforth/community into a ./contrib/ subdirectory, test the stuff again and document it better https://sourceforge.net/p/amforth/community/HEAD/tree/ And this list is not complete. 6. Call this *release 8.0* 7. Remove arm msp430 riscv for the sake of simplicity -- unless someone speaks up to offer help. Carsten has offered support for arm and riscv --- Thank you! msp430 anyone? 8. Fix and automate the creation of the reference cards - include ALL available WORDs (not only the ones in a particular build) - include the exact file path(s), where WORD is defined - possibly add a Forth equivalent (.asm WORDS) - possibly a pointer to a worked example In order to achieve that I would rework the existing perl script AND add any missing file headers, possibly in a new/enhanced format. If we get this far, then imho we have /advanced considerably/. Does this sound like a worthwile plan? I'm sure there are other ideas and suggestions. Point 5 is huge and needs to be broken into smaller steps. I would appreciate any response, and if you could include, which target you are using, all the better. Still reading? Thank you for your precious time. Happy forthing, Erich [1] I'm using torbrowser most of the time. I'm using firefox to work at amforth.sourceforge.net. However, NoScript or uMatrix do an excellent job, but break the sf.net webpage routinely. I do not see all the buttons and what not unless I really switch off NoScript. This is not, what I prefer. -- May the Forth be with you ... |
From: Carsten S. <ca...@st...> - 2020-10-31 19:31:05
|
Hi Erich, Hi amForth coders, @Erich: thank you for continuing the work on amForth! I've been absent from amForth for a long time, but I consider to join back in to do some work on the RISC-V and ARM side of things (I currently have no usecase for AVR, but that is fine). I want to respond to an list of questions from Erich earlier this year (sorry for being so late). I think these ideas could need more discussion. >- Whacky Ideas > > - git? -- With all the cool kids using git repositories, should > I attempt do convert the existing repositories, webpage, etc? > does sourceforge.net provide git repositories? Can the > existing svn repository be converted on the server side? I find SourceForge (SF) a real pain and I don't like to interact with the SF system/webpage. I think there is a =git= interface on SF, but it does not have the workflow the workflow that makes =git= successful elsewhere. =git= alone does not help much, it's the workflow around it that makes developent and contribution fun to use. I really prefer to use SourceHut (https://sr.ht) these days, the interface is quick and lean (no JavaScript required). I also find that Drew DeVault, who runs SH, has a good view on free software development. GitLab and GitHub have their own problems, but are quite popular and, for me, are less painful compared to SF. > - Should we use a ticket system rather than mailing list? Both. The ticket system should work over email and should integrate into an email workflow. A mailing list is nice(er) for general discussions. > - Who of you is using which target controller? Would it be > feasible to drop msp430, arm, risc-v in order to simplify the > whole thing? yes/no? As I would like to work on RISC-V and ARM, I vote =NO= here. > - Can we get rid of the Atmel/Microchip Avrasm Assembler? > > One big difference between the avr8 and the risc-v tree is > the assembly language. avr8 is using Atmels assembly. Which > is good, because it is thoroughly documented. And which is > bad, because there is no working free/libre alternative to > avrasm.exe. Yes there is the "avra" project but it has been > abandoned long ago. I have been able to assemble AmForth with > avra way back in releases 4.2 up until maybe 4.9. I have even > contributed a small patch to make atmega644p working. > https://sourceforge.net/projects/avra/ > > Matthias has contemplated the idea to port AmForth/avr8 to > use gnu assembly. He might even have produced a working > branch, I don't know. I've used AVRA back in the day when I've worked with amForth 4.x. Using Wine and non free software is generally a no go for me, esp. as I often work on non-Intel machines (ARM, MIPS, PPC). There I need to be able to compile from source. > For risc-v there is no avr assembly, naturally. That's where > all the .s assembly files come into the game. > > I personally would love to have a free/libre assembler for > avr assembly. AVRASM.EXE is the only thing that forces me to > install wine on my system. Maybe porting amForth own AVR assembler (http://amforth.sourceforge.net/TG/recipes/Assembler.html) to GNU/Forth and use that as the base assembler? Greetings Carsten |
From: <fr...@fr...> - 2020-10-24 16:41:27
|
Hi Erich, Thanks for welcoming me to your community. Thanks to everybody for the constructive feed-back and the good pointers! > reading a datasheet In my case I first found Amforth and then I read the datasheet. I believe that's true for 95% of potential users. Is being able to read datasheets a precondition to using Amforth? This would keep out 95% to 98% of potential users... Actually, we are doing something similar at ]project-open[, we call it "customer self-selection" :-) Only users with experience in SAP / ERP understand our system. But in our case it's not intended... We use a Wiki to document our internal procedures because it is so little effort... George Herzog wrote: > USB is to some extent proprietary, where as RS-232, > SPI, and I2C are easier to deploy. I mentioned that SPI failed for me completely in a bus- like setup (a stack of multiple PCBs with connectors on one side). I guess that's because it requires a common GND between all components. Also, debugging via SPI didn't work. There were several debugging sources in Amforth that sent stuff directly to the UART so that I needed a serial port anyway :-( And in my setup I'm not ready to replace the RasPI with anything else, because it's great for WiFi and we plan to run some AI functions. > If you come up with patches to make usb on the 32u4 work Tristan Williams wrote: > AmForth 6.9 does not support a connection to the USB > controller of the ATmega32U4 or any AVR8 as far as I know. > This is something I, and quite a few other people I believe, > would like - but it is not there yet. No 32u4! I just bought 5 pieces of CP2102 / FT232 based USB to UART converters for EUR 1.00 / pcs in order to connect my good ol' 328s to USB. So I'm going to skip any experiments with Leonardo or Mega 2560: USB Advantage and Disadvantages: + Cheap and proven: The protocol even does re-sends in case of noise in the line and reports failures. + USB has differential signalling: (RS-422 and RS-485 also have, but sooo much overhead...) + Just one cable to each subsystem for both data and power (space for cables is critical in my setup). Plus a second cable for motor power, obviously... + 3.3V and 5.0V output from FT232: The FT232 provides 3.3V, that should be enough for my 328s + USB is fast + I can connect as many devices as I want using an USB hub as RasPI HAT. I will use a HUB with extra 2.5A 5V power connector. + For debugging I can take the subsystem and attach it to a laptop. + No common GND anymore: I would like to locate my 328s close to the motors, because there is some space. USB comes with it's own GND, but it's OK if that is not perfect because of the USB differential drivers. + Linux drivers available Downsides: - USB may not be as reliable as a electrically stable RS232 or similar? Any references? - Did I miss something? > I would never even try to build something on USB, > should my life depend on it. OK, it's just a robot, no life depends on it. Thank you very much Erich for sharing your Amforth 4.6 vs. 6.8 experience. I'll definitely proceed with caution and make sure there's a watchdog and/or central reset button :-) > The essence of this is: start very simple. > Try to make your project run for extented periods of time. Thank you! Very good advice! I'll let you know about my USB experience. I will definitely make sure DC motors and Atmegas won't share common GND! > Should you decide to climb it I'm pretty much on top already, I believe... As I said, I even had a SPI driver for Amforth running, allowing my RasPI to send commands to the various 328s via SPI and my angle encoders for the DC motors work using interrupts. I guess that's getting close to the core, isn't it? George Herzog wrote: > More appropriate than a Raspberry Pi with Linux. The RasPi Zero W is great to handle WiFi communications etc. I also plan to deploy a camera and some AI functions there. The USB Hub HAT can distribute separate 2.5A power, so that should be enough for the logic part. Thanks for pointing to the pitfall, though. > Use of Forth to Enable Distributed Processing on Wireless > Sensor Networks Thanks, read! Right, this is the type of system I was thinking about, just using a wireless protocol. Actually, I read this paper already a year ago and used it as one of the "inspirations" for the SPI driver code. Cheers! Frank |
From: Erich W. <ew....@na...> - 2020-10-23 17:00:10
|
Hello Frank, and welcome to the list. fr...@fr... writes: > Hi! > > > Summary: I believe you could greatly increase the > number of Amforth users with little effort providing > one Wiki page per hardware device. There you would > provide fuse settings, name of a suitable binary, > parameters for the flasher etc. in order to reduce the > frustration of a rookie to see the first Forth prompt. > It's only 20-50 devices, that's not much compared to > the list of devices in Arch Linux for example (I found > my specific laptop model there...). > SourceForge offers a Wiki very suitable for that! * wiki pages: Well, maybe. However man- or woman-power is the key resource to this. I will certainly not start such a thing on my own. Moreover, I'm convinced that reading a datasheet and having "control" over your board is worth more than writing more documentation --- which will be outdated sooner than you wish. > In Detail: > > I'm a fellow open source guy, running a project > here on SourceForge for a living: > https://sourceforge.net/projects/project-open/ > Also, 30 years ago I wrote a Forth for Inmos > Transputers... Cool! I have not written my own Forth, and I have resisted the urge for over 10 years. I just try to keep this project alive after the original author had to abandon it. > So: Congratulations to your work on Amforth! > I managed to get it running on a barebone AtMega > 328 for a hobby project (a tracked robot with my > son...). > > I implemented drivers for both stepper motors > and DC motors with angle coders without too much > trouble and to send Forth commands over SPI. > > However, I got some trouble trying to connect > multiple 328s to a single RasPi and finally serious > trouble with spikes from the DC motors affecting > the SPI bus :-( You absolutely must provide separate power supplies for the controller and for the DC motors. I would not even share the same ground. Use opto couplers and appropriate diodes and capacitors to filter the effects of the motors. Other projects have solved this sort of thing, just hunt for them. https://roboternetz.de/ is one. > For the next iteration I'd like to decouple the > various I/O subsystems electrically and use UART > over USB for communication in order to address the > issues both with multiple devices (USB hub as PI > HAT) and noise (USB has differential signaling...) > > So, I'd like to use a 32U4 or Mega 2560 or similar > for each subsystem and a RasPi Zero W as a base, > but I haven't yet purchased anything. > Here some information on the supported features > would come in handy. I've spent several hours > trying to understand if/how Amforth supports > USB/UART in these model. 6.9 doesn't seem to > support it at all, correct? > > > There isn't much space in a robot, and USB cables > are surprisingly bulky. And now imagine that I'd > somehow need to have 2x USB for each Atmega... * USB is, well, not cool. I would never even try to build something on USB, should my life depend on it. I have seen way too many difficulties with industrial anything on USB. Keep it simple! If you come up with patches to make usb on the 32u4 work, I shall look into integrating them. And I'm sure there are more readers on the list, who would try them. > I wonder if I'm the only one trying to build a more > complex system using Amforth or if others had > similar problems... > > I have also found very few postings in the Internet > from people connecting multiple Arduinos to > a RasPI or to build bigger projects in general. > That's precisely where I see the value of Amforth, > because it introduces a protocol layer that is > easy to debug and decouples the subsystems. * robot or other complex system: If you play with software (no matter which one exactly), you are not dealing with software alone. Never. You are dealing with hardware (printed circuit board, components, chips, cables! and connectors!), power (there is much to be learned about power supplies), signals and impedance (like it or not), a programmer, an assembler, and finally the software system itself. You cannot run this software in empty space. I myself have a modestly complex setup with atmega32 controllers on a RS485 bus. The software I wrote using AmForth 4.6 is running since maybe 10 years with very few hiccups. However: I have failed miserably to recreate this system with AmForth 6.8+ on nice and shiny boards with atmega644pa controllers. And I have no idea, why. It works for some time and then all of a sudden the controller stops dead in it's tracks and blocks any access. Very interestingly: a reset or power cycle does *NOT* help. So I'm currently completely out of ideas. The essence of this is: start very simple. Try to make your project run for extented periods of time. And see where it gets you. If you tend to use an ARM controller, do not hesitate to try Mecrisp (Author Matthias Koch). Mecrisp is a native Forth and not an indirect threaded one. I have no experience with arm controllers, so others on the list may have a say. Yes, I know, the initial hill is steep. Should you decide to climb it, the mailing list is there to help. The Archives harbour lots of hints, too. The fuse settings can be found in appl/arduino/Makefile. Did you see them? Using forth itself as a protocol to talk to other controllers has been tried in at least 2 places, one is not public, the other is this: Vierte Dimension 2016/1 page 9ff Salvatore Gaglio et al. -- Use of Forth to Enable Distributed Processing on Wireless Sensor Networks (english text) https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2016-01.pdf and references therein. Happy forthing! Erich > Cheers, and keep up the good work! > Frank |
From: George H. <jac...@gm...> - 2020-10-23 08:47:46
|
Frankly, making everything USB dependent takes you into trouble. USB is to some extent proprietary, where as RS-232, SPI, and I2C are easier to deploy. Early versions of the Raspberry Pi had deeply constrained power distribution. That may be a source of further woes. Perhaps a shift to an STM324xx device with multiple available USARTs and Mecrisp-Stellaris Forth would be more appropriate than a Raspberry Pi with Linux. Individual wikis for each device would certainly be nice in AmForth, but I suspect this is suffering sufficient manpower to maintain. There are ARM fuse selection applications available that can be somewhat useful. On Fri, Oct 23, 2020, 6:54 AM <fr...@fr...> wrote: > Hi! > > > Summary: I believe you could greatly increase the > number of Amforth users with little effort providing > one Wiki page per hardware device. There you would > provide fuse settings, name of a suitable binary, > parameters for the flasher etc. in order to reduce the > frustration of a rookie to see the first Forth prompt. > It's only 20-50 devices, that's not much compared to > the list of devices in Arch Linux for example (I found > my specific laptop model there...). > SourceForge offers a Wiki very suitable for that! > > > In Detail: > > I'm a fellow open source guy, running a project > here on SourceForge for a living: > https://sourceforge.net/projects/project-open/ > Also, 30 years ago I wrote a Forth for Inmos > Transputers... > > > So: Congratulations to your work on Amforth! > I managed to get it running on a barebone AtMega > 328 for a hobby project (a tracked robot with my > son...). > > I implemented drivers for both stepper motors > and DC motors with angle coders without too much > trouble and to send Forth commands over SPI. > > However, I got some trouble trying to connect > multiple 328s to a single RasPi and finally serious > trouble with spikes from the DC motors affecting > the SPI bus :-( > > For the next iteration I'd like to decouple the > various I/O subsystems electrically and use UART > over USB for communication in order to address the > issues both with multiple devices (USB hub as PI > HAT) and noise (USB has differential signaling...) > > So, I'd like to use a 32U4 or Mega 2560 or similar > for each subsystem and a RasPi Zero W as a base, > but I haven't yet purchased anything. > Here some information on the supported features > would come in handy. I've spent several hours > trying to understand if/how Amforth supports > USB/UART in these model. 6.9 doesn't seem to > support it at all, correct? > > > There isn't much space in a robot, and USB cables > are surprisingly bulky. And now imagine that I'd > somehow need to have 2x USB for each Atmega... > > I wonder if I'm the only one trying to build a more > complex system using Amforth or if others had > similar problems... > > I have also found very few postings in the Internet > from people connecting multiple Arduinos to > a RasPI or to build bigger projects in general. > That's precisely where I see the value of Amforth, > because it introduces a protocol layer that is > easy to debug and decouples the subsystems. > > > Cheers, and keep up the good work! > Frank > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Tristan W. <ho...@tj...> - 2020-10-23 08:46:11
|
On 23Oct20 00:28, fr...@fr... wrote: > Hi! > > > Summary: I believe you could greatly increase the > number of Amforth users with little effort providing > one Wiki page per hardware device. There you would > provide fuse settings, name of a suitable binary, > parameters for the flasher etc. in order to reduce the > frustration of a rookie to see the first Forth prompt. > It's only 20-50 devices, that's not much compared to > the list of devices in Arch Linux for example (I found > my specific laptop model there...). > SourceForge offers a Wiki very suitable for that! > > > In Detail: > > I'm a fellow open source guy, running a project > here on SourceForge for a living: > https://sourceforge.net/projects/project-open/ > Also, 30 years ago I wrote a Forth for Inmos > Transputers... > > > So: Congratulations to your work on Amforth! > I managed to get it running on a barebone AtMega > 328 for a hobby project (a tracked robot with my > son...). > > I implemented drivers for both stepper motors > and DC motors with angle coders without too much > trouble and to send Forth commands over SPI. > > However, I got some trouble trying to connect > multiple 328s to a single RasPi and finally serious > trouble with spikes from the DC motors affecting > the SPI bus :-( > > For the next iteration I'd like to decouple the > various I/O subsystems electrically and use UART > over USB for communication in order to address the > issues both with multiple devices (USB hub as PI > HAT) and noise (USB has differential signaling...) > > So, I'd like to use a 32U4 or Mega 2560 or similar > for each subsystem and a RasPi Zero W as a base, > but I haven't yet purchased anything. > Here some information on the supported features > would come in handy. I've spent several hours > trying to understand if/how Amforth supports > USB/UART in these model. 6.9 doesn't seem to > support it at all, correct? > > > There isn't much space in a robot, and USB cables > are surprisingly bulky. And now imagine that I'd > somehow need to have 2x USB for each Atmega... > > I wonder if I'm the only one trying to build a more > complex system using Amforth or if others had > similar problems... > > I have also found very few postings in the Internet > from people connecting multiple Arduinos to > a RasPI or to build bigger projects in general. > That's precisely where I see the value of Amforth, > because it introduces a protocol layer that is > easy to debug and decouples the subsystems. > > > Cheers, and keep up the good work! > Frank > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > Hello Frank, > Also, 30 years ago I wrote a Forth for Inmos > Transputers... Transputers - that does take me back. I remember looking longingly at an add-on transputer box for the Atari ST at a computer fair in London in the 1980s. It was well beyond my budget, however. > So, I'd like to use a 32U4 or Mega 2560 or similar > for each subsystem and a RasPi Zero W as a base, > but I haven't yet purchased anything. > Here some information on the supported features > would come in handy. I've spent several hours > trying to understand if/how Amforth supports > USB/UART in these model. 6.9 doesn't seem to > support it at all, correct? AmForth 6.9 does not support a connection to the USB controller of the ATmega32U4 or any AVR8 as far as I know. This is something I, and quite a few other people I believe, would like - but it is not there yet. Best wishes, Tristan |