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
(7) |
Sep
(9) |
Oct
|
Nov
(4) |
Dec
|
|
From: Ian J. <ij...@sa...> - 2010-05-25 15:29:35
|
Hi Andy, I think you want to look at marker. From gforth: marker forget1 ok : hello ." Hello One " cr ; ok marker forget2 ok : hello ." Hello Two " cr ; redefined hello ok hello Hello Two ok forget2 ok hello Hello One ok forget1 ok hello :55: Undefined word >>>hello<<< Backtrace: $7FBA4EB4 throw $7FBB1618 no.extensions $7FBA502C interpreter-notfound1 On Tue, 25 May 2010, an...@ki... wrote: > Erich, Matthias, Guys > > Thanks. > > I had a quick play with the installed amforth last night and it works fine. > > The usual "Hello World" compiled and ran fine as well as a couple of > other simple words. > > I guess I need to tidy up the templates, sort out ISR comms and enable > brown out detect etc. > > Something I noticed looking at the datasheets the 640, 1280 and 2560 are > the same device/pinout. Implications being it is possible (with SMT > rework) to upgrade a standard Arduino Mega to an Arduino Mega-Mega. ie > using the 2560 instead of the smaller 1280. Same IO more memory. > > Could be a useful platform for developing Amforth for larger memory devices. > > I am surprised no one is selling these commercially yet. > > A quick question, forget does not seem to be implemented, how do I get > rid of the words I compiled without a full reload ?? (There must be a > way but at silly o'clock this morning I was'nt seeing it.) > > Cheers > > Andy Kirby > > > Erich Waelde wrote: >> Hi Andy, >> >> On 05/23/2010 10:59 PM, an...@ki... wrote: >>> Guys >>> >>> We have a prompt at least that bit works. The issue was the USART >>> initialization plus the fuse bits. (These look to be working as Ext >>> 0xFF, Hi 0xD9, Lo 0xF7) >> >> You made it! Congrats! Getting a device up is hard, no question ... >> >> >> Cheers, >> Erich >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Amforth-devel mailing list >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > --------------------------------- --------------------------------------------- > > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: <an...@ki...> - 2010-05-25 14:43:19
|
Erich, Matthias, Guys Thanks. I had a quick play with the installed amforth last night and it works fine. The usual "Hello World" compiled and ran fine as well as a couple of other simple words. I guess I need to tidy up the templates, sort out ISR comms and enable brown out detect etc. Something I noticed looking at the datasheets the 640, 1280 and 2560 are the same device/pinout. Implications being it is possible (with SMT rework) to upgrade a standard Arduino Mega to an Arduino Mega-Mega. ie using the 2560 instead of the smaller 1280. Same IO more memory. Could be a useful platform for developing Amforth for larger memory devices. I am surprised no one is selling these commercially yet. A quick question, forget does not seem to be implemented, how do I get rid of the words I compiled without a full reload ?? (There must be a way but at silly o'clock this morning I was'nt seeing it.) Cheers Andy Kirby Erich Waelde wrote: > Hi Andy, > > On 05/23/2010 10:59 PM, an...@ki... wrote: >> Guys >> >> We have a prompt at least that bit works. The issue was the USART >> initialization plus the fuse bits. (These look to be working as Ext >> 0xFF, Hi 0xD9, Lo 0xF7) > > You made it! Congrats! Getting a device up is hard, no question ... > > > Cheers, > Erich > > ------------------------------------------------------------------------------ > > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Erich W. <ew....@na...> - 2010-05-24 07:57:04
|
Hi Andy, On 05/23/2010 10:59 PM, an...@ki... wrote: > Guys > > We have a prompt at least that bit works. The issue was the USART > initialization plus the fuse bits. (These look to be working as Ext > 0xFF, Hi 0xD9, Lo 0xF7) You made it! Congrats! Getting a device up is hard, no question ... Cheers, Erich |
|
From: <an...@ki...> - 2010-05-23 20:59:25
|
Guys We have a prompt at least that bit works. The issue was the USART initialization plus the fuse bits. (These look to be working as Ext 0xFF, Hi 0xD9, Lo 0xF7) Assembled and programmed I now get the amforth 3.8 ATmega 128 banner (Need to change this to 1280) and an ok prompt. Don't have time tonight but in a day or so I can have a play with writing a bit of : script and seeing if it compiles and stores etc. I will forward the template and device files to Mathias to go in the repository. Cheers Andy Kirby Andy Kirby wrote: > Just noticed the usart mode select that is being configured into usart register c is selecting synchronous when it should be asynchronous. > > UMSEL does not need setting at all the default 00 is asynchronous for these. Will try it tonight at some point. > > Cheers > > andy kirby > > -- > Like a rolling stone > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Andy K. <an...@ki...> - 2010-05-23 11:32:39
|
Just noticed the usart mode select that is being configured into usart register c is selecting synchronous when it should be asynchronous. UMSEL does not need setting at all the default 00 is asynchronous for these. Will try it tonight at some point. Cheers andy kirby -- Like a rolling stone |
|
From: <an...@ki...> - 2010-05-22 21:08:24
|
Yup I found the AVR fuse calculator/s today. I will try those settings. we certainly don't want to set the boot vector fuse, as this causes a reset or boot to go straight to the boot loader section of flash. (Top of flash) When as I understand it amforth is booting from the label just after the interrupt vector table at the bottom of flash. (default). So I will get rid of that and try again. I think taking some time to rummage through the listing file will help as well, as everything is ordered in there as it goes onto the device. I find this makes it easier for me to follow what is happening rather than trying to work out which files and includes are in/out and in what order/segments the code will end up. Cheers Andy Kirby Matthias Trute wrote: > Hi Andy, > > > A few remarks from me (sorry, but I dont have the right > hardware at hand and the simulator is not really helpful) > > Do you know the the web avr fuse calculator? > > http://www.engbedded.com/fusecalc > > I just played around with it from your remarks > >>>> BOD, Disabled >>>> SPI, Enabled >>>> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000) >>>> Full swing osc , slow rise time with max delays >>>> > > I stumbled across the full swing osc. The arduino schematics tells me > there is a quartz. > My guess for the fuses would be low 0x7f, high 0x99 and extended 0xff > (just enter > the values on the website to see the effects: factory default and a 16MHz > quartz). > >> >> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000) >> is correct though, or is it ?? >> > > The max_dict_address is the highest address the self programming > feature can deal with. Everything above this limit is read-only for amforth. > It's basically the same as the maximum boot loader size. But: It's not a > bootloader, the reset has to start at address 0x0000, not at the bootloader > start address. (to make things even more complicate: It's possible to > move the amforth to the bootloader and turn it into an unbreakable > system, but thats a completly different story; I would not stress it _now_). > > >> Hmm a scope it is then, my hearing is very poor in the ultrasonic <|;) >> > > ROTFL mine too ;=) > >> That's reassuring to know. I think I want to keep this to the templates >> and board specific bits though. Rather than mess with the code that is >> common to all. >> > > I just ordered an arduino mega, but it will take a week or two. Just > keep the hope > that it works. I absolutly sure it will do so. > > Matthias > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Andy K. <an...@ki...> - 2010-05-22 09:18:27
|
Yup looks like the mailing list is (probably very sensibly) filtering out attachments. Having emailed mathias direct with the attachments i was kind of hoping they would automagicaly appear in the repository as the current state of the work in progress. Mathias maybe busy thoug. I am working at the moment so will forward on the files to anyone askin when i get in tonight. The cheapest arduino clones i have found are the dfrduino boards made in china. I got two mega clones from a uk importer (www.yerobot.com). Sorry probably a bit late if you have already ordered. Cheers andy kirby -- Like a rolling stone ----- Original message ----- > Duhhhh > > Helps if I actually attach the zip file does'nt it. > > an...@ki... wrote: > > Guys > > > > Please find attached the current copy of the forthduino application > > templates so far. (I wonder if we should really be calling it > > forthduino1280, amforthduino, or amforthmegaduino or some such ??) > > > > There is a devices folder in there with the two device definition files. > > I know they don't go there really. > > > > I put them there to get it all into an easy zip file to email. So they > > need to come out and be put in the right place in the repository amongst > > the core stuff. > > > > These are the current state of non working play. > > > > All tweaked to assemble with the release version of amforth using AVR > > Studio 4.18 with no warnings or errors. > > > > Still no go on uart0 talking to us and doing interactive forth. > > > > Time to add some LED action I think. > > > > BTW, the amforth project docs that are on the front page of the web site > > imply that the templates are used by copying them to \amforthxxx when > > for the paths etc to work they need to be copied to \amforthxxx\core. > > Again a little thing. Sorry. > > > > Cheers > > > > Andy Kirby > > > > PS the zip file minus the device definitions is a starter contribution > > for the forthduino amforth app template to go in to the appl folder with > > the other templates > > > > > > > > > > |
|
From: Matthias T. <mt...@we...> - 2010-05-21 18:19:20
|
Hi Andy, A few remarks from me (sorry, but I dont have the right hardware at hand and the simulator is not really helpful) Do you know the the web avr fuse calculator? http://www.engbedded.com/fusecalc I just played around with it from your remarks >>> BOD, Disabled >>> SPI, Enabled >>> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000) >>> Full swing osc , slow rise time with max delays >>> I stumbled across the full swing osc. The arduino schematics tells me there is a quartz. My guess for the fuses would be low 0x7f, high 0x99 and extended 0xff (just enter the values on the website to see the effects: factory default and a 16MHz quartz). > >> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000) > is correct though, or is it ?? > The max_dict_address is the highest address the self programming feature can deal with. Everything above this limit is read-only for amforth. It's basically the same as the maximum boot loader size. But: It's not a bootloader, the reset has to start at address 0x0000, not at the bootloader start address. (to make things even more complicate: It's possible to move the amforth to the bootloader and turn it into an unbreakable system, but thats a completly different story; I would not stress it _now_). > Hmm a scope it is then, my hearing is very poor in the ultrasonic <|;) > ROTFL mine too ;=) > That's reassuring to know. I think I want to keep this to the templates > and board specific bits though. Rather than mess with the code that is > common to all. > I just ordered an arduino mega, but it will take a week or two. Just keep the hope that it works. I absolutly sure it will do so. Matthias |
|
From: Ian J. <ij...@sa...> - 2010-05-21 15:25:26
|
Hi Andy, Thought you might appreciate some feedback. Thanks! This is a quiet list usually but wonderful progress is being made on wonderful forth. I'm a beginner but have been able to enjoy amforth. I did not see the attachments... maybe filtered by the listserver? On Fri, 21 May 2010, an...@ki... wrote: > Guys > > Please find attached the current copy of the forthduino application > templates so far. (I wonder if we should really be calling it > forthduino1280, amforthduino, or amforthmegaduino or some such ??) > I like Arduino-Forth mainly because in my mind the Butterfly is Butter-Forth ... but I think the authors should have the honour of naming. Ian |
|
From: <an...@ki...> - 2010-05-21 11:21:21
|
Duhhhh Helps if I actually attach the zip file does'nt it. an...@ki... wrote: > Guys > > Please find attached the current copy of the forthduino application > templates so far. (I wonder if we should really be calling it > forthduino1280, amforthduino, or amforthmegaduino or some such ??) > > There is a devices folder in there with the two device definition files. > I know they don't go there really. > > I put them there to get it all into an easy zip file to email. So they > need to come out and be put in the right place in the repository amongst > the core stuff. > > These are the current state of non working play. > > All tweaked to assemble with the release version of amforth using AVR > Studio 4.18 with no warnings or errors. > > Still no go on uart0 talking to us and doing interactive forth. > > Time to add some LED action I think. > > BTW, the amforth project docs that are on the front page of the web site > imply that the templates are used by copying them to \amforthxxx when > for the paths etc to work they need to be copied to \amforthxxx\core. > Again a little thing. Sorry. > > Cheers > > Andy Kirby > > PS the zip file minus the device definitions is a starter contribution > for the forthduino amforth app template to go in to the appl folder with > the other templates > > > > > |
|
From: <an...@ki...> - 2010-05-21 11:16:47
|
Guys Please find attached the current copy of the forthduino application templates so far. (I wonder if we should really be calling it forthduino1280, amforthduino, or amforthmegaduino or some such ??) There is a devices folder in there with the two device definition files. I know they don't go there really. I put them there to get it all into an easy zip file to email. So they need to come out and be put in the right place in the repository amongst the core stuff. These are the current state of non working play. All tweaked to assemble with the release version of amforth using AVR Studio 4.18 with no warnings or errors. Still no go on uart0 talking to us and doing interactive forth. Time to add some LED action I think. BTW, the amforth project docs that are on the front page of the web site imply that the templates are used by copying them to \amforthxxx when for the paths etc to work they need to be copied to \amforthxxx\core. Again a little thing. Sorry. Cheers Andy Kirby PS the zip file minus the device definitions is a starter contribution for the forthduino amforth app template to go in to the appl folder with the other templates |
|
From: <an...@ki...> - 2010-05-21 09:16:03
|
Matthias Trute wrote: > > You defined the usart3 as your terminal IO port. Is that really really ok? > I had that kind of error more than often, stupid thing that. > Actually that was already in the templates I copied. But I corrected this for references to usart0 before sending the original email. Sorry that wouldn't have been clear. I guess USART3 is standard on some board or other that the template was drawn from ????? The usart flags (Assembling under avr studio 4.18) also needed to have the usart number in the mnemonic. THis looks to be a quirk of updated AVR Studio device defs. It does'nt seem very efficient to me but is'nt mine to choose. ; initial baud rate of terminal .equ BAUD = 9600 .equ USART_B_VALUE = (1<<TXEN0) | (1<<RXEN0) ;| (1<<RXCIE0) .equ USART_C_VALUE = (1<<UMSEL0)|(3<<UCSZ00) I will forward the updated templates & defs with all the tweaks etc as soon as I have something that is a step forward, ie it looks to be at least booting and responding. I did'nt think it worth sending a copy of them after every trial. Cheers |
|
From: <an...@ki...> - 2010-05-21 09:05:40
|
OK on the notes below. Matthias Trute wrote: > Andy, > >> Compilation is fine except for a single warning:- >> >> C:\Documents and >> settings\andy\Desktop\forthduino_3.8\core\devices/atmega1280.asm(192): >> warning: .cseg .db misalignment - padding zero byte >> > > Just add a space to your mcuname string. It's not crtical however. > >> At the moment I am considering the list below. >> fixed this. >> 1. I missed tweaking something in the code as it comes, Mathias >> suggested using polled serial comms instead of ISR's. Do I need to >> tweak something to make this so, or does it do it already? There may be >> no response from the serial link but the board may actually be running. >> > > I just reviewed the template application files. They use the > poll based words now. Maybe the commit diffs that can > be viewed at > > http://amforth.svn.sourceforge.net/viewvc/amforth?view=rev&revision=860 > > are helpful as well. > Ah so, the interupt flag was'nt commented out in my template. Sorted now. >> 2. I have got something wrong with the fuses and addresses etc and the >> board just is'nt running. Programing all verifies etc and is done from >> AVR Studio, 4.18 with an AVR ISP Mk2. >> >> BOD, Disabled >> SPI, Enabled >> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000) >> Full swing osc , slow rise time with max delays >> > > That is probably wrong. Just set the fuses to the factory defaults _and_ > change the osc settings _only_ . The boot fuses are not relevant here. > sorted I assume though that >> Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000) is correct though, or is it ?? >> 3. I have got something wrong with the hardware defs or the tweaks to >> the app asm file and the code just is'nt running, crashed. >> > > You defined the usart3 as your terminal IO port. Is that really really ok? > I had that kind of error more than often, stupid thing that. > >> To help with the debugging, I need to turn on the debugging LED that is >> connected to port B7. >> >> Where and how is best to place the code? >> > > An LED is not that useful. Place a piezo there instead. Than you > can hear the controller working. The LED may only dim. A piezo would work, the board already has an LED though (All Arduino Megas do) and no piezo, once I have a pin toggling I usually hook up my oscilloscope so I can see what is happening and do some easy timing calculations etc. On the Arduino Mega the debug LED's port is also brought out to an external connector. This makes life real easy. > > I usually use the pause word to toggle the IO port, than I can hear > that the controller does nothing but waiting for a keystroke. Another > place would be the DO_NEXT label, but here you may need to > put an count down as well since the inner interpreter is called > very often (ultra sonic frequencies usually). > > Hmm a scope it is then, my hearing is very poor in the ultrasonic <|;) >> Whilst ultimately blinking would be nice for now I am happy with turn >> the LED on. >> >> I am not really looking for someone to do this for me here, just point >> me in the right Amforth compatible direction. >> > > There is no such "amforth compatible direction" thing at all. That's reassuring to know. I think I want to keep this to the templates and board specific bits though. Rather than mess with the code that is common to all. > > Good luck > Matthias > > ------------------------------------------------------------------------------ > > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > I will probably need it, of to play some more. Thanks for the quick response, and guidance, much appreciated. Hopefully disabling the UART interrupt flag and the above will be enough. Cheers |
|
From: Matthias T. <mt...@we...> - 2010-05-20 18:58:50
|
Andy, > Compilation is fine except for a single warning:- > > C:\Documents and > settings\andy\Desktop\forthduino_3.8\core\devices/atmega1280.asm(192): > warning: .cseg .db misalignment - padding zero byte > Just add a space to your mcuname string. It's not crtical however. > At the moment I am considering the list below. > > 1. I missed tweaking something in the code as it comes, Mathias > suggested using polled serial comms instead of ISR's. Do I need to > tweak something to make this so, or does it do it already? There may be > no response from the serial link but the board may actually be running. > I just reviewed the template application files. They use the poll based words now. Maybe the commit diffs that can be viewed at http://amforth.svn.sourceforge.net/viewvc/amforth?view=rev&revision=860 are helpful as well. > 2. I have got something wrong with the fuses and addresses etc and the > board just is'nt running. Programing all verifies etc and is done from > AVR Studio, 4.18 with an AVR ISP Mk2. > > BOD, Disabled > SPI, Enabled > Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000) > Full swing osc , slow rise time with max delays > That is probably wrong. Just set the fuses to the factory defaults _and_ change the osc settings _only_ . The boot fuses are not relevant here. > > 3. I have got something wrong with the hardware defs or the tweaks to > the app asm file and the code just is'nt running, crashed. > You defined the usart3 as your terminal IO port. Is that really really ok? I had that kind of error more than often, stupid thing that. > > To help with the debugging, I need to turn on the debugging LED that is > connected to port B7. > > Where and how is best to place the code? > An LED is not that useful. Place a piezo there instead. Than you can hear the controller working. The LED may only dim. I usually use the pause word to toggle the IO port, than I can hear that the controller does nothing but waiting for a keystroke. Another place would be the DO_NEXT label, but here you may need to put an count down as well since the inner interpreter is called very often (ultra sonic frequencies usually). > Whilst ultimately blinking would be nice for now I am happy with turn > the LED on. > > I am not really looking for someone to do this for me here, just point > me in the right Amforth compatible direction. > There is no such "amforth compatible direction" thing at all. Good luck Matthias |
|
From: <an...@ki...> - 2010-05-20 11:46:53
|
Guys I have compiled and downloaded the image for the amforth core as it comes, using a hand tweaked set of device defs. But cant get a squeak out of the board. (atmega1280, on an arduino mega clone) Compilation is fine except for a single warning:- C:\Documents and settings\andy\Desktop\forthduino_3.8\core\devices/atmega1280.asm(192): warning: .cseg .db misalignment - padding zero byte ATmega1280 memory use summary [bytes]: Segment Begin End Code Data Used Size Use% --------------------------------------------------------------- [.cseg] 0x000000 0x01e7e0 1904 5908 7812 131072 6.0% [.dseg] 0x000200 0x000200 0 0 0 8192 0.0% [.eseg] 0x000000 0x000040 0 64 64 4096 1.6% Assembly complete, 0 errors. 1 warnings At the moment I am considering the list below. 1. I missed tweaking something in the code as it comes, Mathias suggested using polled serial comms instead of ISR's. Do I need to tweak something to make this so, or does it do it already? There may be no response from the serial link but the board may actually be running. 2. I have got something wrong with the fuses and addresses etc and the board just is'nt running. Programing all verifies etc and is done from AVR Studio, 4.18 with an AVR ISP Mk2. BOD, Disabled SPI, Enabled Boot Flash 4k, start $F000 (to match .equ max_dict_addr = $F000) Full swing osc , slow rise time with max delays 3. I have got something wrong with the hardware defs or the tweaks to the app asm file and the code just is'nt running, crashed. To help with the debugging, I need to turn on the debugging LED that is connected to port B7. Where and how is best to place the code? Where: as in it will run at boot and turn on the LED showing something is live. Where it can stay once I have completed and become part of the templates in the distribution. (not somewhere it will interfere with someone else's implementation of a 1280 based non arduino board, will blink it rather than leave it on eventualy) How: as in, just in line assembler at the indicated spot, or do something that approaches the assembler approximation of forth. 40 DDRB c! 40 PORTB c! Whilst ultimately blinking would be nice for now I am happy with turn the LED on. I am not really looking for someone to do this for me here, just point me in the right Amforth compatible direction. All input and advice welcome. Cheers Andy Kirby |
|
From: <an...@ki...> - 2010-05-20 09:14:45
|
Michael That would be great. It may (or may not) be useful to take a peak at the ICSP programming code for the arduino. It can be found in the example code for V18 of the arduino IDE and is called ArduinoISP. This emulates the AVR ISP I think using the STK protocol. Certainly there is a whole bunch that can be trimmed out for a more simple clone function ie the STK protocol and a whole bunch of the host comms code. It is written in C and I am certainly not suggesting doing similar. It would be useful though to pull apart and understand the programming algorithms and bit banging etc though. An optionally overridden check of the device ID's could be used to ensure that a successful clone is possible. I was sugesting overridden because Atmel do have a habit of bringing out new variants of their processors that are directly compatible but have a different device ID. I am thinking of the "p" or low power variants here. ie the 644 and 644p are 100% compatible code wise from 644 => 644p. If you already had a bunch of this covered, sorry. Not knowing I thought it better to contribute just in case it was of some use. Cheers Andy Kirby PS off to play some more with getting amforth onto an Arduino Mega (ATMega1280). I have got it assembling and loading but does not yet run. Kalus Michael wrote: > HI. > > Am 19.05.2010 um 15:01 schrieb an...@ki...: > .. >> There is perhaps a missed oportunity >> to implement something like a "clone" word that will allow an amforth >> installation to clone itself (via ICSP) to an identical but empty >> atmel >> device. > > Yes, a clone word should be there in amforth. I'll think about it. > > Michael > > ------------------------------------------------------------------------------ > > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Kalus M. <mic...@on...> - 2010-05-19 21:31:54
|
HI. Am 19.05.2010 um 15:01 schrieb an...@ki...: .. > There is perhaps a missed oportunity > to implement something like a "clone" word that will allow an amforth > installation to clone itself (via ICSP) to an identical but empty > atmel > device. Yes, a clone word should be there in amforth. I'll think about it. Michael |
|
From: <an...@ki...> - 2010-05-19 13:01:35
|
Hurro Mathias & guys > I know that amforth is difficult to use for an absolute beginner. For > both langauge and hardware reasons. I myself had to spend a lot of > time until my first microcontroller program did run (no, it was not > amforth but a simple "hello world" that flashed a LED). The only > way around I see is that those people get a pre-programmed > chip / complete system. The arduino has it's success mainly > because of those pre-programmed hardware ready to use. > > Thinking that approach further: the amforth core system can > reside within 8KB flash, selecting an atmega with that boot sector > size would allow an "undestroyable" amforth system. No user > could overwrite the forth system at will or by mistake. Well, there > are still a few things more to do, but that would work. There is certainly some mileage in this. I could see it working and giving new users a quick in. The undestroyable idea has its merits. I am thinking back a little here to an English company that produced Forth based microcontrolers TDS2020 back before flash was really available. Tiny EEPROM's or battery backed sram were as good as it got. The company was called TDS I think. Their system used Eproms and battery backed sram. So was along those lines. (I still have the manuals, but seem to have lost the boards etc.) On getting forth onto virgin chips. There is perhaps a missed oportunity to implement something like a "clone" word that will allow an amforth installation to clone itself (via ICSP) to an identical but empty atmel device. If an arduino can be used as an stk500 programmer purely from code to program a blank atmel microcontroler with a bootloader the clone should be as easily doable. Perhaps easier as it would only clone to an identical device. Sure it is limited to only cloning to identical devices but it would give folk teaching classes a way to do forth only and bypass the fuss of the toolchain. Students could breadboard up an empty forth system and clone the core from the tutors example system or from each others. The students could then take away their devices, as a ready to go device they could use at home on their own breadboard, pcb or breadboard. cheers Andy Kirby |
|
From: <an...@ki...> - 2010-05-19 09:21:11
|
Guys Bit of a dum bunch of questions, but I have got to ask them, sorry. Just attempting a build of amforth 3.8 under windows and avrstudio 4.12. I have followed the guideance of the user guide and copied my template files into the folder \amforth3.8. Then followed the guidance of the amforth FAQ for building under windows. I get a number of errors which in summary amount to the template needs tweaking so that the paths to the amforth initial includes need prefxing with /core. The build then has dificulties with the rest fo the sub includes that the amforth includes reference. I am happy to tweak and hack these but looking at the amount of work you guys have gone to to set this up to build easily in the first instance. I can't help but think you probably intended it all to work a different way and I have missed something. (Like building from the wrong folder ???) Just before I leap in and tweak every path to fix the build errors, can I have some advice ?? Cheers Andy Kirby |
|
From: <an...@ki...> - 2010-05-16 15:59:56
|
Just some thoughts.... Is it worth considering creating (only for each full release) a set of binaries that are ready to program. But only for a specifically small set of designated off the shelf boards and perhaps a single (Amforth Project specific) published DIY design. It is neither desirable nor possible to turn out images for every variant and potential application. I guess the aim here is to be able to give a would be Amforth newbie the ability to get something up to play with very quickly that could reinforce their interest and give them incentive to want to do more. By buying in off the shelf or making their own starter Amforth system (breadboard, strip-board or home made single sided PCB) and programming on the image/s. The tool-chain and compilation is of course really necessary when you know what you are wanting to achieve, how you will be doing it and what you will be doing. Both in terms of hardware and forth words. I think there is no doubt about this. Tailoring your end product/project is always going to be the best way forwards. The objective of the suggestion is to make the first tentative steps easy. What boards are chosen and what is in the binary images in terms of words, is a discussion to have if the suggestion proves to be popular... Being able to experiment using inexpensive off the shelf boards without having to run up and get to grips with a full tool-chain, could be inviting to some. Thoughts for what they are worth.. Cheers Andy Kirby |
|
From: Matthias T. <mt...@we...> - 2010-05-13 18:30:36
|
Hi Andy, > Looking at the quote below. > > Are we actually saying here that the top 64k is not accessible then on a > 128k device ?? > no no, the 128Kb are fully usable. No (further) restrictions are in place > That the memory is arranged in Amforth in words (ie 16 bit) ?? > It depends. The key to understand it is the concept of an address unit. One address unit provides atomic access to data. For RAM one address unit contains 1 byte. One flash address unit has 2bytes. Since amforth is a 16bit forth, there are 64K address units. That translates to 64KB RAM and 128KB Flash (separate address ranges, @ and i@ (and e@) have nothing in common). At that level there is no difference between any controller, that amforth supports. At the assembly level (where you put your hands into the dirty details) the flash has surprisingly both a 16bit and a 8bit access schema, that needs to be taken into account. And the bigger controllers need a different instruction to read the (whole) flash. The details are well hidden in the readflashcell and writeflashcell assembly macros. For the full details you'll definitly need to read the data sheets from Atmel. But I hope, that the at90can128 file is a good starting point for the atmega1281. > Or that it is paged and therefore takes a bit more time to access ?? > The flash pages are not exposed, they are used internally only. I may re-arrange the code to provide access to the pages in future releases, e.g. to implement a block device for flash that is not accessible otherwise (eg on the atmega256). The increased access time comes from the additional code needed to access the flash, but thats not that much. Only a few CPU cycles. still more confused? sorry, but be assured: the atmega128 has nothing that cannot be used with amforth and is not really slower than the smaller device types. Matthias |
|
From: <an...@ki...> - 2010-05-13 16:34:37
|
Looking at the quote below. Are we actually saying here that the top 64k is not accessible then on a 128k device ?? That the memory is arranged in Amforth in words (ie 16 bit) ?? Or that it is paged and therefore takes a bit more time to access ?? Sorry for being a bit dim..... Cheers Andy kirby Matthias Trute wrote: > [1] The 128KB flash are seen as 64KWords to fit into the 16bit address > range, and there are a few other instructions to use. And finally the big > atmegas are slightly slower when accessing the flash since they need > to execute more instructions. But thats all hidden inside a few macros. |
|
From: Matthias T. <mt...@we...> - 2010-05-13 12:39:25
|
Andy, > > What can I say, you are all stars. Thank you very much, but whats a star without the universe? ;=) amforth got most of it's features from user feedback (anything from within complaints and patches). > The one processor that was short for me was the 1280 (Arduino Mega) > which is pretty much a 640 but with 128k of memory instead of 64k. I am > just about to set too and have a go at compiling for the 1280 and will > mod the 640 file (I assume this is still the way to go, although the > headers claim that the files are auto generated) The files are generated with the pd2amforth utility, but edited afterwards, there is no complete toolchain to implement the files for a new controller type. The manual changes are mostly trivial however... > Questions. > > Who do I need to feedback difs changes tweaks etc to to get the final > 1280 dev files into the distribution (at some point) ?? Just send them to me directly. There is a patch tracker at the sourceforge project site as well, it will reach me either way.. > > Which variables do I need to tweak to increase the memory size?? (a > quick win hopefully, for my first attempts) You may use the at90can128 file as a starting point since it already has all the changes needed for the 128KB flash [1]. Another hint is: use the usart words with polling access. The interrupt driven IO may sometimes be very frustrating to get working. Then there should be only a very few addresses to check: Usart ports, RAM start/end NRWW start address. Anything else should be left unchanged. At least for the first try ;=) Matthias [1] The 128KB flash are seen as 64KWords to fit into the 16bit address range, and there are a few other instructions to use. And finally the big atmegas are slightly slower when accessing the flash since they need to execute more instructions. But thats all hidden inside a few macros. |
|
From: <an...@ki...> - 2010-05-12 17:05:00
|
Mathias & the Guys I have just been having a rummage through the latest release of Amforth and the wider support for Atmega processors is impressive. Particularly as they cover most of the Arduino variants sufficiently enough to use their hardware. What can I say, you are all stars. I have started a new thread over on the RepRap forums to discuss Amforth and Reprap specificaly. Hopefully some of the folk who were interested in forth last we discussed it will still be interested enough to look into the potential. The one processor that was short for me was the 1280 (Arduino Mega) which is pretty much a 640 but with 128k of memory instead of 64k. I am just about to set too and have a go at compiling for the 1280 and will mod the 640 file (I assume this is still the way to go, although the headers claim that the files are auto generated) Questions. Who do I need to feedback difs changes tweaks etc to to get the final 1280 dev files into the distribution (at some point) ?? Which variables do I need to tweak to increase the memory size?? (a quick win hopefully, for my first attempts) I have got a couple or Arduino Mega's (Cost effective Chinese clones) so can spare one to experiment with for this. Cheers Andy Kirby (aka47) |
|
From: D W. <dou...@ya...> - 2010-05-01 16:42:27
|
Greeting!
New user here, having trouble with recent versions.
It appears the amforth 3.1 is the last version that works on the ATmega128. I do not know if it applies only to my hardware or to the ATmega128 in general, can anyone comment?
I have an old Kanda STK300 development board and the associated AVR-ISP. I am using AVR-ISP version 5.1.0.
I think it has something to do with the ATmega128 having two usarts. Starting with version 3.2, the compilation error messages can be resolved by changing (for example on version 3,.2):
UDRIE to UDRIE0, [usart0.asm line 63]
FE, DOR, and PE to FE0, DOR0, and PE0, [usart0.asm line 121]
UDRIE to UDRIE0, [TX0.asm line 40]
but running the result gives no prompt.
I got the impression that it is something to do with the interrupts, but this area is outside my expertise, so I'm just guessing.
On version 3.1 down to 2.8, the code compiles with no errors and immediately displays the forth version number and prompt. Fuses and clock are the same in all cases.
Any hints or comments?
D
|
8 messages has been excluded from this view by a project administrator.
