Menu
▾
▴
amforth-devel
|
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: 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-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: <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 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: 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: 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: 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-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: 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-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: 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: Matthias T. <mt...@we...> - 2010-05-25 18:27:07
|
Am 25.05.2010 16:43, schrieb an...@ki...: > 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. Great! > Could be a useful platform for developing Amforth for larger memory devices. > > I am surprised no one is selling these commercially yet. Well, amforth works on all the controller types you mention ;=) Maybe it's worth to deal with the un-destroyable amforth than. I'm looking forward to get my board at hand.. > A quick question, forget does not seem to be implemented, It was present in early versions but a few people with much more forth experience pursuaded me that it's a bad idea. And in fact, whith word lists it would be very hard to implement it properly. The already mentioned marker is much better in any respect. It's defined in one of the frt files, and it has postpone as a pre-requisite (in another frt file). Michael Kalus wrote (writes?) an forth_to_assembly converter named G4 (> http://www.forth-ev.de/repos/g4/ ), that may be useful as well, I'm sure you want to include some words into the initial flash files that are available as forth source only ;=) Another way to get an re-usable flash image is create a generic initial hex file, send a few forth source files afterwards to the controller and read back the flash and EEPROM from the controller, that way I prefer btw... Matthias |
|
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: <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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X