Menu
▾
▴
amforth-devel
|
From: Al W. <al....@aw...> - 2010-09-15 19:30:55
|
I saw amforth and popped it on an ATMega 8. Works but very little code space. So I dug up an ATmega 16 (you can mark it as working on the matrix -- it does). However, I want to be able to use Marker. I have uploaded the definiton several different ways including the python shell (which appears not to handle backspace well in interactive mode, by the way). It seems to work, but after you execute it (example: marker blah) the system will say OK but any input will hang the system when you hit enter. The other issue I had was trying to use the 16's internal RC clock. It would work until you wrote to flash (colon definition) and then it would also die with no recourse but to reflash. With a 10MHz resonator (and the right fuses) it works fine. Maybe my OSCCAL was too far off for 8MHz (I didn't load the 8MHz OSCAL but the default 1MHz one was pretty close). So as it stands now I must use a crystal or resonator and whatever I put in as colon defintions are pretty much forever because there is no forget (I understand why) or marker. Oh, and it took me awhile to figure out that avra was no longer supported :-( Any ideas on getting marker to work? Great work, by the way. Really a fun piece of software. |
|
From: Erich W. <ew....@na...> - 2010-09-15 19:44:03
|
Hi and welcome, on 09/15/2010 09:24 PM, Al Williams wrote: > I saw amforth and popped it on an ATMega 8. Works but very little code space. > So I dug up an ATmega 16 (you can mark it as working on the matrix -- it > does). > > However, I want to be able to use Marker. I have uploaded the definiton several > different ways including the python shell (which appears not to handle > backspace well in interactive mode, by the way). It seems to work, but after > you execute it (example: marker blah) the system will say OK but any input > will hang the system when you hit enter. This issue is currently being worked on. Version 3.8 works for me (mostly using atmega32). > The other issue I had was trying to use the 16's internal RC clock. It would > work until you wrote to flash (colon definition) and then it would also die with > no recourse but to reflash. With a 10MHz resonator (and the right fuses) it > works fine. Maybe my OSCCAL was too far off for 8MHz (I didn't load the 8MHz > OSCAL but the default 1MHz one was pretty close). It could be, that it has nothing to do with the resonator, but with colon breaking the dictionary. > > So as it stands now I must use a crystal or resonator and whatever I put in as > colon defintions are pretty much forever because there is no forget (I > understand why) or marker. > > Oh, and it took me awhile to figure out that avra was no longer supported :-( avra is currently being worked on again, so it might work again in the near future. > > Any ideas on getting marker to work? > > Great work, by the way. Really a fun piece of software. Cheers, Erich |
|
From: Marcin C. <sa...@sa...> - 2010-09-15 19:51:52
|
On Wed, 15 Sep 2010, Erich Waelde wrote:
>
> avra is currently being worked on again, so it might work again in the near future.
>
It works if you apply my three patches (and remove unsupported .overlap / .nooverlap
for now).
Links for patches:
3044547 Error:: ldi can only use a high register (r16 - r31)
https://sourceforge.net/tracker/?func=detail&aid=3044547&group_id=55499&atid=477233
3044545 movw y, z causes Error:: No register associated with y and z
https://sourceforge.net/tracker/?func=detail&aid=3044545&group_id=55499&atid=477233
3044541 .ifndef does not work (Can't redefine constant, use .SET)
https://sourceforge.net/tracker/?func=detail&aid=3044541&group_id=55499&atid=477233
Let me know if you have any trouble (can be on avra list too).
--Marcin
|
|
From: Al W. <al....@aw...> - 2010-09-15 20:06:32
|
Excellent! Reverting to 3.8 did the trick. Thanks for the quick response. > > > The other issue I had was trying to use the 16's internal RC clock. It > > would work until you wrote to flash (colon definition) and then it would > > also die with no recourse but to reflash. With a 10MHz resonator (and > > the right fuses) it works fine. Maybe my OSCCAL was too far off for 8MHz > > (I didn't load the 8MHz OSCAL but the default 1MHz one was pretty > > close). > > It could be, that it has nothing to do with the resonator, but with colon > breaking the dictionary. Well it all works (except for marker) with a 10MHz resonator. I can create colon defintions as much as I want -- I just can't get rid of them. But with the internal clock any colon definition and you are done for. I suspect it is the timing of the flash write. |
|
From: Kalus M. <mic...@on...> - 2010-09-15 21:59:37
|
Hi.
Am 15.09.2010 um 21:24 schrieb Al Williams:
..
> Any ideas on getting marker to work?
maybe this version works. It copies the _entire_ system vector to
flash, and pops it back when executing the marker word.
: pushee ( -- ) dp , here , edp , edp 8 do i e@ , 2 +loop ;
: popee ( adr n -- ) 0 do dup i + i@ i 2* 2 + e! loop drop ;
: marker ( -- )
edp >r dp >r
pushee create r> , r> ,
does> >r r@ i@ r> 1+ i@ popee ;
I append marker.asm, include it in your application words if you like.
BUT since it was written for amforth-3.6 on atmega168 you have to do
the changes mentioned in the file. (pushee has been called ,ee there.)
Michael
|
|
From: Marcin C. <sa...@sa...> - 2010-09-15 22:16:01
|
Al Williams <al....@aw...> wrote: > I saw amforth and popped it on an ATMega 8. Works but very little code space. > So I dug up an ATmega 16 (you can mark it as working on the matrix -- it > does). > > However, I want to be able to use Marker. I have uploaded the definiton several > different ways including the python shell (which appears not to handle > backspace well in interactive mode, by the way). It seems to work, but after > you execute it (example: marker blah) the system will say OK but any input > will hang the system when you hit enter. I have reproduced this error and dumped 6 images of flash and eeprom at the different stages: http://saper.info/hg/forth/2010-sep-marker-problem/ You can fetch all the files using Mercurial (http://mercurial.seleni.com) with: hg clone http://saper.info/hg/forth/2010-sep-marker-problem/ There is something strange when portion of flash memory gets erased for the new word. --Marcin |
|
From: Al W. <al....@aw...> - 2010-09-15 22:21:17
|
One of my many hats is that I am a "blogger" for the venerable Dr. Dobb's Journal (I used to do columns for their magazines, but blogging is hipper ;) ). I wrote about my experiences with Amforth: http://www.drdobbs.com/blog/archives/2010/09/forth_love_if_h.html I am very impressed with it, although my original purpose might not be suitable. I was thinking of having inexpensive development boards for students. The problem is once you mess up the flash you have to reprogram. I was thinking long term it would be possible to either have a bootloader built in that would let you reflash a pristine system. Sort of a rescue mode. Maybe something I'll try when I ever get enough free time. Thanks again for all the replies. Al W. On Wednesday, September 15, 2010 17:15:33 pm Marcin Cieslak wrote: > Al Williams <al....@aw...> wrote: > > I saw amforth and popped it on an ATMega 8. Works but very little code > > space. So I dug up an ATmega 16 (you can mark it as working on the > > matrix -- it does). > > > > However, I want to be able to use Marker. I have uploaded the definiton > > several different ways including the python shell (which appears not to > > handle backspace well in interactive mode, by the way). It seems to > > work, but after you execute it (example: marker blah) the system will > > say OK but any input will hang the system when you hit enter. > > I have reproduced this error and dumped 6 images of flash > and eeprom at the different stages: > > http://saper.info/hg/forth/2010-sep-marker-problem/ > > You can fetch all the files using Mercurial (http://mercurial.seleni.com) > with: > > hg clone http://saper.info/hg/forth/2010-sep-marker-problem/ > > There is something strange when portion of flash memory gets erased for > the new word. > > --Marcin > > > --------------------------------------------------------------------------- > --- Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Kalus M. <mic...@on...> - 2010-09-15 23:31:37
|
Hi Al. .. > The problem is once you mess up the flash you have to reprogram. Adding a simple 'restoresystem on reset' helps allot. It just takes a copy of the original system vectors and puts them back into eeprom. As long as you did not overwrite amforth below DP by mistake this will work. Include your restoresystem word in the cold start routine cold.asm - here you find how it may be done: |
|
From: Marcin C. <sa...@sa...> - 2010-09-15 22:31:10
|
On Wed, 15 Sep 2010, Al Williams wrote: > One of my many hats is that I am a "blogger" for the venerable Dr. Dobb's > Journal (I used to do columns for their magazines, but blogging is hipper ;) > ). > > I wrote about my experiences with Amforth: > http://www.drdobbs.com/blog/archives/2010/09/forth_love_if_h.html > > I am very impressed with it, although my original purpose might not be > suitable. I was thinking of having inexpensive development boards for > students. The problem is once you mess up the flash you have to reprogram. I > was thinking long term it would be possible to either have a bootloader built > in that would let you reflash a pristine system. Sort of a rescue mode. > > Maybe something I'll try when I ever get enough free time. Amforth has a kind of bootloader built-in, since it constantly flashes new words defined. I am doing so-called in-line serial programming with two Arduinos (cheap AVR development board with USB - http://www.arduino.cc/) connected to each other. One runs the flasher (not yet in Forth, but soon!) and the other one is being flashed. I don't even have a programmer here. Actually we have a project with 4 AVRs connected to another one (a master) via the SPI interface, and we will probably try to test re-programming them on the fly via SPI (exciting possibility of a really self-replicating, self-deploying distributed programming). There is also possibility to flash the Arduino board completely in-line via the FTDI chip that is on-board there, but one needs to solder a small 4-pin header to the board and it's kind of slow, but works great in emergency. //Marcin |
|
From: Al W. <al....@aw...> - 2010-09-15 22:34:28
|
Right, I understand the i@ word constitutes a bootloader of sorts. But I was trying to get a way a student with no strange equipment could go back to a default state. I guess another way would be to drop a marker at the end of the default dictionary and have a config option that basically says "if the specified pin is low on boot up, drop back to that marker and erase everything" -- of course that could be bad too, but what I have in mind isn't critical at all. |
|
From: Al W. <al....@aw...> - 2010-09-15 22:49:54
|
I tried entering this as Forth code and got the same result. Not sure what changes you mean (since you define pushee and popee). Also, I don't think the list took your attachment. I presume this is broken because of the changes to here and dp recently. Anyway, for now I'm sticking with a hybrid 3.8 -- I did take some of the device and driver stuff out of 4.1 and got it working with 3.8. On Wednesday, September 15, 2010 16:59:25 pm Kalus Michael wrote: > Hi. > > > Am 15.09.2010 um 21:24 schrieb Al Williams: > .. > > > Any ideas on getting marker to work? > > maybe this version works. It copies the _entire_ system vector to > flash, and pops it back when executing the marker word. > > : pushee ( -- ) dp , here , edp , edp 8 do i e@ , 2 +loop ; > : popee ( adr n -- ) 0 do dup i + i@ i 2* 2 + e! loop drop ; > : marker ( -- ) > > edp >r dp >r > pushee create r> , r> , > does> >r r@ i@ r> 1+ i@ popee ; > > I append marker.asm, include it in your application words if you like. > BUT since it was written for amforth-3.6 on atmega168 you have to do > the changes mentioned in the file. (pushee has been called ,ee there.) > > Michael |
|
From: Marcin C. <sa...@sa...> - 2010-09-15 22:55:27
|
Al Williams <al....@aw...> wrote: > Right, I understand the i@ word constitutes a bootloader of sorts. But I was > trying to get a way a student with no strange equipment could go back to a > default state. I guess another way would be to drop a marker at the end of the > default dictionary and have a config option that basically says "if the > specified pin is low on boot up, drop back to that marker and erase everything" > -- of course that could be bad too, but what I have in mind isn't critical at > all. I did a presentation/workshop for the German hacking community two weeks ago: http://mrmcd1001b.metarheinmain.de/schedule/76/event/4008.en.html I plugged three Arduinos to my laptop running FreeBSD. There was a special workshop-jail (virtual instance) of the system configured with two users "box1" and "box2". You could log in to one of them and you immediately got a shared live terminal session. Both were displayed on a beamer screen during the workshop (FORTH looks cool in xterm with 24- or 36-point font). Third Arduino running boot software was ready with ICSP cables connected for a quick re-flashing if needed (proved not to be necessary as I didn't use "marker" :-) I was typing mostly on one, people hacking the other one, somebody tried to paste Forth "Hello world!" example from Wikipedia (and failed, since it was all-uppercase). Next time I will leave more time for hands-on hacking like this (it was targeted to a general tech public new to FORTH, 90% people knew C). By the way, the main point of the presentation was to demonstrate certain weaknesses of programming Harvard architecture machines in C (PROGMEM macro, string copying from flash to RAM to have unified pointers, linker tricks to fake unified address space, etc.). It is also not the FORTH favourite environment, but I find i@, e@ and friends a much more elegant solution to the problem. //Marcin |
|
From: Kalus M. <mic...@on...> - 2010-09-15 23:51:45
|
Hi Al. Seems the list does not take any attachments. Try these links: http://dl.dropbox.com/u/1170761/marker.asm http://dl.dropbox.com/u/1170761/savesystem.asm > I presume this is broken because of the changes to here and dp > recently. This is the old version I have on amforth3.6, may be its still good with 3.8 : : pushee ( -- ) here , heap , edp , edp 8 do i e@ , 2 +loop ; : popee ( adr n -- ) 0 do dup i + i@ i 2* 2 + e! loop drop ; : marker ( -- ) edp >r here >r pushee create r> , r> , does> >r r@ i@ r> 1+ i@ popee ; Michael Am 16.09.2010 um 00:49 schrieb Al Williams: > I tried entering this as Forth code and got the same result. Not > sure what > changes you mean (since you define pushee and popee). Also, I don't > think the > list took your attachment. > > I presume this is broken because of the changes to here and dp > recently. > Anyway, for now I'm sticking with a hybrid 3.8 -- I did take some > of the > device and driver stuff out of 4.1 and got it working with 3.8. > > > On Wednesday, September 15, 2010 16:59:25 pm Kalus Michael wrote: >> Hi. >> >> >> Am 15.09.2010 um 21:24 schrieb Al Williams: >> .. >> >>> Any ideas on getting marker to work? >> >> maybe this version works. It copies the _entire_ system vector to >> flash, and pops it back when executing the marker word. >> >> : pushee ( -- ) dp , here , edp , edp 8 do i e@ , 2 +loop ; >> : popee ( adr n -- ) 0 do dup i + i@ i 2* 2 + e! loop drop ; >> : marker ( -- ) >> >> edp >r dp >r >> pushee create r> , r> , >> does> >r r@ i@ r> 1+ i@ popee ; >> >> I append marker.asm, include it in your application words if you >> like. >> BUT since it was written for amforth-3.6 on atmega168 you have to do >> the changes mentioned in the file. (pushee has been called ,ee >> there.) >> >> Michael > > ---------------------------------------------------------------------- > -------- > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Al W. <al....@aw...> - 2010-09-16 02:51:31
|
Thanks Klaus, The marker.asm did NOT work on 4.1. I made the 3 changes plus I had to chnage EE_SYS0 to 2 (juding from the Forth code and noting a compile error or EE_SYS0). It did strike me as odd though that there were not 4 places to change. But I didn't get thought theh code enought to tell. I will look at the savesystem code. What would be ideal would be to configure a pin to boot into "restore mode" -- for example, since I am hooked up to USB for power, it could be configured to be the Rx line. Then a jumper could bring it low on boot (it would normally be high connected to the serial port) and trigger a restore. I'll try that soon. Thanks again for your help. On Wednesday, September 15, 2010 18:51:35 pm Kalus Michael wrote: > Hi Al. > > Seems the list does not take any attachments. > Try these links: > http://dl.dropbox.com/u/1170761/marker.asm > http://dl.dropbox.com/u/1170761/savesystem.asm > > > I presume this is broken because of the changes to here and dp > > recently. > > This is the old version I have on amforth3.6, may be its still good > > with 3.8 : > : pushee ( -- ) > > here , heap , edp , edp 8 do i e@ , 2 +loop ; > > : popee ( adr n -- ) > > 0 do dup i + i@ i 2* 2 + e! loop drop ; > > : marker ( -- ) > > edp >r here >r > pushee create r> , r> , > does> >r r@ i@ r> 1+ i@ popee ; > > Michael > > Am 16.09.2010 um 00:49 schrieb Al Williams: > > I tried entering this as Forth code and got the same result. Not > > sure what > > changes you mean (since you define pushee and popee). Also, I don't > > think the > > list took your attachment. > > > > I presume this is broken because of the changes to here and dp > > recently. > > Anyway, for now I'm sticking with a hybrid 3.8 -- I did take some > > of the > > device and driver stuff out of 4.1 and got it working with 3.8. > > > > On Wednesday, September 15, 2010 16:59:25 pm Kalus Michael wrote: > >> Hi. > >> > >> > >> Am 15.09.2010 um 21:24 schrieb Al Williams: > >> .. > >> > >>> Any ideas on getting marker to work? > >> > >> maybe this version works. It copies the _entire_ system vector to > >> flash, and pops it back when executing the marker word. > >> > >> : pushee ( -- ) dp , here , edp , edp 8 do i e@ , 2 +loop ; > >> : popee ( adr n -- ) 0 do dup i + i@ i 2* 2 + e! loop drop ; > >> : marker ( -- ) > >> : > >> edp >r dp >r > >> pushee create r> , r> , > >> does> >r r@ i@ r> 1+ i@ popee ; > >> > >> I append marker.asm, include it in your application words if you > >> like. > >> BUT since it was written for amforth-3.6 on atmega168 you have to do > >> the changes mentioned in the file. (pushee has been called ,ee > >> there.) > >> > >> Michael > > > > ---------------------------------------------------------------------- > > -------- > > Start uncovering the many advantages of virtual appliances > > and start using them to simplify application deployment and > > accelerate your shift to cloud computing. > > http://p.sf.net/sfu/novell-sfdev2dev > > _______________________________________________ > > Amforth-devel mailing list > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > --------------------------------------------------------------------------- > --- Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: pito <pi...@vo...> - 2010-09-16 08:30:22
|
Hi, interesting! After dozens of dozens of reflashings I downloaded the image of my flash and eeprom to investigate - after a few hours of work with amfort (4.0, 1284p) I saw a couple (~6)of random words written in eeprom's empty space as well as in flash'. So when you write a code which hangs it may write randomly. So my first thougt was to inhibit i! when not compiling word or not setting variable or constant as it is deffered. But it is not possible, only with fuses. So I did few words for XOR checksums (eexor, ffxor, which put the simple XOR sum of flash and eeprom into eeprom (2 cells). It works, and you may check the consistency of the system on boot fast (takes ~1sec to XOR 128kbytes @ 20MHz in amforth). However the sum changes each time you do a i!. Not easy to track. My idea was to check at boot time the XOR sum, when in error - to reflash the eeprom or flash from an image stored in an external spi flash (e.g cheap AT45DB041D 4mbit 8pin 66MHz). The idea was to write an actually valid image to the external flash when brown-out detected, maybe asm code could be fast enough to do it in few miliseconds until power drops. However, to use the amforth with students means to calculate with a lot of reflashes.. Pito ----- PŮVODNÍ ZPRÁVA ----- Od: "Kalus Michael" <mic...@on...> Komu: "Everything around amforth" <amf...@li...> Předmět: Re: [Amforth-devel] Marker etc. Datum: 16.9.2010 - 1:51:35 > Hi Al. > > Seems the list does not take any attachments. > Try these links: > http://dl.dropbox.com/u/1170761/marker.asm > http://dl.dropbox.com/u/1170761/savesystem.asm > > > I presume this is broken because of the changes > > to here and dp > > > recently. > > > This is the old version I have on amforth3.6, may > be its still good > with 3.8 : > : pushee ( -- ) > here , heap , edp , edp 8 do i e@ , 2 +loop ; > : popee ( adr n -- ) > 0 do dup i + i@ i 2* 2 + e! loop drop ; > : marker ( -- ) > edp >r here >r > pushee create r> , r> , > does> >r r@ i@ r> 1+ i@ popee ; > > Michael > > > Am 16.09.2010 um 00:49 schrieb Al Williams: > > > I tried entering this as Forth code and got the > > same result. Not > > > sure what > > changes you mean (since you define pushee and > > popee). Also, I don't > > > think the > > list took your attachment. > > > > I presume this is broken because of the changes > > to here and dp > > > recently. > > Anyway, for now I'm sticking with a hybrid 3.8 > > -- I did take some > > > of the > > device and driver stuff out of 4.1 and got it > > working with 3.8. > > > > > > > On Wednesday, September 15, 2010 16:59:25 pm > > Kalus Michael wrote: > > >> Hi. > >> > >> > >> Am 15.09.2010 um 21:24 schrieb Al Williams: > >> .. > >> > >>> Any ideas on getting marker to work? > >> > >> maybe this version works. It copies the > >> _entire_ system vector to > >> >> flash, and pops it back when executing the > >> marker word. > >> >> > >> : pushee ( -- ) dp , here , edp , edp 8 do i > >> e@ , 2 +loop ; > >> >> : popee ( adr n -- ) 0 do dup i + i@ i 2* 2 + > >> e! loop drop ; > >> >> : marker ( -- ) > >> > >> edp >r dp >r > >> pushee create r> , r> , > >> does> >r r@ i@ r> 1+ i@ popee ; > >> > >> I append marker.asm, include it in your > >> application words if you > >> >> like. > >> BUT since it was written for amforth-3.6 on > >> atmega168 you have to do > >> >> the changes mentioned in the file. (pushee has > >> been called ,ee > >> >> there.) > >> > >> Michael > > > > ---------------------------------------------------------------------- > > > > > > > -------- > > Start uncovering the many advantages of virtual > > appliances > > > and start using them to simplify application > > deployment and > > > accelerate your shift to cloud computing. > > http://p.sf.net/sfu/novell-sfdev2dev > > _______________________________________________ > > Amforth-devel mailing list > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > ------------------------------------------------------------------------------ > > Start uncovering the many advantages of virtual > appliances > and start using them to simplify application > deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Matthias T. <mt...@we...> - 2010-09-16 19:07:28
|
Al, > I saw amforth and popped it on an ATMega 8. Works but very little code space. Yeah, atmega8 is more a mee-too system. Not really usable any more. If you really want to use such little systems, you will have to go back in time and use versions around 1.x or so. > So I dug up an ATmega 16 (you can mark it as working on the matrix -- it > does). Ok, but it is already mentioned ;=) > > However, I want to be able to use Marker. It already worked, and does not currently. But it will do so again. But dont ask, when... > I have uploaded the definiton several > different ways including the python shell (which appears not to handle > backspace well in interactive mode, by the way). It seems to work, but after > you execute it (example: marker blah) the system will say OK but any input > will hang the system when you hit enter. Your complaints are welcome, but what could I do? Others complain that the scripts do not work at all due to <whatever>. I use the scripts on my systems and they work good enough. Maybe I intuitivly circumvent all the bugs and deficits already ;=) > So as it stands now I must use a crystal or resonator Most people who work with atmegas strongly recommend to use a quartz when it comes to serial communication (even at low speed such as 9600 characters per second). The internal oscillator works at 8MHz which is cut down to 1MHz and it is known to be very unstable. And again: marker is currently broken, sorry for that. But it will come back. Sooner or later. Matthias |
|
From: pito <pi...@vo...> - 2010-09-16 20:18:37
|
> Most people who work with atmegas strongly > recommend to use a quartz > when it comes to serial communication (even at low > speed such as 9600 > characters per second). The internal oscillator > works at 8MHz which is > cut down to 1MHz and it is known to be very > unstable. > Hi, some points I've gathered with serial i/o and terminals with amforth (I am using XP, usb connectivity, atmega32 @11.0592MHz, atmega1284p @25Mhz): 1. there are only 2 terminals which work reliable to me - Forfiter and Mosaic Serial Terminal, the later I am using now. 2. the speeds - I run Mosaic up to 256kbits - absolutely no problem 3. you CANNOT use terminals which do not commit "ok" or each character, amforth will not work - it will corrupt when writing new words !!!! Amforth needs a lot of time (sometimes fraction of seconds) in order to compile and flash the word - when not commiting 'ok' terminal will shoot characters to amforth and amforth will loose them!! therefore you must wait until ready again. There is none handshaking except this one! 4. amforth is very demanding as the baudrate precision is concerned, the 8n1 communication can have +/- 4.5% baudrate precision, but amforth will not compile with such spread. It means in practise unless you have so called any_baud crystals (e.g. 11.0592 etc.) you can compile only for specific speeds!!! 5. baudrate - you may change it in amforth session by: Num UBRR0L c! where Num is the baudrate_constant - you may see the atmega guide table 17.9-17.10 or you may calculate it for a given resonator or crystal (!! with known frequency!!). When reset the amforth reverts to default baudrate burned in. Finetuning: you may try to change the constant a little bit until the serial works reliable (do not forget to change the baudrate in terminal as well when you change to next baudrate step) 6. crystals, resonators, internal RC - you will not have any issues with standard crystals, but pls mind the 2 capacitors must have a specific value as well (15-22pf). Be carefull with higher frequences, crystals higher than 25MHz are so called overtone crystals, they oscillate on 1/3 of the frequency depicted on its body. Resonators easily have 10-20% deviation from depicted frequency, so it may not work with serial at given baudrate, however you may measure its frequency and adjust baudrate constant accordingly. The stability is good for serial. Internal RC - the chip makers claim up to 3% precision, so-so usable, but it is voltage (! the chip voltage - pls mind very good decoupling caps near the chip Vcc, Avcc) dependand so you may go out of baudrate easily as well when voltage fluctuates (mind BOD Brown-out Detector - when enabled (fuses!) a small drop in voltage causes an reset (2ns impuls can trigger it), also EEPROM and FLASH WRITE does not work properly when voltage fluctuates). You may measure the frequency on a pin, then udjust baudrate accordingly, or, some chips have internal udjustment (register value) for finetuning (+/- 10%) of the internal frequency. I would recommend internal oscillator up to 2400baud to be safe. 7. for amforth the finetuned serial communication with appropriate terminal supporting 'ok' commit is absolutely vital!! It flashes in its flash directly from serial, there are no large buffers (as far as I know) with checksums, so any instability means corruption of data. 8. From my other experience - electronics - the 97% of instabilities and corruptions in sw area comes from hardware issues - wrong capacitors, crystals, decoupling, voltage source instability, interference between PC and development board, grounding, unreliable sockets, connectors, cables too long, mobile phones laying near the testbed, statics, etc.etc.) Pito |
|
From: Al W. <al....@aw...> - 2010-09-16 20:48:10
|
> > Ok, but it is already mentioned ;=) > Whoops I see that. > Your complaints are welcome, but what could I do? Others complain that > the scripts do not work at all due to <whatever>. I use the scripts on > my systems and they work good enough. Maybe I intuitivly circumvent all > the bugs and deficits already ;=) > Please don't take anything as a complaint! I'm very impressed and I'm enjoying exploring. > > So as it stands now I must use a crystal or resonator > > Most people who work with atmegas strongly recommend to use a quartz > when it comes to serial communication (even at low speed such as 9600 > characters per second). The internal oscillator works at 8MHz which is > cut down to 1MHz and it is known to be very unstable. The default is 8 with an 8:1 prescaler, but you can pick 1:1 which I did. It all worked except for the write to flash. > > And again: marker is currently broken, sorry for that. But it will > come back. Sooner or later. I've reverted to an older version and hacked it up with some of the newer device stuff and it works great! Thanks. |
|
From: Al W. <al....@aw...> - 2010-09-16 21:40:47
|
Not sure why, but I tried running the 8MHz internal RC again and now its fine. Granted, before I was on the 4.1 and now I'm on 3.8 -- doubt that's the difference though. Probably operator error! |
|
From: Marcin C. <sa...@sa...> - 2010-09-16 21:47:07
|
Al Williams <al....@aw...> wrote: > Not sure why, but I tried running the 8MHz internal RC again and now its fine. > Granted, before I was on the 4.1 and now I'm on 3.8 -- doubt that's the > difference though. Probably operator error! There seems to be a bug in i@ introduced in 4.1 (see other postings). Can you try trunk now? //Marcin |
|
From: Al W. <al....@aw...> - 2010-09-17 00:06:50
|
Yes, grabbing the head and building for ATMEGA32 marker now works! Great! On Thursday, September 16, 2010 16:46:44 pm Marcin Cieslak wrote: > Al Williams <al....@aw...> wrote: > > Not sure why, but I tried running the 8MHz internal RC again and now its > > fine. Granted, before I was on the 4.1 and now I'm on 3.8 -- doubt > > that's the difference though. Probably operator error! > > There seems to be a bug in i@ introduced in 4.1 (see other postings). Can > you try trunk now? > > //Marcin > > > --------------------------------------------------------------------------- > --- Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
Thanks for helping keep SourceForge clean.
X