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 2 of 2 — ← Prev page 1 [2]

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

kristoff <kristoff@skypro.be> writes:
>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.

As others have written, you can use wordlists/vocabularies for that.

However, namespaces are the C++ solution for a C++ problem (actually
it's common to all Algol family languages):

If you have the same name defined in two libraries, C++ gives you an
error (unless you use name spaces).

In Forth, if you have two words with the same name in two libraries,
in many cases the program just works.  Say, you have:

library1:

: foo ... ;
: bar ... foo ... ;

library2:

: foo ... ;
: boing ... foo ... ;

main program:
require library1
require library2
: main bar boing ;

Here the FOO in BAR refers to the FOO in library1, and the FOO in
BOING refers to the FOO in library2, just as the programmers of these
libraries intended.  If you need to access one or both of the FOOs
from the main program, you can arrange that:

main program:
require library1
synonym lib1-foo foo
require library2
synonym lib2-foo foo \ not necessary, just for clarity
: main bar boing lib1-foo lib2-foo ;

In contrast, C++ and its ancestors up to Algol and Fortran give you
error messages when you define FOO twice, so you need name spaces or
something similar to work around that.

One tends to avoid such name clashes in Forth by renaming one of the
FOOs if we can help it, because in debugging we want to be able to
call both FOOs.  But for the same reason we prefer renaming to
wordlists: we would have to manage the search order all the time
during debugging.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43165

Hi rick,


This is a very long delay. My apologies for that.



On 22-10-15 21:43, rickman wrote:
>> 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?

If you use a new platform. The change of there being a ready-to-use 
platform for it are indeed relative small.


But, as said, I look at this from the classes I give in our local radioclub.
Most people using arduinos thesedays do not have a real "computing" or 
"IT" background. These are people who are into electronics, or who just 
want to make something and get it to work.

Most people thesedays use the "code by youtube" principle. Search the 
net to find to find information about somebody who has done a simular 
project, copy-and-paste it and then modify it to do whatever you want to 
do with it.

As said, the bigest advantage of the arduino enviroment is that the code 
works crossplatform. Image that the project you want to do is on -say- a 
arduino due (cortex-M3) and the examples you find on the web are for 
(say) an arduino uno (AVR) or a chipkit (PIC32), the code is portable 
and will work.


And, in that is the reason why the arduino is so successfull: the large 
amount of code and examples out there that "'simply work", not matter 
what platform you use it on.



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

OK, but what would be helpfull for the platform you are working on, is 
that, if you write the low-level code for this platform, is that you 
create the same words as used on other platforms to do the same thing.




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

"hiding details" is not always with the goal to hide information. I once 
wrote a POCSAG encoder for arduino (or plain C++ if you like). The API 
is just one call "create message", but the code itself is freely 
available on github and it probably contains as much lines comments 
explaining the POCSAG format then actual code implementing it.


But, as said, the point is that the large majority of people do not 
really care about all this.
The next exercise for the class is a project to drive a antenne-motor 
(based on information received from a PC).
You know, these people do not care about the USARTDIV or PORTAMOD 
registers or or interrupt service routines for the USART or the ADC, 
they joint want to have something that works: i.e. point the antenne to 
the direction of the remote station they want to reach.


I know of at least two people who had started out with AVRs and PICs 
years ago but had given up because it was "to much work" having to dig 
through pages of datasheets and programming-manuals and to code all 
these details.
But using the high-level APIs of arduino, mbed and what else have you, 
they are again into microcontrollers. At least now, they can spend most 
time working on the project they want to achieve and not all this 
low-level stuff.



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

OK, kind of found part of that.

I'm still kind of confused on how to get the interrupt-service-routine 
and the other threads communicate with eachother without having to use 
global data.



Cheerio! Kr. Bonne.

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

#43177

On 11/3/2015 6:16 AM, kristoff wrote:
> Hi rick,
>
>
> This is a very long delay. My apologies for that.
>
>
>
> On 22-10-15 21:43, rickman wrote:
>>> 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?
>
> If you use a new platform. The change of there being a ready-to-use
> platform for it are indeed relative small.
>
>
> But, as said, I look at this from the classes I give in our local
> radioclub.
> Most people using arduinos thesedays do not have a real "computing" or
> "IT" background. These are people who are into electronics, or who just
> want to make something and get it to work.
>
> Most people thesedays use the "code by youtube" principle. Search the
> net to find to find information about somebody who has done a simular
> project, copy-and-paste it and then modify it to do whatever you want to
> do with it.
>
> As said, the bigest advantage of the arduino enviroment is that the code
> works crossplatform. Image that the project you want to do is on -say- a
> arduino due (cortex-M3) and the examples you find on the web are for
> (say) an arduino uno (AVR) or a chipkit (PIC32), the code is portable
> and will work.
>
>
> And, in that is the reason why the arduino is so successfull: the large
> amount of code and examples out there that "'simply work", not matter
> what platform you use it on.

So they can find what they want, all good.


>>> 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...
>
> OK, but what would be helpfull for the platform you are working on, is
> that, if you write the low-level code for this platform, is that you
> create the same words as used on other platforms to do the same thing.

Are you referring to Forth?  Yes, I will be adapting Mecrisp and will 
not deviate from the model currently used by Matthias.  For example, I 
will need to write code for managing the flash and will use the same 
words he used if possible.  But it is likely I won't find words for many 
of the things I end up doing.  These will be new.

If you mean common to Auduino, I don't know Arduino and am not likely to 
be reading the docs to try to use similar routines.  I have looked at 
Arduino a bit and didn't find it so clear, but that is likely because I 
wasn't familiar with the language.  I ended up asking for help with some 
library stuff and a few programmers who weren't familiar with Arduino 
couldn't tell if it was C++ or some other language, lol.  Does Python 
look like C++?


>>> 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.
>
> "hiding details" is not always with the goal to hide information. I once
> wrote a POCSAG encoder for arduino (or plain C++ if you like). The API
> is just one call "create message", but the code itself is freely
> available on github and it probably contains as much lines comments
> explaining the POCSAG format then actual code implementing it.
>
>
> But, as said, the point is that the large majority of people do not
> really care about all this.
> The next exercise for the class is a project to drive a antenne-motor
> (based on information received from a PC).
> You know, these people do not care about the USARTDIV or PORTAMOD
> registers or or interrupt service routines for the USART or the ADC,
> they joint want to have something that works: i.e. point the antenne to
> the direction of the remote station they want to reach.

A loop antenna any chance?  I've been learning about them and they seem 
very interesting.  I don't even have a Ham license, but I'm thinking 
about getting one so I can experiment with transmitting loop antennas.


> I know of at least two people who had started out with AVRs and PICs
> years ago but had given up because it was "to much work" having to dig
> through pages of datasheets and programming-manuals and to code all
> these details.
> But using the high-level APIs of arduino, mbed and what else have you,
> they are again into microcontrollers. At least now, they can spend most
> time working on the project they want to achieve and not all this
> low-level stuff.

Yes, that is why Arduino is so popular.


>>> - 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.
>
> OK, kind of found part of that.
>
> I'm still kind of confused on how to get the interrupt-service-routine
> and the other threads communicate with eachother without having to use
> global data.

I haven't gotten that far with Mecrisp.  One of my goals is to write 
some documentation for Mecrisp.  But first I have to learn it.  lol

-- 

Rick

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

#43219

Hi Rickman,



On 03-11-15 17:12, rickman wrote:
> If you mean common to Auduino, I don't know Arduino and am not likely to
> be reading the docs to try to use similar routines.  I have looked at
> Arduino a bit and didn't find it so clear, but that is likely because I
> wasn't familiar with the language.  I ended up asking for help with some
> library stuff and a few programmers who weren't familiar with Arduino
> couldn't tell if it was C++ or some other language, lol.  Does Python
> look like C++?


That is true.

But, in essence, that is not that bad. Most of these people would 
otherwize not be using microcontrollers if it was not for the 
ease-of-use of the arduino enviroment.

If you want more info on writing libraries, github is probably a better 
place to look.


In fact, the original arduino enviroment is a combination of C++, the 
"processing" enviroment, a library called "wiring" and the arduino 
bootloader. Add to the arduino board itself, the formfactor of the 
shields, the frizling enviroment for documentating designs and ... 
probably the most important, the fact that everything was thrown on the 
internet as open source.




>> But, as said, the point is that the large majority of people do not
>> really care about all this.
>> The next exercise for the class is a project to drive a antenne-motor
>> (based on information received from a PC).
>> You know, these people do not care about the USARTDIV or PORTAMOD
>> registers or or interrupt service routines for the USART or the ADC,
>> they joint want to have something that works: i.e. point the antenne to
>> the direction of the remote station they want to reach.
>
> A loop antenna any chance?  I've been learning about them and they seem
> very interesting.  I don't even have a Ham license, but I'm thinking
> about getting one so I can experiment with transmitting loop antennas.


This project just talks to a antenne motor controller. It just drives a 
motor to rotate any antenne you happen to have on your mast.


For magnetic loop antennas, the main issue is tuning it. Using a 
loop-antenne to receive is easy but if you want to transmit, you have to 
make sure it is correctly tuned to the frequency on which you want to 
transmit.
As a magnetic loop antenne is very narrow-band, you actually need to 
return it while you are changing frequency in the same band.


We once did an analysis of a automatic loop-antenna tuning system 
somebody made (and for which the code was available). It worked pretty 
well, even in the not so easy enviroment of having high-power RF that 
close to the PIC controller.


Althou radio by itself has a particular "magical" aspect to it, I 
concider it also very interesting as an "add-on" for other hobbies. Last 
year, we had people who where into electronics, networking, 
high-altitude ballooning, signal-processing (DSP, SDR, ...), robotics, 
quadcopters, etc.

I do not know where you are located, but if you happen to visit FOSDEM 
in Brussels on the 30 and 31 of January (https://fosdem.org/2016/), we 
will probably have our infobooth on ham-radio this year again.



Cheerio! Kr. Bonne  (ON1ARF)

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

#43230

On 11/4/2015 8:06 AM, kristoff wrote:
> Hi Rickman,
>
>
>
> On 03-11-15 17:12, rickman wrote:
>> If you mean common to Auduino, I don't know Arduino and am not likely to
>> be reading the docs to try to use similar routines.  I have looked at
>> Arduino a bit and didn't find it so clear, but that is likely because I
>> wasn't familiar with the language.  I ended up asking for help with some
>> library stuff and a few programmers who weren't familiar with Arduino
>> couldn't tell if it was C++ or some other language, lol.  Does Python
>> look like C++?
>
>
> That is true.
>
> But, in essence, that is not that bad. Most of these people would
> otherwize not be using microcontrollers if it was not for the
> ease-of-use of the arduino enviroment.
>
> If you want more info on writing libraries, github is probably a better
> place to look.
>
>
> In fact, the original arduino enviroment is a combination of C++, the
> "processing" enviroment, a library called "wiring" and the arduino
> bootloader. Add to the arduino board itself, the formfactor of the
> shields, the frizling enviroment for documentating designs and ...
> probably the most important, the fact that everything was thrown on the
> internet as open source.
>
>
>
>
>>> But, as said, the point is that the large majority of people do not
>>> really care about all this.
>>> The next exercise for the class is a project to drive a antenne-motor
>>> (based on information received from a PC).
>>> You know, these people do not care about the USARTDIV or PORTAMOD
>>> registers or or interrupt service routines for the USART or the ADC,
>>> they joint want to have something that works: i.e. point the antenne to
>>> the direction of the remote station they want to reach.
>>
>> A loop antenna any chance?  I've been learning about them and they seem
>> very interesting.  I don't even have a Ham license, but I'm thinking
>> about getting one so I can experiment with transmitting loop antennas.
>
>
> This project just talks to a antenne motor controller. It just drives a
> motor to rotate any antenne you happen to have on your mast.
>
>
> For magnetic loop antennas, the main issue is tuning it. Using a
> loop-antenne to receive is easy but if you want to transmit, you have to
> make sure it is correctly tuned to the frequency on which you want to
> transmit.
> As a magnetic loop antenne is very narrow-band, you actually need to
> return it while you are changing frequency in the same band.
>
>
> We once did an analysis of a automatic loop-antenna tuning system
> somebody made (and for which the code was available). It worked pretty
> well, even in the not so easy enviroment of having high-power RF that
> close to the PIC controller.
>
>
> Althou radio by itself has a particular "magical" aspect to it, I
> concider it also very interesting as an "add-on" for other hobbies. Last
> year, we had people who where into electronics, networking,
> high-altitude ballooning, signal-processing (DSP, SDR, ...), robotics,
> quadcopters, etc.
>
> I do not know where you are located, but if you happen to visit FOSDEM
> in Brussels on the 30 and 31 of January (https://fosdem.org/2016/), we
> will probably have our infobooth on ham-radio this year again.

I would certainly consider that, but I don't swim as well as I used to. 
  I"m in the US.

-- 

Rick

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

#42753

Hi Kristoff,

have a look into the common folder and the other STM targets already supported in Mecrisp-Stellaris. You simply use a chip that has got little attention so far, but there are many similiarities between STM chips, so that this will give you hints. GPIO examples are there for your chip, ADC and DAC are ready for other chips. Somewhere is a SPI-bit-bang implementation, but all this you are asinkg for are just peripheral bit wigglers. I included everything I know of into the package, and Reginald Beardsley measured GPIO characteristics for STM32F407. http://sourceforge.net/p/mecrisp/home/STM32F4-tst1/

Multitasking is available as Forth source in the common folder.

For everything else, you need to dive into the datasheets and find out which bits to set in which register to make the chip do what you desire. Do not forget to send me your results for the mainstream release ! I am just out of time writing examples for various chips each with their various peripherals all at my own. Currently, I am busy with developing a stronger optimizing compiler which can hold the top five elements in registers.

By the way, I am not here on comp.lang.forth too often, so feel free to contact me via E-Mail if you wish a quicker response.
Matthias


> 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] | [prev] | [next] | [standalone]

#42756

Hallo Mathias,




On 22-10-15 11:13, Matthias Koch wrote:
> Hi Kristoff,
>
> have a look into the common folder and the other STM targets already
> supported in Mecrisp-Stellaris. You simply use a chip that has got
> little attention so far, but there are many similiarities between STM
> chips, so that this will give you hints. GPIO examples are there for
> your chip, ADC and DAC are ready for other chips. Somewhere is a
> SPI-bit-bang implementation, but all this you are asinkg for are just
> peripheral bit wigglers. I included everything I know of into the
> package, and Reginald Beardsley measured GPIO characteristics for
> STM32F407. http://sourceforge.net/p/mecrisp/home/STM32F4-tst1/

Yes, I started looking into that code. Thanks!


As mentioned in message to Rick, I looked at this from a higher-level.

Compairing this with the arduino-platform, the big advantage of that 
platform is not only that application-level programmers can just use the 
high-level APIs (and does not need to deal with the "bit-fiddling" 
code), but also that the API is actually standardised across platforms 
and IDEs.

This makes sharing code much easier which really helps the "open source" 
element of all this.



> Multitasking is available as Forth source in the common folder.

Hmm. Didn't see that. I must have looked over it. My appologies.




> For everything else, you need to dive into the datasheets and find out
> which bits to set in which register to make the chip do what you desire.
> Do not forget to send me your results for the mainstream release ! I am
> just out of time writing examples for various chips each with their
> various peripherals all at my own. Currently, I am busy with developing
> a stronger optimizing compiler which can hold the top five elements in
> registers.

As I see it, there are two elements in here that could nicely run next 
to eachother: low-level optimizing the code and implementing a standard 
API for basic functions.

Either can be done by different people.

And, if you have a standard platform and the code is open-source, it can 
probably be used as "template" for other microcontrollers!.
This would allow other people to implement the same code for other 
microcontrollers.



> By the way, I am not here on comp.lang.forth too often, so feel free to
> contact me via E-Mail if you wish a quicker response.

No problem. I just do this when I have a little bit of time. It's a nice 
way to get to learn more how a microcontroller actually works.


BTW. I did manage to get the "switch MCU to 72 Mhz" code (in 
assembly-language) running.  (althou the code is not good enough, I 
still need to find out how to return data from a function in 
assembly-language so I can indicate if the switch to 72 Mhz has 
successeeded or not).

Anycase, my first ever ARM assembly-code! YES! :-)


> Matthias
Cheerio! Kr. Bonne.

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

#42757

Hi Kristoff,

comparing to Arduino, there is one main difference:

Arduino already has collected many libraries and contributions,
Mecrisp, Mecrisp-Stellaris and Mecrisp-Ice are going to collect many contributions.

I will focus on porting, compiler design and low-level optimisations and
I collect Forth examples others write for their favourite chips.

> And, if you have a standard platform and the code is open-source, it can 
> probably be used as "template" for other microcontrollers!.
> This would allow other people to implement the same code for other 
> microcontrollers.

I use the chip that is closest to the new one as template for porting,
unfortunately, there is few in common across manufacturers.

You'll see in other posts that unifying attemps on Forth may soon run into trouble.

Start with something small:
Writing unified SPI code for all STM targets of Mecrisp-Stellaris seems possible.

Currently, I use this interface for bit-banged SPI:

init-spi ( -- )
spix ( c -- c )
>spi ( c -- )
spi> ( -- c )

But clock polarity, edges and other specialities are configured by changing the
init-spi code for every new occurence. Chip select wires cannot be unified.

Just find out how SPI peripheral in STM chips work.

> BTW. I did manage to get the "switch MCU to 72 Mhz" code (in 
> assembly-language) running.  (althou the code is not good enough, I 
> still need to find out how to return data from a function in 
> assembly-language so I can indicate if the switch to 72 Mhz has 
> successeeded or not).

Put it on the stack:

subs psp, #4
str tos, [psp]
movs tos, result

> Anycase, my first ever ARM assembly-code! YES! :-)

That is truly cool ! Congratulations !

Matthias

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web