From: <ha...@hu...> - 2007-03-13 06:56:50
|
Hi Matthias, I have a forth and an amforth question: On the web page, it is descibed that ' mypause 'pause ! sets the pause hook to the word mypause. That works just fine from immediate mode, but not from within another word. How would I achieve the same thing from within another word? Also, on the home page under Bugs, "Using timer interrupt may cause strange effects." is mentioned. I would like to use a timer to refresh my multiplexed LED display, can you let me know what the "strange effects" are? I love amforth! Being able to iteratively develop on the AVR is so much fun! Thanks! Hans |
From: <ha...@hu...> - 2007-03-13 07:23:52
|
2007/3/13, Hans H=FCbner <ha...@hu...>: > On the web page, it is descibed that > > ' mypause 'pause ! > > sets the pause hook to the word mypause. That works just fine from > immediate mode, but not from within another word. How would I achieve > the same thing from within another word? I checked the ANS specification (http://www.taygeta.com/forth/dpans.htm) and found the answer myself, ['] in a word definition does what ' does in immediate mode, so my code now reads : start-display ( -- ) init-display 0 set-display ['] refresh-display 'pause ! ; -Hans |
From: <ha...@hu...> - 2007-03-13 17:52:12
|
2007/3/13, Matthias Trute <mt...@we...>: > Hans H=FCbner wrote: > > Also, on the home page under Bugs, "Using timer interrupt may cause > > strange effects." is mentioned. I would like to use a timer to > > refresh my multiplexed LED display, can you let me know what the > > "strange effects" are? > > If the frequency is too high (say 100Hz on a 16MHz controller) the > controller stops responding. And regardless of the frequency you are not > able to use the flash write operation i! and all words using it. I have > no idea why it happens... For fun, I have connected a four digit 7 segment display to my ATMEGA32 running at 16 Mhz. The display is multiplexed in two pairs, so I need to refresh fast enough to get a stable display. To do so, I use TIMER0 with the overflow interrupt mapped to vector three. I prescale the timer by 256, thus my interrupt handler is called at about 240 Hz. It just works. Also, I have observed no anomalies working in immediate mode while my display refresh was active, so I could still compile works. What a gas! Great stuff :) -Hans If anyone's interested: I had to patch devices/atmega32.asm: .org=09OVF0addr ; Overflow0 Interrupt Vector Address rjmp int3_isr \ Ansteuerung der vierstelligen 7-Segment-Anzeige \ Port A =3D> 1. und 3. Stelle \ Port B =3D> 2. und 4. Stelle \ Port C =3D> Bit 0: 1. und 2. Stelle ausw=E4hlen \ Bit 1: 3. und 4. Stelle ausw=E4hlen \ Bit 1 und 3 d=FCrfen nicht gleichzeitig auf 1 gesetzt werden! decimal \ Tabelle f=FCr die Umsetzung von Ziffern in Bits f=FCr die 7-Segment-Anzei= ge create 7seg-digit-map 63 invert , 6 invert , 91 invert , 79 invert , 102 invert , 109 invert , 125 invert , 7 invert , 127 invert , 111 invert , \ Umrechnen einer Ziffer in Bits f=FCr die 7-Segment-Anzeige : 7seg-digit ( n -- m ) 7seg-digit-map 1+ + i@ ; \ Variable f=FCr die aktuell angezeigten Display-Bits 0 variable display 3 allot \ Eine Zahl ins Display-Register schreiben : set-display ( n -- ) 4 0 do 10 /mod loop drop 7seg-digit display 3 + c! 7seg-digit display 2 + c! 7seg-digit display 1 + c! 7seg-digit display c! ; \ Initialisieren der Schnittstelle zum Display : init-display \ Erst mal die Bits so einstellen, da=DF alle LEDs aus sind 255 PORTA c! 255 PORTB c! 0 PORTC c! \ Jetzt die Datenrichtungsregister setzen, so da=DF die entsprechenden Bits alle \ als Ausgang konfiguriert sind. 255 DDRA c! 255 DDRB c! 7 DDRC c! ; \ Aktuell aktive Display-H=E4lfte 0 variable field \ Wechseln der Display-H=E4lfte und anzeigen der passenden Ziffern. Jedes \ Mal, wenn das Wort refresh-display aufgerufen wird, wird wird das Display \ umgeschaltet. Wenn man refresh-display schnell genug hintereinander aufr= uft, \ ergibt sich ein stehendes Bild. : refresh-display ( -- ) 0 PORTC c! field c@ dup if display c@ PORTA c! display 1 + c@ PORTB c! 2 PORTC c! else display 2 + c@ PORTA c! display 3 + c@ PORTB c! 1 PORTC c! then not field c! ; \ Demo f=FCr refresh-display : refresh-display-demo ( -- ) begin refresh-display 1ms key? until key drop ; \ Anzeige aller vier Ziffern im Hintergrund. Die Umschaltung erfolgt \ durch den Timer-Interrupt. : start-display ( -- ) init-display 0 set-display ['] refresh-display 3 intvector ! \ Timer clock =3D> sysclk / 256 4 TCCR0 c! \ Timer0 einschalten 1 TIMSK c! ; : count ( -- ) 10000 0 do i set-display 1ms loop ; |
From: <ha...@hu...> - 2007-03-13 19:55:10
|
Am 13.03.07 schrieb Hans H=FCbner <ha...@hu...>: > For fun, I have connected a four digit 7 segment display to my > ATMEGA32 running at 16 Mhz. The display is multiplexed in two pairs, > so I need to refresh fast enough to get a stable display. To do so, I > use TIMER0 with the overflow interrupt mapped to vector three. I > prescale the timer by 256, thus my interrupt handler is called at > about 240 Hz. It just works. Also, I have observed no anomalies > working in immediate mode while my display refresh was active, so I > could still compile works. What a gas! Great stuff :) Just an observation: While compiling, the display flickers. It seems that IRQs are being disabled during flash programming, which is a good thing. Other than that, the timer driven refresh code has now been running for several hours without a hitch. -Hans |
From: Matthias T. <mt...@we...> - 2007-03-13 20:07:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Hans, Hans H=FCbner schrieb: > Am 13.03.07 schrieb Hans H=FCbner <ha...@hu...>: >> For fun, I have connected a four digit 7 segment display to my >> ATMEGA32 running at 16 Mhz. The display is multiplexed in two pairs, >> so I need to refresh fast enough to get a stable display. To do so, I >> use TIMER0 with the overflow interrupt mapped to vector three. I >> prescale the timer by 256, thus my interrupt handler is called at >> about 240 Hz. It just works. Also, I have observed no anomalies >> working in immediate mode while my display refresh was active, so I >> could still compile works. What a gas! Great stuff :) >=20 > Just an observation: While compiling, the display flickers. It seems > that IRQs are being disabled during flash programming, which is a good > thing. This is really a good news. In my tests the controller always freezes when the flash gets written. I should re-do the tests... Thanks+Bye Matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF9wR5Lo3irIddFw4RAn0AAJ4n9ysiK35Hr5tRC3/lanaG05PRRwCZAX6E PDMTYIEDg/N43uA/0bI2Cnc=3D =3DJSRh -----END PGP SIGNATURE----- |