From: Kalus M. <mic...@on...> - 2011-04-10 00:20:46
|
Hi Hannu. Am 09.04.2011 um 21:57 schrieb Hannu Vuolasaho: > > Hi Michael and rest of you! > > Thanks for kind answers. Those were very enlightning. I'll bring > these new questions up so that beginners like myself doesn't need > to ask them over again (if they can search archives) and maybe give > some ideas what to put also getting started document. I have > confidense that I can find the answers from examples and trying > things. Even one fool can ask more questions than hundred wise men > can answer, I hope you don't feel I'm abusing this list. You are welcome. >> Am 08.04.2011 um 06:41 schrieb Hannu Vuolasaho: >> >>> Q: Is somewhere simple LED blinker example? >>> A: saw examples directory and studying those programs. But the >>> workflow from forth code to standalone program is missing >> >> \ example: >> : main ( -- ) begin led-on 1000 ms led-off 1000 ms key? until ; >> ' main is turnkey > Just to make sure that I understood this correctly, we define main > word which has loop and executes led-on word, puts 1000 to stack, > waits one second turns led off waits and reads from serial port. > The key? word puts true if there is input. Exactly. Number base has to be decimal to wait about a second. The led-on and led-off words have to be defined earlier of course, depending on which port pin LED is. > Second line makes main executed with turnkey word which is like > autoexec.bat :) Yes. > I'm learning the language so I like to explain all code that I find > so I understand what I read. > >> 1. flash amforth into device >> 2. develop your forth code on the device. Since it is in flash, is >> permanent. >> 3. set turnkey, Since it is in eeprom its permanent too. >> 4. turn off power of device. Turn power on, it will run your >> application. > wow. It's like a Commorode 64 or picoBasic. (PIC chip with > interactive BASIC. Finnsh webpage only: www.picobasic.com) > Anyway instant usable computer :) > >> >> Step 2 can be very strenuous. amforth is very simple, it is for tiny >> devices. I use gforth or some other "big" forth systems to develop >> most of the forth code before it goes down the device and runs on >> amforth. Since amforth is standard forth, this works nice. You have >> to simulate features of the device. Fine tuning then is done >> interactive on the device itself. So its kind of iteration using >> gforth, test it in amforth on the device, continue this loop >> modifying code until it does the job. > > MARKER word seems to be good for this. Yes. That is its intended use. >> Usually it takes a lot of re-flashing amforth till everything is >> works well. > > During flash everything is resetted. First are lost the forth words > code and in EEPROM reset dictionary to them. So source file must be > on computer where it van be uploaded to system. Also using ASM > reguires reflashing. Re-flashing gives a clean forth again. You must upload forth source too then. I hope your Terminal does handle this. >> Common constructs are: >> : main ( -- ) begin ... key? until ; \ test for any key >> : main ( -- ) begin ." ." 1000 ms key? dup if drop key $03 = then >> until ; \ test ctrl-c > > OK. Now I don't understand. ." is for printing like ." Hello > world!" If I've understood correct. What does two ." ." in row? You are right, the phrase ." xyz" in a definition outputs the string "xyz" to Terminal. The second " right after z is the delimmiter of the string definition. So if want a string of 5 stars I code ." *****" and if I want 3 dots I do ." ..." and if I want one dot only it is ." ." you see. You may use hex 2E emit as well. > wait a second check for input duplicate TOS (Why? does IF consume > one?) and if is true drop TOS, retrive the character and read from > memory address 03 ? Shouldn't that be just 03 when equality is > tested and passed to until after then word. So My current > understanding says that the duplicated key? is consumed only during > until? Yes, UNTIL consumes a flag. IF consumes a flag too. So you need two of them. If a key has been entered, check if it is ctrl-c ($03). This check gives the flag for UNTIL, so we better drop the underlying true flag. If there was no key we have a false flag, IF consumes the duplicated key? flag, an the false flag is passed on to UNTIL, so we get another run in the loop. ... >> My opinion: Never use (highlevel) forth on a embedded device to serve >> an interrupt. Use the method that comes with the device. On atmega: >> place a jump to code fragment that will set a variable. If service >> may be slow, serve that variable in your forth task later. > > True that. I need to check exsamples and study more. Right now I > have questions in my mind. > 1) Which registers I can use with ASM without pushing and popping > them from stack. In asm code you may use all working registers named "temp" since amforth makes no use of them. Top of stack (TOS) is in the register pair named tosl and tosh. So you have access to TOS within register operations. > 2) How do I create variable so that for exsample ISR can increment > counter and I can use it in forth. There are two ways for this. First one is: Add your variable to the source of amforth, then flash it. Add your code file in ASM too that increments second, minute, hour by interupt. While interupt is working in background, you may fetch variable with forth - see example "time". time c@ gets the value stored at adr = hour on top of stack. time 1+ c@ gives you the minute. time 2 + c@ gives you the second. ; ( -- adr ) VE_TIME: .dw $ff04 .db "time" .dw VE_HEAD .set VE_HEAD = VE_TIME XT_TIME: .dw PFA_DOVARIABLE PFA_TIME: .dw heap .equ hour=heap .set heap = heap + 1 .equ minute=heap .set heap = heap + 1 .equ second=heap .set heap = heap + 1 The other way is to load the assembler.frt on top of amforth and code it there as a source file. > 3) How to add portions of ASM and specify words for it. Upload amforth-4.2/lib/assembler.frt (Lubos Pekny) to amforth. > ... > Last of my questions is there way to see how some word has been > defined? There is no comfortable SEE yet as far as I know. But you may inspect you code with a dump of flash memory : myword somecode ; ' myword 10 dump you may look up all the execution tokens (xt) in the *.lst file that was created by your assembler (AVRA?) when generating amforth. Or include SEEWORD to you source to see name of given execution token: ; : seeword xt>nfa icount $ff and itype ; ; ( xt -- ) ; R( -- ) ; type name of word. VE_SEEWORD: .dw $FF07 .db "seeword",0 .dw VE_HEAD .set VE_HEAD = VE_SEEWORD XT_SEEWORD: .dw DO_COLON PFA_SEEWORD: ; ( xt -- ) .dw XT_XT_TO_NFA .dw XT_ICOUNT .dw XT_DOLITERAL .dw $FF .dw XT_AND .dw XT_ITYPE .dw XT_EXIT Include SEEDEF to get name of word that a deferred definition is currently using. ; ( xt -- ) ; R( -- ) ; type name of deferd word in use. VE_SEEDEF: .dw $FF06 .db "seedef" .dw VE_HEAD .set VE_HEAD = VE_SEEDEF XT_SEEDEF: .dw DO_COLON PFA_SEEDEF: ; ( xt -- ) .dw XT_DEFERFETCH .dw XT_SEEWORD .dw XT_EXIT Try ' key seedef :-) > > And last I like to share this idea. in avr-libc documentation there > is a the simple demo project. It is interrupt driven and makes PWM. > I think it could be nice if the demo project in getting starte page > had first single task non-sleeping non interrupt version of the > project and then shoved how to make as much as possible same > project with interrupts. > > So far I think that amforth may become the default environment for > my 8-bit AVR toys because forth as language thinks more like I do > in principle. Learning curve is quite steep however since there are > so many words and many look much a like and forth's postfix is > sometimes hard to understand. > > But now I think I'll stop writing mail and start trying on that > dimmer what I know about forth. ATMega88 is the victim this time. > > Best regards, > Hannu Vuolasaho Success! Michael |