Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #42736 > unrolled thread

Forth and "embedded" enviroment

Back to article view | Back to comp.lang.forth

Contents

  Forth and "embedded" enviroment kristoff <kristoff@skypro.be> - 2015-10-22 00:23 +0200
    Re: Forth and "embedded" enviroment Roberto Waltman <usenet@rwaltman.com> - 2015-10-21 19:19 -0400
    Re: Forth and "embedded" enviroment rickman <gnuarm@gmail.com> - 2015-10-21 21:59 -0400
      Re: Forth and "embedded" enviroment kristoff <kristoff@skypro.be> - 2015-10-22 15:37 +0200
        Re: Forth and "embedded" enviroment rickman <gnuarm@gmail.com> - 2015-10-22 15:43 -0400
          Re: Forth and "embedded" enviroment jonjo <jjonethal@yahoo.de> - 2015-10-22 15:26 -0700
            Re: Forth and "embedded" enviroment rickman <gnuarm@gmail.com> - 2015-10-23 03:20 -0400
          namespace (was: Forth and "embedded" enviroment) kristoff <kristoff@skypro.be> - 2015-10-25 23:20 +0100
            Re: namespace Paul Rubin <no.email@nospam.invalid> - 2015-10-25 15:45 -0700
              Re: namespace kristoff <kristoff@skypro.be> - 2015-10-25 23:53 +0100
                Re: namespace Paul Rubin <no.email@nospam.invalid> - 2015-10-25 16:18 -0700
                  Re: namespace "Elizabeth D. Rather" <erather@forth.com> - 2015-10-25 14:01 -1000
                    Re: namespace Paul Rubin <no.email@nospam.invalid> - 2015-10-25 17:40 -0700
            Re: namespace "Elizabeth D. Rather" <erather@forth.com> - 2015-10-25 12:50 -1000
              Re: namespace kristoff Bonne <kristoff@skypro.be> - 2015-10-26 00:11 +0100
                Re: namespace "Elizabeth D. Rather" <erather@forth.com> - 2015-10-25 14:10 -1000
                  Re: namespace kristoff <kristoff@skypro.be> - 2015-11-03 23:11 +0100
                    Re: namespace "Elizabeth D. Rather" <erather@forth.com> - 2015-11-03 16:17 -1000
                      Re: namespace kristoff <kristoff@skypro.be> - 2015-11-07 17:56 +0100
            Re: namespace (was: Forth and "embedded" enviroment) hughaguilar96@gmail.com - 2015-10-25 16:31 -0700
            Re: namespace (was: Forth and "embedded" enviroment) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-26 11:23 +0000
          Re: Forth and "embedded" enviroment kristoff <kristoff@skypro.be> - 2015-11-03 12:16 +0100
            Re: Forth and "embedded" enviroment rickman <gnuarm@gmail.com> - 2015-11-03 11:12 -0500
              Re: Forth and "embedded" enviroment kristoff <kristoff@skypro.be> - 2015-11-04 14:06 +0100
                Re: Forth and "embedded" enviroment rickman <gnuarm@gmail.com> - 2015-11-04 09:29 -0500
    Re: Forth and "embedded" enviroment Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-10-22 11:13 +0200
      Re: Forth and "embedded" enviroment kristoff <kristoff@skypro.be> - 2015-10-22 15:54 +0200
        Re: Forth and "embedded" enviroment Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-10-22 16:42 +0200

Page 1 of 2  [1] 2  Next page →

#42736 — Forth and "embedded" enviroment

Hi,


I am interested in using Forth on embedded platform (currently trying 
out mecrisp on a STM32).

Does anybody have links to documentation on this? (GPIO, SPI, I2c, 
single-wire, ADCs, DACs, external hardware interrupts, timed interrups, 
...).
Also multithreading with communication between the different threads is 
interesting on a embedded-controller.


Yes, I did search the net for this myself, but the problem with Forth is 
that there simply is to much information about it and it all spread out 
over different versions of Forth and different applications.
So I am kind-of lost here.



Cheerio! Kr. Bonne.

[toc] | [next] | [standalone]

#42737

kristoff wrote:

>I am interested in using Forth on embedded platform (currently trying 
>out mecrisp on a STM32).
>
>Does anybody have links to documentation on this? (GPIO, SPI, I2c, 
>single-wire, ADCs, DACs, external hardware interrupts, timed interrups, 

What do you need besides the data sheets and application notes from
STM? (Plus @, !, c@, c!, etc ...)

>Also multithreading with communication between the different threads is 
>interesting on a embedded-controller.

Try FreeRTOS, Chibios, etc. (Not Forth based ...)

R.W.

[toc] | [prev] | [next] | [standalone]

#42742

On 10/21/2015 6:23 PM, kristoff wrote:
> Hi,
>
>
> I am interested in using Forth on embedded platform (currently trying
> out mecrisp on a STM32).
>
> Does anybody have links to documentation on this? (GPIO, SPI, I2c,
> single-wire, ADCs, DACs, external hardware interrupts, timed interrups,
> ....).
> Also multithreading with communication between the different threads is
> interesting on a embedded-controller.
>
>
> Yes, I did search the net for this myself, but the problem with Forth is
> that there simply is to much information about it and it all spread out
> over different versions of Forth and different applications.
> So I am kind-of lost here.

I'm not sure what info you are looking for.  The programming interfaces 
for the various MCU peripherals are all different between brands. 
Mostly they use programmed I/O unless you are expecting asynchronous 
events such as with UARTs where you may want to use interrupt driven 
routines.  I think you are going to find Mecrisp only has support for 
the I/O to the console and every thing else you will need to roll your 
own.  This is best done by obtaining the source in either assembly or 
better C code which you can then recode in Forth.

I just received a new board with the FPGA/MCU SoC from Microsemi which I 
am going to try to get Mecrisp running on.  The above is how I am going 
to do that.  You can email me if you'd like to have an exchange about 
all this, or we can discuss it here.  I'll probably get around to 
starting some of the work next week.

If you need to dig into Mecrisp to learn how that works, some of it is 
commented in German, so you may need a translation web page if you 
aren't a native speaker.  If you are a native speaker, I may need you to 
help me translate.  Sometimes technical jargon is hard to translate.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#42755

Hi Rickman,


(inline coments)


On 22-10-15 03:59, rickman wrote:
>> I am interested in using Forth on embedded platform (currently trying
>> out mecrisp on a STM32).
>> Does anybody have links to documentation on this? (GPIO, SPI, I2c,
>> single-wire, ADCs, DACs, external hardware interrupts, timed interrups,
>> ....).

> I'm not sure what info you are looking for.  The programming interfaces
> for the various MCU peripherals are all different between brands. Mostly
> they use programmed I/O unless you are expecting asynchronous events
> such as with UARTs where you may want to use interrupt driven routines.
> I think you are going to find Mecrisp only has support for the I/O to
> the console and every thing else you will need to roll your own.  This
> is best done by obtaining the source in either assembly or better C code
> which you can then recode in Forth.


Well, I give a small arduino / microcontroller / programming course in 
our local radio-club here in Ostend and have been thinking if it would 
be possible to give a m smmal demo on Forth (to show it next to 
arduino/wiring, native C or mbed).


Now, one of the nice things about the arduino platform (from a simple 
user point of view) is the standard standard API for a lot of basic 
stuff that works all across the board.
Things like "pinMode", "digitalWrite", "analogRead", "delay", etc. all 
work on whatever platforms: arduino AVR, arduino ARM, mapple 
(STM32-based arduine clone), Energia (arduino-IDE clone for the TI 
launchpad), ...

There even is code for (say) attaching functions to timed-interrupts, to 
hardware-interrupts, etc.


Of course, the code below (say) "digitalWrite" is different for every 
microcontrollers, but that is also the case for the 
arduino/mapple/energvia platform).

After all, isn't that the goal of a high-level language: hide the 
complexity of the low-level bitshifting code for the high-level 
application-level programmer.



So,
- is there a standard "library" for the basic I/O functions a embedded 
controller is typically used for. (reading from ports, writing to ports, 
...)

- If no such thing exist for the particular microcontroller I use, I do 
not have an objection to try do some stuff myself.

As mentioned above, the nice thing for an application-level programmer 
about the arduino platform is the standardised API that exists accross 
platforms.

Is there a standard API in Forth for this kind of work, so that a Forth 
application on one microcontroller can be ported with limited (or no) 
effort?


- Are there any open-source examples of code for certain things. I guess 
certain things are pretty straight-forward (like reading or writing to a 
digital pin), but other aspects are more complex.

E.g. two weeks ago, in our radio-club, we did an exercise to read the 
input from a PS/2 keyboard using an arduino. If you look into the C++ 
class for this, it see that it actually uses a hardware interrupt 
(attached to the clock-signal of the PS/2 interface).

It would be nice to have some code-exmmples to look at to find out how 
to code this in Forth?




>
> I just received a new board with the FPGA/MCU SoC from Microsemi which I
> am going to try to get Mecrisp running on.  The above is how I am going
> to do that.  You can email me if you'd like to have an exchange about
> all this, or we can discuss it here.  I'll probably get around to
> starting some of the work next week.
Well, I am still pretty new in all this, but if I can help, no problem.


> If you need to dig into Mecrisp to learn how that works, some of it is
> commented in German, so you may need a translation web page if you
> aren't a native speaker.  If you are a native speaker, I may need you to
> help me translate.  Sometimes technical jargon is hard to translate.
My reading-skills of German are not 100 % but I can manage.


Cheerio! Kr. Bonne.

[toc] | [prev] | [next] | [standalone]

#42760

On 10/22/2015 9:37 AM, kristoff wrote:
> Hi Rickman,
>
>
> (inline coments)
>
>
> On 22-10-15 03:59, rickman wrote:
>>> I am interested in using Forth on embedded platform (currently trying
>>> out mecrisp on a STM32).
>>> Does anybody have links to documentation on this? (GPIO, SPI, I2c,
>>> single-wire, ADCs, DACs, external hardware interrupts, timed interrups,
>>> ....).
>
>> I'm not sure what info you are looking for.  The programming interfaces
>> for the various MCU peripherals are all different between brands. Mostly
>> they use programmed I/O unless you are expecting asynchronous events
>> such as with UARTs where you may want to use interrupt driven routines.
>> I think you are going to find Mecrisp only has support for the I/O to
>> the console and every thing else you will need to roll your own.  This
>> is best done by obtaining the source in either assembly or better C code
>> which you can then recode in Forth.
>
>
> Well, I give a small arduino / microcontroller / programming course in
> our local radio-club here in Ostend and have been thinking if it would
> be possible to give a m smmal demo on Forth (to show it next to
> arduino/wiring, native C or mbed).
>
>
> Now, one of the nice things about the arduino platform (from a simple
> user point of view) is the standard standard API for a lot of basic
> stuff that works all across the board.
> Things like "pinMode", "digitalWrite", "analogRead", "delay", etc. all
> work on whatever platforms: arduino AVR, arduino ARM, mapple
> (STM32-based arduine clone), Energia (arduino-IDE clone for the TI
> launchpad), ...
>
> There even is code for (say) attaching functions to timed-interrupts, to
> hardware-interrupts, etc.

That's great if you are happy with the hardware/software/development 
environment.  Many have needs that are not fulfilled by Arduino.  My 
goal is to use the Microsemi SoC.  Do you know of an Arduino environment 
for this device?


> Of course, the code below (say) "digitalWrite" is different for every
> microcontrollers, but that is also the case for the
> arduino/mapple/energvia platform).

Hence the problem which is not solved by using Arduino...


> After all, isn't that the goal of a high-level language: hide the
> complexity of the low-level bitshifting code for the high-level
> application-level programmer.

I don't see it quite that way because my work *is* the low level 
interfacing.  I don't want it hidden anyway.  I want to be able to dig 
in and see *exactly* what is going on.  I've seen too many things made 
hard by hiding the details.


> So,
> - is there a standard "library" for the basic I/O functions a embedded
> controller is typically used for. (reading from ports, writing to ports,
> ...)
>
> - If no such thing exist for the particular microcontroller I use, I do
> not have an objection to try do some stuff myself.
>
> As mentioned above, the nice thing for an application-level programmer
> about the arduino platform is the standardised API that exists accross
> platforms.

Isn't that what Forth provides?


> Is there a standard API in Forth for this kind of work, so that a Forth
> application on one microcontroller can be ported with limited (or no)
> effort?

Forth *is* the API.  If you mean are their standardized words for 
talking to SPI, UART, I2C, etc, then I guess not.  But none of this is 
hard to deal with in my opinion.  More importantly, I seldom port code 
across hardware platforms.  Sometimes from one version of Windows to 
another or to Linux perhaps.  So far I've found Forth to be very 
compatible.


> - Are there any open-source examples of code for certain things. I guess
> certain things are pretty straight-forward (like reading or writing to a
> digital pin), but other aspects are more complex.
>
> E.g. two weeks ago, in our radio-club, we did an exercise to read the
> input from a PS/2 keyboard using an arduino. If you look into the C++
> class for this, it see that it actually uses a hardware interrupt
> (attached to the clock-signal of the PS/2 interface).
>
> It would be nice to have some code-exmmples to look at to find out how
> to code this in Forth?

Not sure what you are asking.  If you have the C source, it is very easy 
to recode that into Forth.  If you have an interrupt handler to port, 
you will need to read about your particular Forth an how to code that.


>> I just received a new board with the FPGA/MCU SoC from Microsemi which I
>> am going to try to get Mecrisp running on.  The above is how I am going
>> to do that.  You can email me if you'd like to have an exchange about
>> all this, or we can discuss it here.  I'll probably get around to
>> starting some of the work next week.
> Well, I am still pretty new in all this, but if I can help, no problem.

I'm downloading the MCU side of the IDE as I write this.


>> If you need to dig into Mecrisp to learn how that works, some of it is
>> commented in German, so you may need a translation web page if you
>> aren't a native speaker.  If you are a native speaker, I may need you to
>> help me translate.  Sometimes technical jargon is hard to translate.
> My reading-skills of German are not 100 % but I can manage.
>
>
> Cheerio! Kr. Bonne.

I know the first step of porting Mecrisp is to get the UART interface 
code.  I recall that Matthias codes everything in either assembly or 
Forth.  So I'll be getting up to speed in ARM assembly soon as well.  	

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#42762

You can use the disassembler from common directory to get an idea how mecrisp is working inside and how your code looks after compilation. Very handy to get in touch with assembly.

Jean

[toc] | [prev] | [next] | [standalone]

#42765

On 10/22/2015 6:26 PM, jonjo wrote:
> You can use the disassembler from common directory to get an idea how mecrisp is working inside and how your code looks after compilation. Very handy to get in touch with assembly.

Thanks.  I have been looking at the sources.  There are lots of good 
references online to explain how assembly works.  But if I want to dig 
into compiled words, I'll use the disassembler.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#42799 — namespace (was: Forth and "embedded" enviroment)

Hi all,





On 22-10-15 21:43, rickman wrote:
>> Is there a standard API in Forth for this kind of work, so that a Forth
>> application on one microcontroller can be ported with limited (or no)
>> effort?

> Forth *is* the API.  If you mean are their standardized words for
> talking to SPI, UART, I2C, etc, then I guess not.  But none of this is
> hard to deal with in my opinion.
(...)

Well, I have a question about this.

Today, I have been playing around a little bit with the code I have for 
setting the clock on the STM32F103. I ported the code I originally wrote 
to set the CPUspeed from assembler to Forth.


If this would have been in (say) C or arduino (i.e. C++), what I would 
do now is drop the code somewhere on the internet (github), making it a 
seperate library/class.
That way, the names of the functions I have written would surely not 
interfere with with somebody else might have used.


How does one do this in Forth?
Is there a way to set up different "namespaces". How do you make sure 
you can write code and that the names of the "functions" and "constants" 
do not get in eachother way.

Or do you use names like "stm32f103_css.<something>" for all words and 
constants, just to make sure that they are all unique.


I am still relative new to forth. I looked in the documentation I have 
for the concept of "namespaces" or something equivalent but did not find 
it. My appologies if I have overlooked it.


Cheerio! Kr. Bonne.

[toc] | [prev] | [next] | [standalone]

#42802 — Re: namespace

kristoff <kristoff@skypro.be> writes:
> I am still relative new to forth. I looked in the documentation I have
> for the concept of "namespaces" or something equivalent but did not
> find it. My appologies if I have overlooked it.

The Forth term for that is "wordlists".

[toc] | [prev] | [next] | [standalone]

#42805 — Re: namespace

Paul,





On 25-10-15 23:45, Paul Rubin wrote:
> kristoff <kristoff@skypro.be> writes:
>> I am still relative new to forth. I looked in the documentation I have
>> for the concept of "namespaces" or something equivalent but did not
>> find it. My appologies if I have overlooked it.
>
> The Forth term for that is "wordlists".

Thanks!

I found it in the "programming forth" book. The other books I have found 
("Forth Primer" and "thinking forth") do not mentioned that.


What online manual for Forth would you advice nowdays for new users?


Cheerio! Kr. Bonne.

[toc] | [prev] | [next] | [standalone]

#42807 — Re: namespace

kristoff <kristoff@skypro.be> writes:
> What online manual for Forth would you advice nowdays for new users?

I generally use the gforth manual

  http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/

which has some significant gaps.  "Forth Application Techniques" (print
only) is supposed to be good but I don't have a copy yet.  There are
online manuals for VFX and Swift that have some helpful info but also
(like the gforth manual) significant gaps.  Looking at implementation
descriptions has also been informative.  There are some nice ones here:

  http://bradrodriguez.com/papers/index.html

Re namespaces: C doesn't have them either, but some big C systems have
been written.  Basically you develop conventions about prefixing symbols
with what subsystem they belong to.  Forth programs also tend to throw
everything in one vocabulary, which works ok if the program is not too
big.

[toc] | [prev] | [next] | [standalone]

#42809 — Re: namespace

On 10/25/15 1:18 PM, Paul Rubin wrote:
> kristoff <kristoff@skypro.be> writes:
>> What online manual for Forth would you advice nowdays for new users?
>
> I generally use the gforth manual
>
>    http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/
>
> which has some significant gaps.  "Forth Application Techniques" (print
> only) is supposed to be good but I don't have a copy yet.  There are
> online manuals for VFX and Swift that have some helpful info but also
> (like the gforth manual) significant gaps.  Looking at implementation
> descriptions has also been informative.  There are some nice ones here:
>
>    http://bradrodriguez.com/papers/index.html
>
> Re namespaces: C doesn't have them either, but some big C systems have
> been written.  Basically you develop conventions about prefixing symbols
> with what subsystem they belong to.  Forth programs also tend to throw
> everything in one vocabulary, which works ok if the program is not too
> big.
>

Good Forth implementations will warn you if they encounter a name 
collision during compilation, so you don't have to be too paranoid about it.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#42811 — Re: namespace

"Elizabeth D. Rather" <erather@forth.com> writes:
> Good Forth implementations will warn you if they encounter a name
> collision during compilation, so you don't have to be too paranoid
> about it.

Gforth issues such a warning but it's easy to miss it due to other
messages spewing across the screen when you load a code file
interactively.

[toc] | [prev] | [next] | [standalone]

#42804 — Re: namespace

On 10/25/15 12:20 PM, kristoff wrote:
> Hi all,
>
>
>
>
>
> On 22-10-15 21:43, rickman wrote:
>>> Is there a standard API in Forth for this kind of work, so that a Forth
>>> application on one microcontroller can be ported with limited (or no)
>>> effort?
>
>> Forth *is* the API.  If you mean are their standardized words for
>> talking to SPI, UART, I2C, etc, then I guess not.  But none of this is
>> hard to deal with in my opinion.
> (...)
>
> Well, I have a question about this.
>
> Today, I have been playing around a little bit with the code I have for
> setting the clock on the STM32F103. I ported the code I originally wrote
> to set the CPUspeed from assembler to Forth.
>
>
> If this would have been in (say) C or arduino (i.e. C++), what I would
> do now is drop the code somewhere on the internet (github), making it a
> seperate library/class.
> That way, the names of the functions I have written would surely not
> interfere with with somebody else might have used.
>
>
> How does one do this in Forth?
> Is there a way to set up different "namespaces". How do you make sure
> you can write code and that the names of the "functions" and "constants"
> do not get in eachother way.
>
> Or do you use names like "stm32f103_css.<something>" for all words and
> constants, just to make sure that they are all unique.
>
>
> I am still relative new to forth. I looked in the documentation I have
> for the concept of "namespaces" or something equivalent but did not find
> it. My appologies if I have overlooked it.

What you're looking for is "wordlists" or "vocabularies". They do 
provide a capability for specialized namespaces. There is a tendency for 
newbies to over-use them, though. My advice is to use them sparingly, 
for specialized code that supports a few high-level public words that 
use it. I always recommend studying the implementation of a 
well-regarded Forth system (ideally more than one) to see how 
experienced Forthers use these facilities.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#42806 — Re: namespace

HI Elizabeth,



On 25-10-15 23:50, Elizabeth D. Rather wrote:
>> I am still relative new to forth. I looked in the documentation I have
>> for the concept of "namespaces" or something equivalent but did not find
>> it. My appologies if I have overlooked it.

> What you're looking for is "wordlists" or "vocabularies". They do
> provide a capability for specialized namespaces.

Thanks.
As replied in my message to Paul, it looks like I looked into the wrong 
(or to old) books.


> There is a tendency for
> newbies to over-use them, though. My advice is to use them sparingly,
> for specialized code that supports a few high-level public words that
> use it. I always recommend studying the implementation of a
> well-regarded Forth system (ideally more than one) to see how
> experienced Forthers use these facilities.

OK, let's take one example. Here's some line of code (to set the USART 
of the STM32F103 to 115200 bps after you reset the clock to the internal 
8 Mhz clock)


--- cut here --- cut here --- cut here ----

\\ Set USART1 to 115200 bps, 8 Mhz (internal) clock
\\ For 8 MHz:
\\ 8000000 / (16 * 115200 ) = 4.3403
\\  0.3403 * 16 = 5.4448
\\  Divider 4, Fractional term 5 or 6 --> $45 or $46.


$40013800 constant USART1_Base
USART1_Base $08 + constant Terminal_USART1_BRR
: setusart_8Mhz
$46 Terminal_USART1_BRR !
;
--- cut here --- cut here --- cut here ----


I know this is a lot of text for just 1 action, but -for me- the goal is 
opensource code is not only to do its work, but also to explain to 
others how something work.


So, in this case, do I put these two constants in a seperate worldlist 
or not?

(of course, this is just one of the words in this "library").


> Cheers,
> Elizabeth
Cheerio! kr. Bonne.

[toc] | [prev] | [next] | [standalone]

#42810 — Re: namespace

On 10/25/15 1:11 PM, kristoff Bonne wrote:
> HI Elizabeth,
>
>
>
> On 25-10-15 23:50, Elizabeth D. Rather wrote:
>>> I am still relative new to forth. I looked in the documentation I have
>>> for the concept of "namespaces" or something equivalent but did not find
>>> it. My appologies if I have overlooked it.
>
>> What you're looking for is "wordlists" or "vocabularies". They do
>> provide a capability for specialized namespaces.
>
> Thanks.
> As replied in my message to Paul, it looks like I looked into the wrong
> (or to old) books.
>
>
>> There is a tendency for
>> newbies to over-use them, though. My advice is to use them sparingly,
>> for specialized code that supports a few high-level public words that
>> use it. I always recommend studying the implementation of a
>> well-regarded Forth system (ideally more than one) to see how
>> experienced Forthers use these facilities.
>
> OK, let's take one example. Here's some line of code (to set the USART
> of the STM32F103 to 115200 bps after you reset the clock to the internal
> 8 Mhz clock)
>
>
> --- cut here --- cut here --- cut here ----
>
> \\ Set USART1 to 115200 bps, 8 Mhz (internal) clock
> \\ For 8 MHz:
> \\ 8000000 / (16 * 115200 ) = 4.3403
> \\  0.3403 * 16 = 5.4448
> \\  Divider 4, Fractional term 5 or 6 --> $45 or $46.
>
>
> $40013800 constant USART1_Base
> USART1_Base $08 + constant Terminal_USART1_BRR
> : setusart_8Mhz
> $46 Terminal_USART1_BRR !
> ;
> --- cut here --- cut here --- cut here ----
>
>
> I know this is a lot of text for just 1 action, but -for me- the goal is
> opensource code is not only to do its work, but also to explain to
> others how something work.
>
>
> So, in this case, do I put these two constants in a seperate worldlist
> or not?
>
> (of course, this is just one of the words in this "library").

No, they certainly don't belong in a separate namespace! What is the 
likelihood you'll have a word named USART1_Base or Terminal_USART1_BRR 
with different values?

The purpose of a separate space is to enable you to use the same names 
for analogous functions in different contexts. For example, Open 
Firmware provides drivers for a lot of devices that may be attached to 
your computer. Every driver has "methods" such as OPEN, CLOSE, READ, 
WRITE, INIT, etc., but they all do device-specific things. So each is in 
a separate wordlist that you specify by naming the device, e.g.:

DISK1 OPEN
DISK2 OPEN
KEYBOARD READ
...etc. where the name selects the device's wordlist so that you get the 
appropriate method for that device.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43201 — Re: namespace

Elizabeth,



(Sorry for the late reply. It's been a strange couple of weeks).



On 26-10-15 01:10, Elizabeth D. Rather wrote:
 >> $40013800 constant USART1_Base
 >> USART1_Base $08 + constant Terminal_USART1_BRR
 >> : setusart_8Mhz
 >> $46 Terminal_USART1_BRR !
 >> ;
 >> --- cut here --- cut here --- cut here ----
 >> I know this is a lot of text for just 1 action, but -for me- the goal is
 >> opensource code is not only to do its work, but also to explain to
 >> others how something work.
 >> So, in this case, do I put these two constants in a seperate worldlist
 >> or not?
 >> (of course, this is just one of the words in this "library").

 > No, they certainly don't belong in a separate namespace! What is the
 > likelihood you'll have a word named USART1_Base or Terminal_USART1_BRR
 > with different values?

Well, my principe has been then "coding" and "making assumptions" make 
not very good friends.

The core idea of open-source is software reusability. And this means you 
know your code will be used by other people, so you try to make sure you 
stay out of everybody's way as much as possible.

You are correct that there the chance somebody else will use the same 
name is pretty slim, but that is not really the point. If there is no 
reason for a application programmer to interact with 
"Terminal_USART_BRR", what is the logic of having it visible to him/her?




 > The purpose of a separate space is to enable you to use the same names
 > for analogous functions in different contexts. For example, Open
 > Firmware provides drivers for a lot of devices that may be attached to
 > your computer. Every driver has "methods" such as OPEN, CLOSE, READ,
 > WRITE, INIT, etc., but they all do device-specific things. So each is in
 > a separate wordlist that you specify by naming the device, e.g.:
 >
 > DISK1 OPEN
 > DISK2 OPEN

Do you mean, "open" of two different kinds of disks, or is this two 
instances of one type of disk?


 > KEYBOARD READ
 > ....etc. where the name selects the device's wordlist so that you get
 > the appropriate method for that device.

I see.

Now, let's concider something like a software-serial interface. How 
would you advice coding that?
Do you need a seperate worldlist per instance, or can you create 
multiple instances of one worldlist, everyone with its own private data?




 > Cheers,
 > Elizabeth

Cheerio! Kr. Bonne.

[toc] | [prev] | [next] | [standalone]

#43206 — Re: namespace

On 11/3/15 12:11 PM, kristoff wrote:
>
> Elizabeth,
>
>
>
> (Sorry for the late reply. It's been a strange couple of weeks).
>
>
>
> On 26-10-15 01:10, Elizabeth D. Rather wrote:
>  >> $40013800 constant USART1_Base
>  >> USART1_Base $08 + constant Terminal_USART1_BRR
>  >> : setusart_8Mhz
>  >> $46 Terminal_USART1_BRR !
>  >> ;
>  >> --- cut here --- cut here --- cut here ----
>  >> I know this is a lot of text for just 1 action, but -for me- the
> goal is
>  >> opensource code is not only to do its work, but also to explain to
>  >> others how something work.
>  >> So, in this case, do I put these two constants in a seperate worldlist
>  >> or not?
>  >> (of course, this is just one of the words in this "library").
>
>  > No, they certainly don't belong in a separate namespace! What is the
>  > likelihood you'll have a word named USART1_Base or Terminal_USART1_BRR
>  > with different values?
>
> Well, my principe has been then "coding" and "making assumptions" make
> not very good friends.
>
> The core idea of open-source is software reusability. And this means you
> know your code will be used by other people, so you try to make sure you
> stay out of everybody's way as much as possible.
>
> You are correct that there the chance somebody else will use the same
> name is pretty slim, but that is not really the point. If there is no
> reason for a application programmer to interact with
> "Terminal_USART_BRR", what is the logic of having it visible to him/her?

Naming constants is always a good thing for code clarity, but why does 
it need to be in a different name space? In what circumstance in this 
program would this name have a different value?

>  > The purpose of a separate space is to enable you to use the same names
>  > for analogous functions in different contexts. For example, Open
>  > Firmware provides drivers for a lot of devices that may be attached to
>  > your computer. Every driver has "methods" such as OPEN, CLOSE, READ,
>  > WRITE, INIT, etc., but they all do device-specific things. So each is in
>  > a separate wordlist that you specify by naming the device, e.g.:
>  >
>  > DISK1 OPEN
>  > DISK2 OPEN
>
> Do you mean, "open" of two different kinds of disks, or is this two
> instances of one type of disk?

They could be entirely different devices. DISK1 selects the name space 
for a particular device, which may be at a different address or even 
have a completely different driver from the device referenced by DISK2, 
but the definition of OPEN does the same conceptual action in both 
cases. In fact, Open Firmware has "methods" such as OPEN, CLOSE. READ, 
WRITE, etc., for most devices, including keyboards, screens, disks, comm 
ports, etc., each of which is defined in a name space associated with 
its device.

>  > KEYBOARD READ
>  > ....etc. where the name selects the device's wordlist so that you get
>  > the appropriate method for that device.
>
> I see.
>
> Now, let's concider something like a software-serial interface. How
> would you advice coding that?
> Do you need a seperate worldlist per instance, or can you create
> multiple instances of one worldlist, everyone with its own private data?

Classically, Forth provides the words KEY and EMIT for serial 
character-level operations, plus ACCEPT (EXPECT in pre-Forth94, with a 
slightly different behavior) and TYPE for string I/O. There are 
task-specific driver-level words typically called (KEY) and (EMIT), so 
KEY and EMIT would call the one for the current task, and ACCEPT/TYPE 
are defined in terms of KEY/EMIT. Here the task provides the context in 
which you get the right one. But if you're not using that kind of 
multitasker, you could certainly use namespaces to achieve the same 
thing, so that the default version of TYPE goes to the screen and a word 
like PRINT selects the alternative that goes to the printer and SERIAL 
sends the string out a serial port.

Cheers,
Elizabeth


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43308 — Re: namespace

Elisabath,




On 04-11-15 03:17, Elizabeth D. Rather wrote:
>> Well, my principe has been then "coding" and "making assumptions" make
>> not very good friends.
>>
>> The core idea of open-source is software reusability. And this means you
>> know your code will be used by other people, so you try to make sure you
>> stay out of everybody's way as much as possible.
>>
>> You are correct that there the chance somebody else will use the same
>> name is pretty slim, but that is not really the point. If there is no
>> reason for a application programmer to interact with
>> "Terminal_USART_BRR", what is the logic of having it visible to him/her?
>
> Naming constants is always a good thing for code clarity, but why does
> it need to be in a different name space? In what circumstance in this
> program would this name have a different value?

Well, especially constants used to nameing return-values (like "TRUE", 
"FALSE", "SUCCESS", "OK", "FAILURE", ...) are



One person might use "SUCCESS" as 1 and "FAIL" as 0, while a programmer 
from another module (you happen to use in your code) uses 0 as "SUCCESS" 
and some negative values for failure-clauses.


But, as mentioned above, the issue is more related to names used to 
define hardware in an embedded controller.
The "header-files" (if I can use the C-equivalent) are nothing else then 
the software equivalent of the datasheets of a microcontroller. Maping 
physical registers and bit-position to their function is a core function 
of writing portable code.
The goal is to code all processor-specific information in the constants 
and keep the actual code to manipulate the registers as generic as 
possible. That way, you reduce the work to port libraries to a different 
processor as as much as possible.


However, this creates huge amounts of constants.

I started creating the constants for the RCC (Reset and clock control) 
of the STM32F103, and i currently have over 20 of them.
But, if you look at something like basic GPIO, for every port there are 
3 registers and as much bitpositions you need to set or read. So this 
means that, per GPIO-port, you need at least 6 constants.
The stm32f103rb -which isn't really a very high-end chip- has 32 GPIO 
ports, so this means that you need 192 constants, just and only for 
basic GPIO functions.
And that is just this one feature of the chip.

The "STM32F10x reference manual" document is 1128 pages. The reference 
manual for the STM32F403 (which is the chip found in the 20 dollar 
STM32F4-discovery board) is 1416 pages!

These things have become really really complex.

As said, the constants are the software equivalent of the datasheets. 
So, you quickly and up with hunderds and hunders of constants.


If you do this in (say) C, that is not an issue. You put all the 
information for that particular processor in a header-file and include 
it in your code to compile the libraries.

However, this is only needed to compile the libraries. And 
application-level programmer does not need these defines. He just links 
to the compiled object and calls "setDigitalOut()". Whatever code (and 
therefor processor-specific constants) are of no concern to him/her so 
there is no need to expose these hunderds and hunderds of constants to 
him/her.


So my question is how to do this in forth?

How do I create a library to do (say) basic I/O functions of a processor 
and not pollute the namespace of the application-users?




>> Now, let's concider something like a software-serial interface. How
>> would you advice coding that?
>> Do you need a seperate worldlist per instance, or can you create
>> multiple instances of one worldlist, everyone with its own private data?
>
> Classically, Forth provides the words KEY and EMIT for serial
> character-level operations ...

OK, I am sorry. My question was a bit different.

If I am correct, "DISK1" and "DISK2" are just two disks. If you have a 
embedded controller, you know there are three USART, so there are three 
different name-spaes: USART1, USART2 and USART3.
This is all linked to the actual hardware of a device.

However, a software-serial is that you use generic GPIO ports for serial 
communication, doing bitbanging instead of using the onboard USART 
hardware. So, you do not know how many interfaces a application-write 
will create. They are created on the fly.

Every software-serial interface needs its own private variables to 
maintain its own state.
In C++ you use objects for that. In C, you'd use "static" local variables.

So, my question: how do you do this in forth?


> Cheers,
> Elizabeth
Cheerio! Kr. Bonne.

[toc] | [prev] | [next] | [standalone]

#42808 — Re: namespace (was: Forth and "embedded" enviroment)

On Sunday, October 25, 2015 at 3:20:17 PM UTC-7, krbonne wrote:
> Is there a way to set up different "namespaces". How do you make sure 
> you can write code and that the names of the "functions" and "constants" 
> do not get in eachother way.

When I was programming in UR/Forth I implemented modules. This required some assembly-language using carnal knowledge, but it wasn't difficult.

After any definition that was intended to only be used within the module, the word LOCAL could be used to mark the word (it set a bit in the header flags byte). At the end of the module (typically the end of an INCLUDE file), the word END-MODULE could be used --- it traversed the dictionary and smudged every word that had been marked by LOCAL (the header flags byte had a bit that indicated that the word was smudged and hence couldn't be found in a dictionary search such as by FIND).

The idea here was that only a few words in the module would be made public, and the rest would be smudged by END-MODULE --- this way there is less name-space pollution.

None of this is possible in ANS-Forth or Forth-200x --- if you are using a custom Forth however, it should be easy to implement.

> Or do you use names like "stm32f103_css.<something>" for all words and 
> constants, just to make sure that they are all unique.

That is what FFL (Forth Foundation Library) does --- this results in grossly ugly code --- I don't recommend doing this because your code will be almost unreadable.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web