Matthias Trute <mtr...@web.de> writes:
Hello Matthias,
> Hi Enoch,
>
>>> Enochs code is a macro, assembling one single instruction SBI into
>>> dictionary and naming it.
>>> Calling that word will execute the SBI instruction.
>>>
>>> Michael
>>
>> I confirm, the code works.
>
> Well. I think its definitly worth some documentation. It is
> not obvious how to use it.
Easy:
Suppose we have a relay connected to PORTA.0
PORTA 0 port:hi! relay_on
PORTA 0 port:lo! relay_off
We can do the same of-course via bitnames.frt but the above is
accomplished through a single instruction.
BTW, bitnames.frt, IMO, needs to be simplifed in two respects:
1. It is extremely rare for a port to be of bidirectional use.
2. Port address can be limited to 0..255.
My own version follows:
----------------------------------------------------------------------
\ define a port: 0 ≤ portadr ≤ $FF, 0 ≤ bitno ≤ 7.
: port: create ( portadr bitno -- )
1 swap lshift \ make it a bitmask
>< or , \ mask at high byte
does> ( -- portmask portadr )
@i dup >< $ff and swap $ff and
;
: hi? ( portmask portadr -- f )
c@ and 0>
;
: lo? ( portmask portadr -- f )
c@ and 0=
;
synonym port@ hi?
: hi! ( portmask portadr -- )
dup >r c@ or r> c!
;
: lo! ( portmask portadr -- )
dup >r c@ swap invert and r> c!
;
: port! ( portmask portadr f -- )
if hi! else lo! then
;
: toggle ( portmask portadr -- )
over over lo? port!
;
\ PORTx.y is output
: out! ( portmask portadr -- )
1- hi!
;
\ PINx.y is input
: in! ( portmask portadr -- )
1+ lo!
;
----------------------------------------------------------------------
>> I suggest that these simple macros would become standard library
>> offerings.
>
> I'll think about it. see above ;)
>
>> Without these atomic bit set/clear one needs to wrap code by
>> -int/+int if register bits are shared by different interrupt
>> routines.
>
> Any given and active forth ISR is never interrupted itself by
> another interrupt. The communication between ISR and the
> main program is close but different (IMHO).
That's no good. Interrupt routines MUST BE interruptible or otherwise
they would introduce unacceptable latency. For example, suppose we are
doing some signal processing and we need to take A/D samples at regular
intervals... By the way, let the programmer worry about avoiding re-entrancy.
The docs gave me the impression that this is the case... i.e., until the
T flag is set the interrupt system is off but later we invoke the
interrupt service word just as usual...
I'll have to visit your asm code :-(
If the above is corrected the importance of those atomic
(uninterruptible) SBI/CBI instructions becomes clear.
Thanks, Enoch.
> Matthias
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
