amforth-devel — Development discussion and user support

[Amforth] Need another mailing list to submit patches?

[Enoch <ix...@ho...>]

Index: doc/source/refcard.rst
===================================================================
--- doc/source/refcard.rst	(revision 1375)
+++ doc/source/refcard.rst	(working copy)
@@ -724,8 +724,8 @@
   fetches XT from interrupt vector i
 
 * :command:`\-int`
-  ( -- sreg )
-  turns off all interrupts and leaves SREG in TOS
+  ( -- )
+  turns off all interrupts
 
 * :command:`\+int`
   ( --  )

Re: [Amforth] Useful?

[Matthias T. <mt...@we...>]

Hi,


> Your SBI/CBI macros are an excellent and inspiring solution for a
> particular problem. I think it really deserves to be published.
> As a recipe in the cookbook.

A rough first shot is online:
http://amforth.sourceforge.net/TG/recipes/Efficient-Bitmanipulation.html

It will get links and much more text. But not tonight..

Matthias

Re: [Amforth] Useful?

[Enoch <ix...@ho...>]

Hello Matthias,

Matthias Trute <mt...@we...> writes:

> Hi Enoch,
>
>> Well, let's try the following indirect argument:
>> 
>> Atmel thought these instructions to be important enough to "spend" 2^10
>> opcodes out of their precious 2^16 RISC range. Don't we need to respect
>> that engineering decision by suitable Amforth words?
>
> No, we don't. Sounds too harsh? Well, yes. Atmel did a lot of
> at least strange design decisions, that later (for the atxmega
> line) got changed. The IO area with 32 possible addresses was
> fine for the very first controllers, but became later a real
> bottleneck.

Personally, if my Flash memory requirements would go beyond 128KB (64KW)
I will choose a different µC architecture. 

>
>>> As Matthias pointed out elsewhere: your snippet is intersting,
>>> because assembly instructions are coded in at compile time
>>> without loading the full assembler. That I can see.
>> 
>> Yes, that DIY assembly approach can do things which lib/assembler.frt
>> may find difficult to follow :-)
>
> Your SBI/CBI macros are an excellent and inspiring solution for a
> particular problem. I think it really deserves to be published.
> As a recipe in the cookbook. There are quite a few solutions, that
> do not go into the repository and are worth studying. I do hope,
> you can live with that. It has the advantage to have documentation

I can certainly live with that :-) You are, as long as your contribution
stream is sustained, the "Guido van Rossum" of this project. I state
that as a fact, with true appreciation to your contribution.

My sense of programming aesthetics requires critical sections to be as
short as possible if not eliminated altogether. It's a result of a
seminar I took years ago on programming cooperating processes, based on
an E.W.Dijkstra paper.

In my current project Atmel has even given me a GPIOR0 (a general
purpose register) that I can apply SBI/CBI atomically to. Why should I
give it up?

> and implementation in one document. The code in the lib/ directory
> is not that well documented.

IMHO the asm code needs better docuemntation as a proirity as well. Your
move to reST makes it easier to contribute. I consider it a personal
obligation to help and hope that other Amforth users feel the same.

Keep up the good work!

Regards, Enoch.

>
> Matthias
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Development request

[Matthias T. <mt...@we...>]

Hi,


> MARKER is great for development, and I use it as well, but it is not
> good enough in production situation:
> 
> Let's say we are consultants and ship an Amforth based "blackbox" to a
> client whose firmware we loaded before shipping via JTAG. When this
> firmware needs a bug fix or an upgrade we must provide the client with a
> serial port based method of new firmware install (compiling/uploading
> new Forth) without the client having to open the box.

In which way would MARKER prohibit this scenario? A well designed
application with in-field replaceable application code (the amforth
core cannot be changed with WIPE btw) can place a strategic marker
label that does all you want to do. One may want to re-check if the
information, MARKER restores is sufficient, but that would be a bug
in MARKER.

> 4e4th is targetting educational applications. There too there's a need
> for rapid "factory reset" between one student application to the next
> one.

An "unbreakable" amforth is possible as well. I came across this years
ago but never really implemented it. It requires an atmega with an
NRWW section big enough to hold the whole amforth core system. Since the
NRWW section cannot be destroyd by amforth itself, there is only a copy
of the EEPROM needed and a trigger that reprograms the EEPROM at boot
time. Should be easy to implement.

Finally: I do understand WIPE and the goals that one may want to
achieve with it (IMHO its an alias for MARKER). But why on earth should
this (rather complex) tool be implemented in assembly language?

Matthias

Re: [Amforth] Useful?

[Matthias T. <mt...@we...>]

Hi Enoch,

> Well, let's try the following indirect argument:
> 
> Atmel thought these instructions to be important enough to "spend" 2^10
> opcodes out of their precious 2^16 RISC range. Don't we need to respect
> that engineering decision by suitable Amforth words?

No, we don't. Sounds too harsh? Well, yes. Atmel did a lot of
at least strange design decisions, that later (for the atxmega
line) got changed. The IO area with 32 possible addresses was
fine for the very first controllers, but became later a real
bottleneck.

>> As Matthias pointed out elsewhere: your snippet is intersting,
>> because assembly instructions are coded in at compile time
>> without loading the full assembler. That I can see.
> 
> Yes, that DIY assembly approach can do things which lib/assembler.frt
> may find difficult to follow :-)

Your SBI/CBI macros are an excellent and inspiring solution for a
particular problem. I think it really deserves to be published.
As a recipe in the cookbook. There are quite a few solutions, that
do not go into the repository and are worth studying. I do hope,
you can live with that. It has the advantage to have documentation
and implementation in one document. The code in the lib/ directory
is not that well documented.

Matthias

Re: [Amforth] Development request

[Michael K. <mi-...@t-...>]

Hi.


Am 20.02.2013 um 10:16 schrieb Enoch:

>> So, do I see this right?
>> WIPE restores a known state. This state needs to be calculated at
>> assembly time.

Yes.


>> It includes the initial state of eeprom, wordlist and
>> other pointers, user area, disabling tasks ... where do you stop?
>> Does wipe call COLD as well? Do you need to clear any interrupts,  
>> too?
>> Does it restore the default interrupt handlers? No, I did not look
>> at the code of WIPE.

WIPE is simple in 4e4th, since it it taylored for the MSP430G2553 on  
LaunchPad.
It just erases user flash and executes FACTORY then.
FACTORY moves a ROM tabel to RAM user area, clears variable area in  
RAM to zero, and does a SAVE on it so that 'factory settings' is the  
new app, and runs into ABORT.

There is no eeprom, and we do not have to take care of other MCUs.
Michael




>>
>>
>> Well, I'm using marker a lot. And I don't see, how wipe would get me
>> any further. The only time I need to reflash is when I screwed up
>> something in the dictionary before the first marker or som flash
>> based data structures.
>
> MARKER is great for development, and I use it as well, but it is not
> good enough in production situation:
>
> Let's say we are consultants and ship an Amforth based "blackbox" to a
> client whose firmware we loaded before shipping via JTAG. When this
> firmware needs a bug fix or an upgrade we must provide the client  
> with a
> serial port based method of new firmware install (compiling/uploading
> new Forth) without the client having to open the box.
>
> 4e4th is targetting educational applications. There too there's a need
> for rapid "factory reset" between one student application to the next
> one.

Exactly. This is what we had in mind.

And a recovery mechanism if a student gets locked in forth some how,  
has no terminal access any more, and reset does not help.
Press switch S2+reset to WIPE and start over.

But you have to chose 4e4thpro (pro for production) to strip S2  
booting capability and use that pin for apps too.

Michael


>
> Regards, Enoch.
>
>
>
>
>
>
>
>
>
>
>
>
>
>>
>> Cheers,
>> Erich
>>
>> --------------------------------------------------------------------- 
>> ---------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>
>
> ---------------------------------------------------------------------- 
> --------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Development request

[Michael K. <mi-...@t-...>]

Hi Enoch.


Am 20.02.2013 um 04:35 schrieb Enoch:
..
> Honored to meet you, the "4e4th" guy :-)

To tell the truth, most of 4e4th is Camelforth, so Brad deserves the  
honor.
Dirk Brühl is the guy with most of the ideas that brought it onto  
MSP430 LaunchPad.
And Ulrich Hoffmann contributed as well, such as caps and crc.
So I'm the code monkey.




>
> To become current with Forth I review code by other OSS Forth  
> projects.
> Another that deserves attention, IMHO, is the Open Firmware
> <http://wiki.laptop.org/go/Open_Firmware>.
>
> In any case, we here should focus on Forth code that utilizes Atmel's
> AVR special features and quirks. In this connection I patiently  
> wait for
> Matthias to recognize/decline my SBI/CBI utilization macros ;-)

I like it.

Regards, Michael


>
> Regards, Enoch.
>
>
>>
>>
>>
>>
>> Am 19.02.2013 um 22:36 schrieb Enoch:
>>
>>> G'day to you to you all,
>>>
>>> I found something that seems to me useful on http://www.4e4th.eu/
>>>
>>> WIPE ( -- )  Back to original status. Stacks unchanged. uarea  
>>> back to
>>> original.
>>>
>>> Having an asm based word which restores the system into its original
>>> Amforth state, both Flash & EEPROM content, means that on-site code
>>> replacement can be done without a JTAG, etc.
>>>
>>> Comments?
>>>
>>> Thank you, Enoch.
>>>
>>> P/S Marker is not good enough: It does not restore the EEPROM. It
>>> removes itself after application.
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> --------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_feb
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>>
>> --------------------------------------------------------------------- 
>> ---------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>
>
> ---------------------------------------------------------------------- 
> --------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Development request

[Enoch <ix...@ho...>]

Erich Waelde <ew....@na...> writes:

> Hi Enoch,
>
> On 02/19/2013 10:36 PM, Enoch wrote:
>> G'day to you to you all,
>> 
>> I found something that seems to me useful on http://www.4e4th.eu/
>> 
>> WIPE ( -- )  Back to original status. Stacks unchanged. uarea back to
>> original.
>> 
>> Having an asm based word which restores the system into its original
>> Amforth state, both Flash&  EEPROM content, means that on-site code
>> replacement can be done without a JTAG, etc.
>> 
>> Comments?
>
> "the original state" is what? So WIPE needs to store a copy of the
> first N eeprom Bytes elsewhere (done at assembly time) and then
> replace eeprom, user area and thus the stack pointers as well?
>> Stacks unchanged
> strikes me as odd.
>
>
>> 
>> Thank you, Enoch.
>> 
>> P/S Marker is not good enough: It does not restore the EEPROM. It
>> removes itself after application.
>
> Well marker does not remove itself. The defined word does. </nitpick>
>
> So, do I see this right?
> WIPE restores a known state. This state needs to be calculated at
> assembly time. It includes the initial state of eeprom, wordlist and
> other pointers, user area, disabling tasks ... where do you stop?
> Does wipe call COLD as well? Do you need to clear any interrupts, too?
> Does it restore the default interrupt handlers? No, I did not look
> at the code of WIPE.
>
>
> Well, I'm using marker a lot. And I don't see, how wipe would get me
> any further. The only time I need to reflash is when I screwed up
> something in the dictionary before the first marker or som flash
> based data structures.

MARKER is great for development, and I use it as well, but it is not
good enough in production situation:

Let's say we are consultants and ship an Amforth based "blackbox" to a
client whose firmware we loaded before shipping via JTAG. When this
firmware needs a bug fix or an upgrade we must provide the client with a
serial port based method of new firmware install (compiling/uploading
new Forth) without the client having to open the box.

4e4th is targetting educational applications. There too there's a need
for rapid "factory reset" between one student application to the next
one.

Regards, Enoch.













>
> Cheers,
> Erich
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Useful?

[Enoch <ix...@ho...>]

Erich Waelde <ew....@na...> writes:

> Hi Enoch,
>
> since you asked for comments ...

I certainly do!

> On 02/13/2013 05:38 AM, Enoch wrote:
>> Hello Matthias and all,
>> 
>> I'd like to see this forum also offering code snippets, so here's my
>> first humble attempt of harnessing the atomic bit manipulation
>> instructions.
>> 
>> : port:hi ( portadr bitno -- )	    \ SBI
>>      swap $20 - 3 lshift or $9A00 or code , end-code
>> ;
>> 
>> : port:lo ( portadr bitno -- )	    \ CBI
>>      swap $20 - 3 lshift or $9800 or code , end-code
>> ;
>> 
>> example:
>> 
>> PORTB 7 port:hi green.hi
>> PORTB 7 port:lo green.lo
>> 
>
> So you want to set or clear a bit in some register.
>
> What is wrong with the words found in bitnames.frt?
>
>   include lib/bitnames.frt
>   PORTB 7  portpin: green
>
> and later
>
>   green pin_output
>   green high
>   \ do something here
>   green low

SBI/CBI can change bits in the 0..31 I/O range without needing a -int /
+int protection. avr-gcc, for example, would use SBI when compiling
PORTA |= _BV(0);

> Sure, bitnames is doing read+modify+write on the memory mapped
> location of the register, while your solution uses sbi/cbi which
> does not work on the memory mapped location (hence $20 - ).
> But what exactly is better with using sbi/cbi? That sbi/cbi
> cannot be interrupted once the instruction is executing? But
> all the instructions leading up to the sbi/cbi can be
> interrupted, can't they? Do I miss the entire motivation of
> the code snippet? Would you dare to enlighten me??

Well, let's try the following indirect argument:

Atmel thought these instructions to be important enough to "spend" 2^10
opcodes out of their precious 2^16 RISC range. Don't we need to respect
that engineering decision by suitable Amforth words?

> As Matthias pointed out elsewhere: your snippet is intersting,
> because assembly instructions are coded in at compile time
> without loading the full assembler. That I can see.

Yes, that DIY assembly approach can do things which lib/assembler.frt
may find difficult to follow :-)

Regards, Enoch.

>
> Cheers,
> Erich
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Development request

[Erich W. <ew....@na...>]

Hi Enoch,

On 02/19/2013 10:36 PM, Enoch wrote:
> G'day to you to you all,
> 
> I found something that seems to me useful on http://www.4e4th.eu/
> 
> WIPE ( -- )  Back to original status. Stacks unchanged. uarea back to
> original.
> 
> Having an asm based word which restores the system into its original
> Amforth state, both Flash&  EEPROM content, means that on-site code
> replacement can be done without a JTAG, etc.
> 
> Comments?

"the original state" is what? So WIPE needs to store a copy of the
first N eeprom Bytes elsewhere (done at assembly time) and then
replace eeprom, user area and thus the stack pointers as well?
> Stacks unchanged
strikes me as odd.


> 
> Thank you, Enoch.
> 
> P/S Marker is not good enough: It does not restore the EEPROM. It
> removes itself after application.

Well marker does not remove itself. The defined word does. </nitpick>

So, do I see this right?
WIPE restores a known state. This state needs to be calculated at
assembly time. It includes the initial state of eeprom, wordlist and
other pointers, user area, disabling tasks ... where do you stop?
Does wipe call COLD as well? Do you need to clear any interrupts, too?
Does it restore the default interrupt handlers? No, I did not look
at the code of WIPE.


Well, I'm using marker a lot. And I don't see, how wipe would get me
any further. The only time I need to reflash is when I screwed up
something in the dictionary before the first marker or som flash
based data structures.

Cheers,
Erich

Re: [Amforth] Useful?

[Erich W. <ew....@na...>]

Hi Enoch,

since you asked for comments ...

On 02/13/2013 05:38 AM, Enoch wrote:
> Hello Matthias and all,
> 
> I'd like to see this forum also offering code snippets, so here's my
> first humble attempt of harnessing the atomic bit manipulation
> instructions.
> 
> : port:hi ( portadr bitno -- )	    \ SBI
>      swap $20 - 3 lshift or $9A00 or code , end-code
> ;
> 
> : port:lo ( portadr bitno -- )	    \ CBI
>      swap $20 - 3 lshift or $9800 or code , end-code
> ;
> 
> example:
> 
> PORTB 7 port:hi green.hi
> PORTB 7 port:lo green.lo
> 

So you want to set or clear a bit in some register.

What is wrong with the words found in bitnames.frt?

  include lib/bitnames.frt
  PORTB 7  portpin: green

and later

  green pin_output
  green high
  \ do something here
  green low

Sure, bitnames is doing read+modify+write on the memory mapped
location of the register, while your solution uses sbi/cbi which
does not work on the memory mapped location (hence $20 - ).
But what exactly is better with using sbi/cbi? That sbi/cbi
cannot be interrupted once the instruction is executing? But
all the instructions leading up to the sbi/cbi can be
interrupted, can't they? Do I miss the entire motivation of
the code snippet? Would you dare to enlighten me??


As Matthias pointed out elsewhere: your snippet is intersting,
because assembly instructions are coded in at compile time
without loading the full assembler. That I can see.

Cheers,
Erich

Re: [Amforth] Development request

[Enoch <ix...@ho...>]

"Michael Kalus" <mi-...@t-...>
writes:

> Hi.
>
>> Comments?
>
>
> :-)
>
>
>
> Michael
>

Honored to meet you, the "4e4th" guy :-) 

To become current with Forth I review code by other OSS Forth projects.
Another that deserves attention, IMHO, is the Open Firmware
<http://wiki.laptop.org/go/Open_Firmware>.

In any case, we here should focus on Forth code that utilizes Atmel's
AVR special features and quirks. In this connection I patiently wait for
Matthias to recognize/decline my SBI/CBI utilization macros ;-)

Regards, Enoch.


>
>
>
>
> Am 19.02.2013 um 22:36 schrieb Enoch:
>
>> G'day to you to you all,
>>
>> I found something that seems to me useful on http://www.4e4th.eu/
>>
>> WIPE ( -- )  Back to original status. Stacks unchanged. uarea back to
>> original.
>>
>> Having an asm based word which restores the system into its original
>> Amforth state, both Flash & EEPROM content, means that on-site code
>> replacement can be done without a JTAG, etc.
>>
>> Comments?
>>
>> Thank you, Enoch.
>>
>> P/S Marker is not good enough: It does not restore the EEPROM. It
>> removes itself after application.
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------- 
>> --------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Development request

[Michael K. <mi-...@t-...>]

Hi.

> Comments?


:-)



Michael





Am 19.02.2013 um 22:36 schrieb Enoch:

> G'day to you to you all,
>
> I found something that seems to me useful on http://www.4e4th.eu/
>
> WIPE ( -- )  Back to original status. Stacks unchanged. uarea back to
> original.
>
> Having an asm based word which restores the system into its original
> Amforth state, both Flash & EEPROM content, means that on-site code
> replacement can be done without a JTAG, etc.
>
> Comments?
>
> Thank you, Enoch.
>
> P/S Marker is not good enough: It does not restore the EEPROM. It
> removes itself after application.
>
>
>
>
>
> ---------------------------------------------------------------------- 
> --------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Development request

[Enoch <ix...@ho...>]

G'day to you to you all,

I found something that seems to me useful on http://www.4e4th.eu/

WIPE ( -- )  Back to original status. Stacks unchanged. uarea back to
original.

Having an asm based word which restores the system into its original
Amforth state, both Flash & EEPROM content, means that on-site code
replacement can be done without a JTAG, etc.

Comments?

Thank you, Enoch.

P/S Marker is not good enough: It does not restore the EEPROM. It
removes itself after application.

Re: [Amforth] int_restore, etc.

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

> Hi,
>
>> I like these "critical[" "]critical" words, much better than int_suspend
>> and int_restore, but I prefer their current asm code implementation
>> since one would like to keep the criticial code execution to the
>> minimum.
>
> A critical section frame is not particular speed sensitve.
> It simply turns off interrupts temporarily. A small
> forth implementation that one can understand is
> far more valuable.
>
> Code _within_ that critical section should be as small
> and fast as possible indeed. But again: maintainable
> forth code is of higher value than some cryptic assembler
> magic.. IMHO.
>
> Matthias

What matters is to keep the critical code section, where global
interrupts are turned off, as short as possible. If asm code would allow
the critical section be even 1µS shorter the asm code should stay :-)

I agree with your general philosophy of minimizing the number of low
level (asm) routines. For example, I recently took note of bm-set.asm,
bm-clr.asm and bm-toggle.asm... they don't follow this principle...

Regards, Enoch.


>
>
>
> ------------------------------------------------------------------------------
> 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/

Re: [Amforth] Code snippet

[Rafael G. <ast...@ya...>]

I have not tried it, but IMHO if the structures are in the code tree, they are tested for the AVR.
There are various comments rshowing the adaptation.
Of course, the FSM must be adapted, cannot be used verbatim.
I may try to adapt it.

Greetings
Rafael




________________________________
 De: Enoch <ix...@ho...>
Para: amf...@li... 
Enviado: Sábado 16 de febrero de 2013 19:55
Asunto: Re: [Amforth] Code snippet
 
Rafael Gonzalez <ast...@ya...> writes:

> Hi, If you want to do a variable jump vector table, that is fine
>
> If you jump vector table has a known size, you' may also use forth200x structures for field names.
> That is the approach of forths like VFX Forth for its I/O vectors (GENIO drivers)

Not sure if lib/forth200x/structures.frt is ready for Flash based
fields.  We should be mindful that the AVR implements Harvard
archtecture unlike our PC's von Neumann's.

>
>
> For something more sophisticated as Finite State Machines you may want to have a look at
> http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm2.htm
>
>
> Paper explaining it at
> http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html

For the above mentioned reason we rarely can copy code verbatim. Hence,
the need to create our own tried & tested library.

Thanks, Enoch.


> Greetings
> Rafael
>
>
>
> ________________________________
>  De: Enoch <ix...@ho...>
> Para: amf...@li... 
> Enviado: Sábado 16 de febrero de 2013 18:47
> Asunto: [Amforth] Code snippet
>  
> Hi,
>
> Excuse me folks, while I am a (very) experienced embedded programmer
> Forth for me is a new experience. So here's another joy discovery. The
> old Forth sage tell us to use decision tables rather than case and
> nested if-s, so here's my "sling" for your review that I use in the
> implementation of a state machine:
>
> \ sling table generator, doc via example:
>
> \ : first ." first" ;
> \ : second ." second" ;
> \ : third ." third" ;
> \ ' third ' second ' first sling shot
> \
> \ 1 shot → second ok
> \ -1 shot → ok
>
> : sling create  ( i × xt -- )
>     depth , begin depth while , repeat
>   does>  ( n -- ? )
>     over over @i U<
>     if 1+ + @i execute
>     else 2drop
>     then
> ;
>
> Cheers, Enoch.
>
>
> ------------------------------------------------------------------------------
> 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/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> ------------------------------------------------------------------------------
> 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/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


------------------------------------------------------------------------------
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/
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] int_restore, etc.

[Matthias T. <mt...@we...>]

Hi,

> I like these "critical[" "]critical" words, much better than int_suspend
> and int_restore, but I prefer their current asm code implementation
> since one would like to keep the criticial code execution to the
> minimum.

A critical section frame is not particular speed sensitve.
It simply turns off interrupts temporarily. A small
forth implementation that one can understand is
far more valuable.

Code _within_ that critical section should be as small
and fast as possible indeed. But again: maintainable
forth code is of higher value than some cryptic assembler
magic.. IMHO.

Matthias

Re: [Amforth] Code snippet

[Enoch <ix...@ho...>]

Rafael Gonzalez <ast...@ya...> writes:

> Hi, If you want to do a variable jump vector table, that is fine
>
> If you jump vector table has a known size, you' may also use forth200x structures for field names.
> That is the approach of forths like VFX Forth for its I/O vectors (GENIO drivers)

Not sure if lib/forth200x/structures.frt is ready for Flash based
fields.  We should be mindful that the AVR implements Harvard
archtecture unlike our PC's von Neumann's.

>
>
> For something more sophisticated as Finite State Machines you may want to have a look at
> http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm2.htm
>
>
> Paper explaining it at
> http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html

For the above mentioned reason we rarely can copy code verbatim. Hence,
the need to create our own tried & tested library.

Thanks, Enoch.


> Greetings
> Rafael
>
>
>
> ________________________________
>  De: Enoch <ix...@ho...>
> Para: amf...@li... 
> Enviado: Sábado 16 de febrero de 2013 18:47
> Asunto: [Amforth] Code snippet
>  
> Hi,
>
> Excuse me folks, while I am a (very) experienced embedded programmer
> Forth for me is a new experience. So here's another joy discovery. The
> old Forth sage tell us to use decision tables rather than case and
> nested if-s, so here's my "sling" for your review that I use in the
> implementation of a state machine:
>
> \ sling table generator, doc via example:
>
> \ : first ." first" ;
> \ : second ." second" ;
> \ : third ." third" ;
> \ ' third ' second ' first sling shot
> \
> \ 1 shot → second ok
> \ -1 shot → ok
>
> : sling create  ( i × xt -- )
>     depth , begin depth while , repeat
>   does>  ( n -- ? )
>     over over @i U<
>     if 1+ + @i execute
>     else 2drop
>     then
> ;
>
> Cheers, Enoch.
>
>
> ------------------------------------------------------------------------------
> 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/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> ------------------------------------------------------------------------------
> 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/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] int_restore, etc.

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

> Hi,
>
>> "-int" (int-off.asm) counterpart is "int_restore" (int-restore.asm). So,
>> why is this "int_restore" header commented out, i.e., not available to
>> the high level?
>
> uhm. yes. These words are one of very first ones, that fell out of
> scope later on.
>
>
>> Candidly, as "+int" (int-on.asm) is a simple SEI instruction (Set Global
>> Interrupt Flag) one would expect "-int" to be a simple CLI (Clear Global
>> Interrupt Flag) but this is not the case...
>> 
>> May I suggest:
>> 
>> +int → SEI
>> -int → CLI
>
> Thats fine.
>> int_suspend → ( -- SREG ) CLI
>> int_restore → ( SREG -- )
>
> These words are not really needed.
>
> \ get the I flag as a forth flag
> : int? SREG c@ SREG_I and 0> ;
>
> \ to be used in pairs within the same colon definition
> \ can be nested
> : critical[
>     int? r> swap >r >r \ keep the current state
>     -int \ turn interrupts off
>     drop \ currently the content of SREG.
> ;
>
> : ]critical
>     r> r> if +int then >r \ will crash if not matched
> ;
>
> \ test case. foo prints bar-1 baz0 qux-1
>
> : bar ." bar" int? . ;
> : baz ." baz" int? . ;
> : qux ." qux" int? . ;
>
> : foo
>   bar
>   critical[
>     \ nothing will disturb us here
>     baz
>   ]critical \ now interrupts or other things may happen again
>   qux ;

I like these "critical[" "]critical" words, much better than int_suspend
and int_restore, but I prefer their current asm code implementation
since one would like to keep the criticial code execution to the
minimum.

Thanks, Enoch.





















>
>
> ------------------------------------------------------------------------------
> 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/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Code snippet

[Rafael G. <ast...@ya...>]

Hi, If you want to do a variable jump vector table, that is fine

If you jump vector table has a known size, you' may also use forth200x structures for field names.
That is the approach of forths like VFX Forth for its I/O vectors (GENIO drivers)


For something more sophisticated as Finite State Machines you may want to have a look at
http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm2.htm


Paper explaining it at
http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html


Greetings
Rafael



________________________________
 De: Enoch <ix...@ho...>
Para: amf...@li... 
Enviado: Sábado 16 de febrero de 2013 18:47
Asunto: [Amforth] Code snippet
 
Hi,

Excuse me folks, while I am a (very) experienced embedded programmer
Forth for me is a new experience. So here's another joy discovery. The
old Forth sage tell us to use decision tables rather than case and
nested if-s, so here's my "sling" for your review that I use in the
implementation of a state machine:

\ sling table generator, doc via example:

\ : first ." first" ;
\ : second ." second" ;
\ : third ." third" ;
\ ' third ' second ' first sling shot
\
\ 1 shot → second ok
\ -1 shot → ok

: sling create  ( i × xt -- )
    depth , begin depth while , repeat
  does>  ( n -- ? )
    over over @i U<
    if 1+ + @i execute
    else 2drop
    then
;

Cheers, Enoch.


------------------------------------------------------------------------------
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/
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] no-wdt

[Matthias T. <mt...@we...>]

Hi Rafael,

> Trying to include dict_mcu.inc, I can't find file  words/no-wdt.asm
> It seems this file is missing from the distribution (amforth-5.0 or amforth-code trunk)

no-wdt is intended to disable the watchdog at runtime (regardless of
the fuse settings). Unfortunatly there are two different methods
to do this, depending on the controller type: either WDTCR or WDTCSR
registers. SLEEP has a similiar dependency.

I simply did not yet write the code to generate the proper no-wdt.asm
file in the core/devices/<mcu>/words directories.

Just comment the line in the dict-file.

Matthias

Re: [Amforth] int_restore, etc.

[Matthias T. <mt...@we...>]

Hi,

> "-int" (int-off.asm) counterpart is "int_restore" (int-restore.asm). So,
> why is this "int_restore" header commented out, i.e., not available to
> the high level?

uhm. yes. These words are one of very first ones, that fell out of
scope later on.


> Candidly, as "+int" (int-on.asm) is a simple SEI instruction (Set Global
> Interrupt Flag) one would expect "-int" to be a simple CLI (Clear Global
> Interrupt Flag) but this is not the case...
> 
> May I suggest:
> 
> +int → SEI
> -int → CLI

Thats fine.
> int_suspend → ( -- SREG ) CLI
> int_restore → ( SREG -- )

These words are not really needed.

\ get the I flag as a forth flag
: int? SREG c@ SREG_I and 0> ;

\ to be used in pairs within the same colon definition
\ can be nested
: critical[
    int? r> swap >r >r \ keep the current state
    -int \ turn interrupts off
    drop \ currently the content of SREG.
;

: ]critical
    r> r> if +int then >r \ will crash if not matched
;

\ test case. foo prints bar-1 baz0 qux-1

: bar ." bar" int? . ;
: baz ." baz" int? . ;
: qux ." qux" int? . ;

: foo
  bar
  critical[
    \ nothing will disturb us here
    baz
  ]critical \ now interrupts or other things may happen again
  qux ;

Re: [Amforth] Useful?

[Matthias T. <mt...@we...>]

Hi Enoch,

>> 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

ok. Now I understand what you intent. I think that
your code is a pretty good example to demonstrate
how to use machine code without loading the full
assembler.

> BTW, bitnames.frt, IMO, needs to be simplifed in two respects:
> 1. It is extremely rare for a port to be of bidirectional use.

I've recently came across 1-wire devices. They switch very
frequently.

> 2. Port address can be limited to 0..255.

That is what earlier releases had. Now look at the ardiuno
Mega devices and what can we find there? PORTJ (261) and PORTK
(264).

>> 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.

Interrupts are per se not interruptable, guess why the
I flag is cleared upon ISR start. A programmer may re-enable
interrupts within the ISR, but that's up to him/her.

> By the way, let the programmer worry about avoiding re-entrancy.

If (s)he takes care of re-entrancy (s)he will be capable to
enable it properly. I'm sure. The other way is far more
troublesome.

Matthias

Re: [Amforth] no-wdt

[Rafael G. <ast...@ya...>]

Good catch with the fuses configuration. I have skipped watchdog fuse configuration. 

No problem with the fuses: avrdude can set them easily and I have a makefile rule for that.

Regarding the file, yes, I've found wdr.asm, 
but IMHO at least the dict_mcu.inc is not correct, as the no-wdt.asm file is missing.


Greetings
Rafael



________________________________
 De: Enoch <ix...@ho...>
Para: amf...@li... 
Enviado: Sábado 16 de febrero de 2013 18:32
Asunto: Re: [Amforth] no-wdt
 
Rafael Gonzalez <ast...@ya...> writes:

> Hello list
>
> Trying to include dict_mcu.inc, I can't find file  words/no-wdt.asm
> It seems this file is missing from the distribution (amforth-5.0 or amforth-code trunk)

Matthias latest docs say:

"amforth provides wrapper words for the microcontroller instructions
SLEEP and WDR (watch dog reset). To work properly, the MCU needs more
configuration. amforth itself does not call these words."

and there is core/words/wdr.asm

Dealing with the fuses (WDTON) is currently outside Amforth scope.

Regards, Enoch.


>
> Greetings
> Rafael
> ------------------------------------------------------------------------------
> 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/
Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Code snippet

[Enoch <ix...@ho...>]

Hi,

Excuse me folks, while I am a (very) experienced embedded programmer
Forth for me is a new experience. So here's another joy discovery. The
old Forth sage tell us to use decision tables rather than case and
nested if-s, so here's my "sling" for your review that I use in the
implementation of a state machine:

\ sling table generator, doc via example:

\ : first ." first" ;
\ : second ." second" ;
\ : third ." third" ;
\ ' third ' second ' first sling shot
\
\ 1 shot → second ok
\ -1 shot → ok

: sling create  ( i × xt -- )
    depth , begin depth while , repeat
  does>  ( n -- ? )
    over over @i U<
    if 1+ + @i execute
    else 2drop
    then
;

Cheers, Enoch.