topic Re: MCF52259 time issue, and processing time in MQX Software Solutions

MCF52259 time issue, and processing time

carlnormansuret — Thu, 01 Sep 2016 02:24:06 GMT

Hi,

I have done a simple test on my processor as I am having some issues with things taking to long.

so I have found each of my "real time" issues and made a very simple block of code with comments showing how long things take.

One obvious issue I can see is that _time_delay(1) to _time_delay(9) all end up taking 10mS.

The other concern is just how long its taking to dump data into a buffer to send.

The code is very simple with comments showing how long each thing takes. I measured this in my DSO.

//Priority 6 task, release BSP/PSP version with optimization

void SDI_Task(uint_32)
{
UINT8 i = 0;

Shell_IO = (pointer)fopen("ittya:", (pointer) (IO_SERIAL_RAW_IO));

reg_ptr->GPIO.DDRUC |= 0b00000100; //Force to output state
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low

//Test 1 All of these pulses are exactly 10mS! instead of 1, 2, 3, 4, 5, 6mS
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
_time_delay(1);
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low
_time_delay(1);
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
_time_delay(2);
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low _time_delay(1);
_time_delay(1);
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
_time_delay(3);
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low
_time_delay(1);
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
_time_delay(4);
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low
_time_delay(1);
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
_time_delay(5);
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low
_time_delay(1);
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
_time_delay(6);
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low

_time_delay(50); //This delay takes about 54mS

//Test 2 this takes ~815uS to "buffer" up ~90 chars. this processors bus is supposed to be running at 80Mhz, and 76MIPS, so about 65,200 bus clocks to buffer up 90 chars...
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
fprintf(Shell_IO, "starting this long test that should not take to long ay, because it should just continue\n");
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low

_time_delay(50);

//Test 3 this takes 7.8mS which is about right for transmitting 90 chars on 115200baud on ittya
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
fprintf(Shell_IO, "starting this long test that should not take to long ay, because it should just with ff \n");
fflush(Shell_IO);
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low

_time_delay(50);

//Test 4 This takes about 71.5mS to format and print around 1300 chars, so thats about 5.7 Million bus clocks... About 4400 clocks per char...
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
for(i = 0; i != 0xFF; ++i)
{
fprintf(Shell_IO, " 0x%02X", i);
}
fprintf(Shell_IO, "\n\n");
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low

_time_delay(50);

//Test 5 this takes about 112mS which is about right on for 1300 chars printed
reg_ptr->GPIO.PORTUC |= 0b00000100; //Force to output to high
for(i = 0; i != 0xFF; ++i)
{
fprintf(Shell_IO, " 0X%02X", i);
}
fprintf(Shell_IO, "\n\n");
fflush(Shell_IO);
reg_ptr->GPIO.PORTUC &= (~0b00000100); //Force to output to low

_task_block();
}

Re: MCF52259 time issue, and processing time

danielchen — Thu, 01 Sep 2016 03:08:02 GMT

Hi Carl Norman:

_time_delay is not useful for precise delays,it is ensuing your application will block for at least the number of ms you enter as a minimum and not a maximum. The ms is converted to TICKS in the function call and rounded up one TICK.

if you need more precise timer, I suggest you use hardware timer. please see the attached document for more details.

Regarding how long its taking to dump data into a buffer to send, please refer to the timing results in the below folder

C:\Freescale\Freescale_MQX_4_2\mqx\examples\benchmrk\timing\results_4.0.0\cw10\twrmcf52259

Thank you for your interest in NXP products and the opportunity to serve you.

Regards

Daniel

Re: MCF52259 time issue, and processing time

carlnormansuret — Thu, 01 Sep 2016 03:59:50 GMT

Thanks :smileyhappy: I will look into these options to sort out my issues. I have had to implment some pretty strict timing requirments for a protocol interface that have made me find these limits.

Re: MCF52259 time issue, and processing time

carlnormansuret — Thu, 01 Sep 2016 05:10:49 GMT

I have had a look at what you supplied and the hwtimer example supplied with MQX and it does not appear to be supported in the TWR52259 at all, and it is not compatible either as the example is based around the TWR-K64F120M.

Basically nothing supplied appears to have anything to do with the platform I am using.

Are there examples of getting the MCF52259 to fire off events at 1mS intervals?

Re: MCF52259 time issue, and processing time

carlnormansuret — Fri, 02 Sep 2016 05:34:00 GMT

Can someone tell me how to get a 1mS timer using MQX and MCF52259 (TWR)? seems like a pretty simple / obvious task for a RToS running 76MIPS, but apparently its not?

Re: MCF52259 time issue, and processing time

danielchen — Fri, 02 Sep 2016 06:12:38 GMT

Hi Carl Norman:

Sorry I forgot you are using Mcf52259.

Could you try the following code

 /* install new ISR on Programmable Interrupt Timer1 */ 
 _int_install_isr(MCF5225_INT_PIT1, PIT1_1ms_Periodic_ISR, NULL);
    
 /*  BSP_LAST_TIMER= 1(PIT1); FREQUENCY=1000ticks(1ms).  */ 
 _mcf5225_timer_init_freq(BSP_LAST_TIMER, 1000, BSP_SYSTEM_CLOCK, TRUE);  
 void PIT1_1ms_Periodic_ISR(pointer param) 
{       ++t; }

Regards

Daniel

Re: MCF52259 time issue, and processing time

danielchen — Fri, 02 Sep 2016 14:00:15 GMT

Please also refer to the following link for a timer demo,

https://community.nxp.com/thread/433761

Regards

Daniel

Re: MCF52259 time issue, and processing time

carlnormansuret — Tue, 06 Sep 2016 01:40:04 GMT

I tried this Cycle routine using _timer_start_periodic and it works fine at 20mS, however, I tried 1mS and 2mS it returns TIMER_NULL_ID so I assume there is some checks and if its to fast it wont work (point is it doesnt work).

I tried 5mS and it worked... I guess I can possibly work around a solution at 5mS. I just worry now that the context switching will cause issues as MQX is quite slow compared to what I would have thought..

Can anyone explain why 1mS timers in a 76MIPs processor is such a problem? I do this stuff in little HC08 8 bit processors all the time and have no issue, I would have thought a 32bit 76MIPS processors time base would be 1mS and it would breeze it in.

Im still suprised it takes 815uS to run this one line:

fprintf(Shell_IO, "starting this long test that should not take to long because its a 76MIPS processor.....\n");

Re: MCF52259 time issue, and processing time

danielchen — Tue, 06 Sep 2016 13:44:50 GMT

The default system tick in MQX is 5ms. This is the smallest unit of the time that clocks the scheduler.

It is not possible to have a delay shorter than 5 milliseconds without modifying the BSP. Each BSP can have a different value in the Macro "#define BSP_ALARM_FREQUENCY 200". This macro defines the number of ticks per second. This means each tick is 5 milliseconds

This is defined in twrmcf52259.h

/*
** The clock tick rate in number of ticks per second
*/
#ifndef BSP_ALARM_FREQUENCY
#define BSP_ALARM_FREQUENCY (200)
#endif

Regards

Daniel

Re: MCF52259 time issue, and processing time

carlnormansuret — Wed, 07 Sep 2016 06:39:28 GMT

It also seem the smallest time value I can get from code like this is 10mS

_time_get(&StartTime);

_time_delay(1);
_time_get(&CurrentTime);
_time_diff(&StartTime, &CurrentTime, &TimeDifference);

result is always 10mS

This is terrible... is there a way to at least measure time in the 1mS range?

Re: MCF52259 time issue, and processing time

danielchen — Wed, 07 Sep 2016 08:04:50 GMT

Hi Carl:

_time_delay() is blocking function, which puts the calling task to the timeout queue. When timeout exceeds for the task ( measured by the BSP tick timer interrupt ) the task is put back to ready queue. Then , RTOS scheduler runs and selects next active task to run depending on scheduling rules. It depends on what are other ready tasks at the moment and their priorities and what interrupts are running at the moment. _time_delay() is specified to guarantee minimum time, not maximum. Maximum depends on the application. So , please don't use time_delay for precise timer requirement.

If you need 1ms range, I think you have an options to try modify the macro BSP_ALARM_FREQUENCY from 200 to 1000, then you will get the tick time is 1ms. but you need to do more tests.

Regards

Daniel

Re: MCF52259 time issue, and processing time

carlnormansuret — Thu, 08 Sep 2016 01:37:54 GMT

Sorry, the above post was a little stupid of me, I am aware _time_delay(1) is incorrect for this test, I was trying to see if the time in MQX is able to see 1mS, and it is not as I assumed even thought the BSP tick time is 5mS, i thought it would still be aware of the time passed. The OS is only able to see a resolution of 5mS by default.

I did change it to 1000 giving me 1mS resolution, however, I worry that this processor is now going to be loaded up doing 5 times the amount of context switching. I have 7 threads running, so I really do worry this will load it up...?