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

Groups > comp.lang.forth > #43308

Re: namespace

Show all headers | View raw

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.

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web