Timer interrupt - brainstorming

All things embedded.
*NO FEATURE REQUESTS*

Timer interrupt - brainstorming

Postby Vicne » Sun Mar 18, 2012 3:51 pm

Hi, all,

I had a very interesting discussion with McGyver the other day about this project (one should always ask McGyver :-)), and here's what he told me.
In any OS, and certainly in Real Time OSes, the key for successful task switching is to have tasks put on hold at regular interval to distribute timeslices to each running task.
That is the role of one (or multiple) timers, and those must fire interrupts (timer interrupts) at regular interval so that heart beat is given to the beast.
In the current state, I still have no idea what interrupt(s) handle timers, so I think I will start working on those in a separate thread

In the meantime, if you have any information about which interrupt is usually linked to timers in Fujitsu microcontrollers, or if you have any timer-related information, please post it here...

Best regards,

Vicne
Vicne
Core Developer
 
Posts: 1703
Joined: Tue Nov 29, 2011 2:30 pm
Been thanked: 155 times

Re: Timer interrupt - brainstorming

Postby tagrefantom » Sun Mar 18, 2012 4:21 pm

tagrefantom
 

Re: Timer interrupt - brainstorming

Postby Vicne » Mon Mar 19, 2012 12:59 pm

tagrefantom wrote:FR-80 prog manual:
http://edevice.fujitsu.com/fj/MANUAL/MA ... 158-1E.pdf


Edit : by the way, did you choose the FR-80 for a reason. What makes you think this chip is similar to the Expeed ?



Thanks for the links. I had already taken a look at some them.

In long-term it would probably best to use softune with realos + tools/libraries.


Well, two questions :
- Softune was surely used for writing the firmware, but can it disassemble a compiled file without having any source ?
- Is Softune free ? Do you own a license to help debugging ?

Best regards,

Vicne
Vicne
Core Developer
 
Posts: 1703
Joined: Tue Nov 29, 2011 2:30 pm
Been thanked: 155 times

Re: Timer interrupt - brainstorming

Postby Vicne » Tue Mar 27, 2012 11:13 am

Still digging how timer interrupt works...
Thanks to the progress made after following leegong's pointer to the REALOS kernel manual (should have RTFM sooner :oops: ), we now have a much clearer view of system calls.
I thought it would be interesting to follow the System Clock related calls, because as stated in section 2., the system clock is run by the hardware interrupt timer ticking every millisecond, so that should lead us to that interrupt.

So let's start with the set_tim() call described at paragraph 4.8.1. which takes as parameter a pointer (R4) to a 64-bit structure representing the time to set. Its 16 highest bits are unused, and the 48 lower ones count milliseconds since jan 1st, 1985.

In the D5100, its implementation goes :
Code: Select all
  1. 000410E8  8B4E                         MOV     R4,FP

  2. 000410EA  4015                         LDUH    @(FP,0x02),R5

  3. 000410EC  2016                         LD      @(FP,0x004),R6

  4. 000410EE  8B57                         MOV     R5,R7

  5. 000410F0  B107                         LSR     #16,R7

  6. 000410F2  E444                         BC      part_2_of_unknown_410e6_              ; (skip)

  7. 000410F4  83EF                         AND     #0xEF,CCR

  8. 000410F6  9F8E 6800 0910               LDI:32  #0x68000910,FP

  9. 000410FC  3016                         ST      R6,@(FP,0x004)

  10. 000410FE  3005                         ST      R5,@(FP,0x000)

  11. 00041100  9310                         OR      #0x10,CCR

  12. 00041102  9F20                         RET:D  

  13. 00041104  C00C                          LDI:8  #0x00,R12

  14. part_2_of_unknown_410e6_:

  15. 0004117C  9F20                         RET:D  

  16. 0004117E  CDFC                          LDI:8  #0xDF,R12



In other words, the 16+32 bits pointed to by R4 are stored to addresses 0x68000910 / 0x68000914.
To make sure values are consistent, the calls are protected inside a "synchronized" block, as interrupts are disabled before (AND #0xEF,CCR) and reenabled after (OR #0x10,CCR) modifying the value.

The get_tim() at 0x41106 is the exact symmetric, reading back 0x68000910 / 14 in a synchronized block and writing the value back to the passed structure.

That address, 0x68000910 is also used by sys_def_alm(), which sounds logical, but also by sub_40c4e_() which starts with :
Code: Select all
  1. ; ************************************************************************

  2. ; sub_40c4e_()

  3. ; ************************************************************************

  4. 00040C4E  1781                         PUSH    RP

  5. 00040C50  170E                         PUSH    FP

  6. 00040C52  9F8E 6800 0910               LDI:32  #0x68000910,FP

  7. 00040C58  83EF                         AND     #0xEF,CCR

  8. 00040C5A  C003                         LDI:8   #0x00,R3

  9. 00040C5C  2006                         LD      @(FP,0x000),R6

  10. 00040C5E  2017                         LD      @(FP,0x004),R7

  11. 00040C60  A417                         ADD     #0x1,R7

  12. 00040C62  A736                         ADDC    R3,R6

  13. 00040C64  3017                         ST      R7,@(FP,0x004)

  14. 00040C66  3006                         ST      R6,@(FP,0x000)

  15. 00040C68  9310                         OR      #0x10,CCR

  16. ...



How interesting : the clock value is read into R6 (higher) and R7 (lower), R7 is incremented and its carry bit is added to R6, and the clock gets written back.
So obviously this is the code incrementing the system clock and it is called by... int_0x18

Sounds like we can make that clock tick :-)

Best regards,

Vicne
Vicne
Core Developer
 
Posts: 1703
Joined: Tue Nov 29, 2011 2:30 pm
Been thanked: 155 times

Re: Timer interrupt - brainstorming

Postby Vicne » Tue Mar 27, 2012 11:53 am

Vicne wrote:Sounds like we can make that clock tick :-)

Hmmm.

The clock ticks, we see structures live in memory, but still nothing on emulated screen...
http://screencast.com/t/EGnLaYGuWB7o

Vicne
Vicne
Core Developer
 
Posts: 1703
Joined: Tue Nov 29, 2011 2:30 pm
Been thanked: 155 times

Re: Timer interrupt - brainstorming

Postby Simeon » Tue Mar 27, 2012 12:33 pm

Nice find.
Simeon
Core Developer
 
Posts: 2103
Joined: Wed Nov 30, 2011 6:12 am
Location: Christchurch, New Zealand
Been thanked: 398 times

Re: Timer interrupt - brainstorming

Postby Simeon » Wed Mar 28, 2012 10:33 am

Also 4065E time, gets the DWORD ltime from 68000914, and is used in lots of places. Which makes it the equivalent to the C time function.
Simeon
Core Developer
 
Posts: 2103
Joined: Wed Nov 30, 2011 6:12 am
Location: Christchurch, New Zealand
Been thanked: 398 times

Re: Timer interrupt - brainstorming

Postby Vicne » Sat Mar 31, 2012 9:03 am

I'm trying to understand how the "task dispatching" works. As far as I can tell, it could well be that everything is done in 40c4e MillisecondTimer() called by int_0x18.
Trying the code "live", it seems to do nothing as long as the three following conditions are true :
@(0x68000918) = 0x68000918
@(0x68000920) = 0x68000920
@(0x68000928) = 0x68000928
(!)
which is always the case.

I guess the dispatcher doesn't have any task waiting to be executed because nothing has called a sta_tsk yet, so it just keeps waiting.

Now how does sta_tsk get called ?

Vicne
Vicne
Core Developer
 
Posts: 1703
Joined: Tue Nov 29, 2011 2:30 pm
Been thanked: 155 times

Re: Timer interrupt - brainstorming

Postby Simeon » Sat Mar 31, 2012 9:20 am

68000918 is access from a sub int_3f, and a sub-function of sys_wup_tsk and sys_dly_tsk, and used directly by sys_tslp_tsk and sys_dly_tsk.
Simeon
Core Developer
 
Posts: 2103
Joined: Wed Nov 30, 2011 6:12 am
Location: Christchurch, New Zealand
Been thanked: 398 times

Re: Timer interrupt - brainstorming

Postby leegong » Tue Apr 03, 2012 1:03 am

Vicne wrote:I'm trying to understand how the "task dispatching" works. As far as I can tell, it could well be that everything is done in 40c4e MillisecondTimer() called by int_0x18.
Trying the code "live", it seems to do nothing as long as the three following conditions are true :
@(0x68000918) = 0x68000918
@(0x68000920) = 0x68000920
@(0x68000928) = 0x68000928
(!)
which is always the case.

I guess the dispatcher doesn't have any task waiting to be executed because nothing has called a sta_tsk yet, so it just keeps waiting.

Now how does sta_tsk get called ?

Vicne

As described in Softune User's Guide chapter 2.8,"When running, REALOS/FR requires a timer device that can generate interrupt signals
at a typical interval of 1 millisecond for use as a system clock."
So,i think INT0x18 is the "missed" block we are looking for ,
I guess INT0x18 should be triggered once every 1ms after PC=0x40618,if so ,the three conditions you mentioned are not satisfied
at the beginning.
leegong
Core Developer
 
Posts: 1612
Joined: Mon Mar 19, 2012 12:21 am
Been thanked: 113 times

Next

Return to Firmware

Who is online

Users browsing this forum: No registered users and 5 guests