[En-Nut-Discussion] Ethernut on TI's Cortex-M3 (Stellaris LM3S...)

[Uwe Bonnes]

>>>>> "Philipp" == Philipp Burch <phip at hb9etc.ch> writes:
    Philipp> I've now started to update the directory structure and the
    Philipp> headers.  Please find attached the Git bundle containing the
    Philipp> changesets which I've made so far. 

There was nothing attached to the mail on the list. Perhaps send private
mail

    Philipp> I still need to get used to
    Philipp> using Git, so never mind if a changeset may look weird or
    Philipp> misses a file. My working copy is clean now, so at least the
    Philipp> last changeset should include everything.  I'd greatly
    Philipp> appreciate if someone could have a look at it and tell me if it
    Philipp> is basically correct what I'm doing. And if it adheres to the
    Philipp> Ethernut standards (if there are any).

I will try to have a look, but there are millions of "correct ways" and
zillions of ways with obstacle. One test is that at least your changes dont'
break any other build, the next step is that your changes build on a foreign
system.

    Philipp> And them something specifically @Ole:

    Philipp> Most parts of the headers are fairly self-explaining, but two
    Philipp> locations confused me so far. Both are related to the
    Philipp> clocking. The first one is the _clk.h (e.g. stm32_clk.h in
    Philipp> nut/include/arch/cm3/stm):

Thes number and names are STM32 specific.  Let me explain with a look at the
LM4F120H5QR, August 29, 2012 page 217 Fig 5-5 and the ST reference manual for
the STM32F4 familiy RM0090 ( Doc ID 018909 Rev 1,  File download
DM00031020.pdf) page 83 Figure 9. Both figures show the clock tree.
The numbers are used to identify the clock sources feeding the CPU. They
might be
 - SYSCLK_HSE : High Speed External quartz or external clock feeds the CPU
 - SYSCLK_HSI : High Speed internal esxillator feeds the CPU
 - SYSCLK_PLL : PLL feeds the CPI

The PLL itself can be feed from HSE or HSI.

For LM4 HSE is "Main OSC", HSI is "  Precision Internal OSC" and there is
also the PLL. Probably is is good to use the similar names as used in the
peripheral library heades


    Philipp> /* STM32F Clock source selectors */ #define SYSCLK_HSI 0
    Philipp> #define SYSCLK_PLL 1 #define SYSCLK_HSE 2 #define PLLCLK_HSI 3
    Philipp> #define PLLCLK_HSE 4


    Philipp> What are these numbers for? Are they something STM32-related,
    Philipp> or should these be present on all Cortex-M3? The other looks
    Philipp> similar and is in nut/include/arch/cm3/timer.h:

    Philipp> #define NUT_HWCLK_EMC 2

    Philipp> /*!  * Clock for USB */ #define NUT_HWCLK_USB 3

    Philipp> /*!  * Clock for WDT */ #define NUT_HWCLK_WDT 4

    Philipp> ... and so on

    Philipp> Again, what do these numbers stand for? This time it can't be
    Philipp> specific to one single Cortex-M3 architecture, as it is in a
    Philipp> generic file and the same defines are present for different
    Philipp> families.

I don't know if there are users of theses definitions yet. But the thought
is to have perhaps a generic EMAC driver and then say " turn on
NUT_HWCLK_EMC" and not have a to say
# if defined(STM32_F$4)
turn on RCC_AHB1ENR bit ETHMAC_EN
#elif defined (LM4)
turn on LM4 related bits
#elsif
...
#endif

    Philipp> Generally: How is the clocking handled in Ethernut? 

For the STM32 with a given frequency of the external clock and the macros 
SYSCLK_PLL/PLLCLK_HSE I try to reach the maximum allowed frequency. If wee
need to conserve energy, we then can sleep in the idle thread at the cost
possible delay between interrupt handler and interrupt bootom half running
in the thread context. There was a discussion some weeks ago about that.

Runntime frequency switching is another case, not yet abstracted...

    Philipp> Is there a document explaining this?

I don't know of any yet.

    Philipp> I'd expect something like SetClock()
    Philipp> to which I'd pass some params to define how the device is
    Philipp> clocked, but this seems to be handled differently.

stm32f4_clk.c e.g. has "int SetSysClock(void)". As setting the sysclock
happens at startup, there is no input device yet to give
arguments to SetClock(). So SetSysClock(void) is configured with macros
derived from the board.conf file. Macros also have the advantage of
resulting in smaller code, as a lot of calculations are done at compile
time, not at run time. 

Enough for now.

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------