Hi,
Let me first explain a little bit of the background.
My aim is to port an arduino library ("SPIFlash",) as I eed it to flash
Winbind NOT flash memory modules. This device is used in the olimex
ice40 FPGA development board.
Once that is done, I can port the code for programmer itself.
The idea is to write the "SPIFlash" library (in C++) as a standalone
library so it can then be used for other projects too. (just like
arduino libraries are independant software components from whatever
application somebody else build on top of them).
The problem is that both the library and the application need functions
like "delay_ms" or "millis". The library also needs us delay-loops.
This creates two problems:
- The us-delay is just a number of "nop" asm-commands in a for-loop.
The number of loops you need are dependent on the speed of the CPU, ...
which means that writing "generic" code must involve knowing the actual
clock-rate the processor is running at.
- The delay_ms and millis (used for timeout detection) use the systick
interrupt (based on your code, thx! :-) ), which require the
systick-setup code.
(BTW. I have created a C++ class to be able to handle timeticks from
both the main application and the library code at the same time.)
The problem here is that "systick init" depends on clockspeed of the CPU
(to calculate the correct reload-value for systick).
Now, in general, if the C++ object of the library is placed in the
"global" context of the application code, it will be created before you
execute the "main" function. At that point, the CPU runs (I think) at 8 Mhz.
So, if the main application then changes the clock speed from 8 Mhz to
72 Mhz, something is needed to correct the reload-value in the systick
configuration.
I have the impression that libopencm3 has some when writing
self-contained "generic" libraries.
I do not know if libopencm3 is still being further developed , but one
feature that -I think- would be nice is a way for libraries to get
information (in real time) from the device: "what cpu am I running on",
"what is the current cpu clock-rate", "how much RAM memory is
available?", ...
Perhaps this:
- we define a number of gloval system-wide "parameters" ( clock-speed, ...)
- provide an API that can just set or read the value of these parameters.
In my example:
- Concider a system-wide parameter "clockspeed".
- in "rcc_clock_setup_in_hse_8mhz_out_72mhz" (or whatever other function
that can be used to change the clockrate of the CPU), execute "set
systeminfo clockspeed = 72000000"
- An application or library that needs to know the clock-speed, you can
just call "get systeminfo clockspeed", to retrieve the value of that
parameter.
Or does such a mechanism already exist?
Cheerio! Kr. Bonne.
On 17-04-17 03:40, Chuck McManis wrote:
> Short answer is 'maybe.'
>
> You can see how the clock tree is set up by reading the RCC_CFGR
> registers. *If* it is set to use an internal clock (say HSI or MSI) you
> can can calculate the speed based on how the registers are set up. If
> however it is using an external crystal (HSE) you can't really know what
> the speed is. ARM suggests in their CMSIS spec that you maintain a
> global variable that has the clock speed in it.
>
> In my clock utility code (which has shown up several times in a variety
> of the examples directories) I have a msleep(t) function which sleeps
> for 't' milliseconds sort of. It uses the SysTick timer and it counts
> ticks but if you wanted to wait for 1 millisecond you calling it you may
> wait for anywhere between .001 and 1 mS depending on where in the count
> you caught it. So for delays the accuracy is 100/length percent (10
> percent for a 10mS pause, 1% for a 100mS pause, etc).
>
> For much more accurate delays (and you still need to know what the core
> clock is) you can set a timer and then execute a WFI (wait for
> interrupt) instruction. That will move to the next instruction on return
> from interrupt. Of course if the interrupt *wasn't* your timer you
> should probably go back to sleep, and if you call WFI *after* the
> interrupt has fired you will wait forever. The alternative is to simply
> busy wait on the interrupt flag while not worrying about it firing..
> Then at least you always proceed, but if you take an interrupt while
> waiting for something like reading a serial character or dealing with
> USB your delay again may be messed up.
>
> Does that help?
> --Chuck
>
>
> On Sun, Apr 16, 2017 at 4:39 PM, kristoff
> <krist...@skypro.be
> <mailto:krist...@skypro.be>> wrote:
>
> Hi,
>
>
> I may be wrong but -as far as I see it- there is no "delay_ms" (or
> equivalent) in libopencm3.
>
>
> I started doing some more work on my FPGA programmer on a STM32F103 and
> -to port the arduino library to libopencm3- I need both the "delay_ms"
> and "millis" functions.
> Therefor I am working on a generic library for this, using the cortex-M
> "systick" interrupt.
>
>
> Question:
> As the reload-value used by systick is directly related to the
> clockspeed of the CPU, is there in libopencm3 a generic way to determine
> the clockspeed of the CPU?
> My goal is to determine if the speed of the CPU has been changed.
>
>
> For the STM32, I found there are a number of external variables that I
> might use (rcc_ahb_frequency, rcc_apb1_frequency and rcc_apb2_frequency)
> but I guess these are specific for that processor.
>
>
> Cheerio! kr. Bonne.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> libopencm3-devel mailing list
> libopencm3-devel@lists.sourceforge.net
> <mailto:libopencm3-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
> <https://lists.sourceforge.net/lists/listinfo/libopencm3-devel>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> libopencm3-devel mailing list
> libopencm3-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
