The RTC driver topic

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

The RTC driver topic

Postby barthess » Wed Aug 24, 2011 6:32 pm

From Todo list:
- New device driver models: Clock, Systick, RTC, WDG, DAC, Power Monitor.

I use RTC in my project and can create hi level driver and low level part for STM32F1xx.
What interface must provide the driver? In my opinion:
- Init,
- Set,
- Get,
- one second callback.
Any more suggestions?

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: RTC driver

Postby Giovanni » Wed Aug 24, 2011 6:45 pm

Thanks, excellent idea.

I would say two ways to get the date/time DOS and Unix like. The DOS time is required by FatFs so it could be used immediately, the Unix way is more accurate.

Another idea is to abstract a "safe storage", most RTCs have backup RAMs.

Giovanni

User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

Re: RTC driver

Postby barthess » Wed Aug 24, 2011 7:26 pm

Unix way will be mandatory. Fraction part of seconds will be available too.
Dos time for FatFS (if need) can be computed from unix time using functions from <time.h>.

Another idea is to abstract a "safe storage"

It is in my plans too. Are there any similar systems in ChibiOS to looking for interface?

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: RTC driver

Postby Giovanni » Wed Aug 24, 2011 8:07 pm

You could subclass BaseFileStream into PersistentMemoryStream, users would use it as a file. Write operations would "sign" the buffer (with a checksum or a CRC), read operation would verify the signature in order to ensure consistency.

Working with streams has the advantage to be consistent with anything we put in the system.

Giovanni

User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

Re: RTC driver

Postby barthess » Wed Aug 31, 2011 7:42 am

What's done and tested with LSE clock source: init, set, get.
Done but currently not tested: ISRs and callbacks.
In plans: alarm wake up from deep sleep.

Is there interface in ChibiOS to handle with power saving / stand by modes of STM32 mcu? That will be nice to use in combo with alarm function.
Where is better to place settings like clock source, clock frequency etc.?

About backup RAM. Accessing to it in BaseFileStream manner not applicable because it is not solid - 16bit registers aligned to 32bit addresses (sic!). Any ideas?

Anybody can checkout and test rtc_dev branch.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: RTC driver

Postby Giovanni » Wed Aug 31, 2011 8:01 am

Good job,

Few notes:

- STM32_LSECLK is already defined in board.h because it is something that can change from board to board. Any clock-related setting should be in hal_xxx.h as usual.

- There is not a a power management for the STM32 yet, I have been thinking to some kind of driver abstraction over deep sleep modes. It is in the to-do list scheduled for post 2.4.x but we could move it in 2.3.x. The driver would have a single call pwrGoToSleep(mode), it would stop things depending on the selected mode then enter the deep sleep mode. The call would never exit.

- BaseFileStream can be used, the stupid memory organization can be hidden to the user that would see just a stream the stream implementation code would make the conversion "stream offset"<->"memory organization".

Anyway there is no need to rush, 2.3.x will last for a while, at least whole 2011, so there is still time to add desirable features, 2.2.x stable will be maintained much longer than usual because commercial requirements.

Giovanni

User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

Re: RTC driver

Postby barthess » Wed Aug 31, 2011 6:42 pm

Callbacks tested, awaking from deep sleep tested.
Waking up from deep sleep looks amazing for me. It really works.

Now it's time to set up runtime system checks, but this is some kind of black magic for me.
Look in documentation:
I-Locked. Kernel locked and regular interrupt sources disabled. I-Class APIs are invokable from this state.

now find I-Class:
"I", I-Class APIs are invokable only from the I-Locked or S-Locked states. See System States.

Hmm... what the differences between invokable and non invokable code? What instructions (or coding technique, or statements) are forbidden in invokable code?

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: RTC driver

Postby Giovanni » Wed Aug 31, 2011 7:32 pm

Not all system functions are usable in a given context.

The most restrictive type are the i-class, an I-class function is a function that must:
- Not access the "current" thread in any way (from an ISR the current thread is random so it is meaningless).
- Not reschedule internally (from an ISR the reschedule is done at the end of the ISR chain, rescheduling from within an ISR is forbidden because would leave the IRQ stack not empty with all kind of funny consequences.
- Not try to change state for the current thread.
- Must be invoked between a lock() and an unlock() but never lock/unlock internally.

A bit less restrictive are the S-class that must simply:
- Be invoked between a lock() and an unlock() but never lock/unlock internally.
S-class can reschedule internally, access the current thread implicitly and also change state so are not eligible for ISR context.

Normal functions can be invoked from thread context only but have no internal restrictions.

The newly implemented checker makes sure that functions are invoked from the correct context only. This greatly reduces the possibility of writing incorrect RTOS-related code.

Giovanni

User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Location: Minsk, Belarus
Been thanked: 7 times

Re: RTC driver

Postby barthess » Fri Sep 02, 2011 2:14 pm

Hi all.
RTC driver merged to trunk. It is ridiculously simple in compare to my first driver (I2C). Usage examples you can find in testhal\STM32F1xx\RTC. Any questions and suggestions post here.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: RTC driver

Postby Giovanni » Fri Sep 02, 2011 5:10 pm

Excellent,

I will try to generate the documentation and make a general sanity check tomorrow. My next steps regarding drivers will be:
- Finalization of the USB driver model (there are pending suggestions in the USB thread).
- Improvements to the MAC driver model and native STM32 implementation.

BTW, you picked up the worst one as "first driver"...

Giovanni


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 10 guests