Hi Chuck,
I just want to show how I see things from a point-of-view of porting libraries. One of the reasons why the arduino is so succesfull is the large amount of libraries available for the platform. The same thing for mbed (I use it for a some NXP-based boards that I have). People are much more drawn towards a platform if they know that they can use preexisting libraries and they do not need to implement all that themselfs. I like libopencm3 and it's a very good library .. but -how I see it- it's really focused on a development model where one person / group writes the complete application. It's a good tool to -say- make a specific project (say, my FPGA programmer), but not that well suited to write a part of that same code (say the winbond NOR flash programmer) in such a way that it can easily reused by others (and it therefor helps the openall libopencm3 community). If you want libopencm3 to grow, I do propose that you try to look at that aspect too. Please provide the people who want to port a library to libopencm3 with the tools to do that. Kristoff On 17-04-17 21:23, Chuck McManis wrote: > Hi Kristoff, > > I think the extern uint32_t `rcc_ahbfrequency` is probably what you > want. Look at the source in > `./lib/stm32/*/rcc.c`, when the code is correctly written it sets that > value appropriately when > the clock speed is changed. But be aware that the RCC code is written by > many different > people in different 'families' of chip so it is not the same from one > family to the next. Verify > that the family you are targeting does the right thing. > > Secondly it is important to realize the libopencm3 is *not* an operating > system or even > an "environment", rather it is a very thin layer over the register > definitions in the data sheet > so everywhere it assumes that whomever is calling it is writing all of > the parts and so knows > all of the things that can vary (like clock speed). > > If you want a nice environment for Cortex M like Arduino where you can > publish modules > and many people can use them, I suggest you look at the "Mbed" (mbed.org > <http://mbed.org>) environment that ARM > does for these parts. > > Cheers, > --Chuck > > > On Mon, Apr 17, 2017 at 6:45 AM, kristoff <krist...@skypro.be > <mailto:krist...@skypro.be>> wrote: > > 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> > > <mailto: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> > > <mailto: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> > > <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 > <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 > <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
