sam7x- RTC - DS1307 ---interface

TWI doesn't really require any interfacing with any OS unless you move up to "PC-class" operating systems where your only access to hardware is through a driver.

In your case, you can use just about any TWI code for your specific processor. For most processors that have hardware support for it, it would be natural to use an interrupt-driven approach where you might have a send buffer and a receive buffer. Then you can use one of the OS primitives to signal a task whenever there is data available in the receive buffer.

Tasks that needs to send can insert data in the transmit buffer. Then it's required to check if the interface is active (so a future interrupt will draw data from the transmit buffer) or if you need to kick-start the transfer. That can also be done using a separate task that gets a signal everytime data have been added to the transmit buffer. Or it can be done by each calling task if you just have a critical section that protects many tasks from concurrently checking if TWI is active before deciding to kick-start the device.

TWI doesn't really require any interfacing with any OS unless you move up to "PC-class" operating systems where your only access to hardware is through a driver.

In your case, you can use just about any TWI code for your specific processor. For most processors that have hardware support for it, it would be natural to use an interrupt-driven approach where you might have a send buffer and a receive buffer. Then you can use one of the OS primitives to signal a task whenever there is data available in the receive buffer.

Tasks that needs to send can insert data in the transmit buffer. Then it's required to check if the interface is active (so a future interrupt will draw data from the transmit buffer) or if you need to kick-start the transfer. That can also be done using a separate task that gets a signal everytime data have been added to the transmit buffer. Or it can be done by each calling task if you just have a critical section that protects many tasks from concurrently checking if TWI is active before deciding to kick-start the device.

hello Per
Oh finally you make me help

Given that your help isnt good,
but Thank you very much for your Attention

i think keil library is very poor

in last time im work with Bascom-AVR , its library is very full.
Bascom make me very Lazy.

have nice time
your sincerely , Amir

I'm not sure that you can blame Bascom entirely for that...

hi,Andrew

You are right

Bascom is really OK,
I like it.
we work in our company with bascom now.
but in this time i want to introduction new controller to my employees,

i hope keil compiler complate its lib.

have nice time friend.
Amir

I think it's more likely to be your expectations that need revising.

Bascom is a very specific environment for just one specific target;
Keil is much more general-purpose and, therefore, cannot provide such fine-detail support for every conceivable different platform.

Yea,Andrew
you are fully right

when i thinking about keil's supported microcontroller, i go to clear , really right
i think support around 2~3000 different type of uC ,yea , this is very hard.

sorry for my bad english
but seem that keil can be lovely, have good support team.

i am thinking to make a forum for keil , interrest on Atmel product.

Can your team help me,

your sincerely,Amir