Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

using vTaskStartTrace with terminal

Posted by natanel on September 24, 2007
I would like to use vTaskStartTrace in such a way
that in the end the result would be sent out to a terminal using uart_0 and saving it as a file

using the tracecon.exe to convert this file

something like this
//-----------------------------------------------------------
// Variable for debug
#define BUFFER_SIZE ( ( unsigned portSHORT ) 512 )
static signed portCHAR pcWriteBuffer1[BUFFER_SIZE]={0};

// some were in the code
vTaskStartTrace( pcWriteBuffer1, BUFFER_SIZE);
.
.
.
// end trace
ulTaskEndTrace();

// write to terminal
for (i=1;i<=BUFFER_SIZE;i++)
print_dbg_char( pcWriteBuffer1);
//-----------------------------------------------------------

then pointing the terminal to transfer it to file and using tracecon over this file

using HyperTerminal and trying any print_dbg function (print_dbg_char, print_dbg_ulong, print_dbg_hex)
the tracecon.exe didn't work for me (got zero size file)

any suggestions

regards



RE: using vTaskStartTrace with terminal

Posted by natanel on September 24, 2007
I have been tring some more staff

using it like that know

for (i=0;i<BUFFER_SIZE;i=i+4)
{
//print_dbg("0x");

// create number as seen in memory window of avr32studio
print_dbg_hex( (pcWriteBuffer1<<(6*4))+(pcWriteBuffer1[i+1]<<(4*4))+(pcWriteBuffer1[i+2]<<(2*4))+
( (unsigned portCHAR) pcWriteBuffer1[i+3]));

print_dbg("\r\n");

}

in avr32studio I can see the memory of pcWriteBuffer1 ( &pcWriteBuffer1 = 0xbd4)

0x00000bd4 : 0xBD4 <Hex>
Address 0 - 3 4 - 7 8 - B C - F
00000BC0 00000000 00000000 00000000 00000000
00000BD0 00000081 00001388 00000001 00001389
00000BE0 00000003 0000138D 00000000 0000138D
00000BF0 00000001 0000138D 00000003 00001392
00000C00 00000000 00001392 00000001 00001392
00000C10 00000003 00001397 00000000 00001397
00000C20 00000001 00001397 00000003 0000139C
00000C30 00000000 0000139C 00000001 0000139C
00000C40 00000003 000013A1 00000000 000013A1
00000C50 00000001 000013A1 00000003 000013A6

which is indenticl to the file from the terminal named Trace.hex (but is writen as txt)

00001388
00000001
00001389
00000003
0000138D
00000000
0000138D
00000001
0000138D
00000003
00001392
00000000
00001392
00000001
00001392
00000003
00001397
00000000
00001397
00000001
00001397
00000003
0000139C
00000000
0000139C
00000001
0000139C
00000003
000013A1
00000000
000013A1
00000001
000013A1
00000003
000013A6

then using hex2bin over this text file (named Trace.hex) giving back zero size file (Trace.bin)

this made me think that hex2bin is not reading txt files with hex numbers but something else

can some one help?


RE: using vTaskStartTrace with terminal

Posted by Richard on September 24, 2007
The data should be tick count followed by task number, so the data looks like it could be real. However, when I open a trace buffer I see the data the other way around, little endian format. Maybe the bytes are being transmit in the wrong order? When looking at pure binary data I would expect it to look more like.

Your data | Expected data
00001388 | 88130000
00000001 | 01000000
00001389 | 89130000
00000003 | 03000000
0000138D | 8D130000
00000000 | 00000000
0000138D | 8D130000
00000001 | 01000000

Etc.

Regards.

RE: using vTaskStartTrace with terminal

Posted by natanel on September 24, 2007
sorry
I didn't understand your response

- does it mean I am getting the right trace data
- tick count of the RTOS program I am using is 5000 ( 5 tick/msec).
so the trace result dosen't look right, for example task 1 is running 0x1388 = 5000 tick
which is one sec, but the task is schedualed for every msec.
in my case I also have a counter in the task which show me that this task is runnig each msec then each sec.
- still I don't know way the hex2bin give me back 0 size file

is some one used vTaskStartTrace with terminal?

Regards

RE: using vTaskStartTrace with terminal

Posted by natanel on September 26, 2007
let me see if I got it right (as it not writeen anywere)

0x00001388 = 5000
00000001
0x 00001389 = 5001
00000003
0x 0000138D = 5005
00000000
0x 0000138D = 5005
00000001
0x 0000138D = 5005
00000003
0x 00001392 = 5100
00000000

task 1 started at tick 5000 until tick 5001
task 3 started at tick 5001 until tick 5005
task 0 started at tick 5005 until tick 5005
task 1 started at tick 5005 until tick 5005
task 1 started at tick 5005 until tick 5010
task 0 started at tick 5010 until tick ...

tell me if I got it right
for my program it is 5000 tick per second

1) the tick are absolute tick count and not delta tick count.
2) if so how come task (1,0) took zero tick to run (5005 to 5005), shouldn't it be at least one tick.
3) if those are the numbers field in the pcWriteBuffer1 way one need the hex2bin.exe and tracecon.exe to get the data.
4) can it be I got wrong pcWriteBuffer1
5) I changed the portCHAR pcWriteBuffer1 to the right hex numbers using this code (shifting places)

// create number as seen in memory window of avr32studio
print_dbg_hex( (pcWriteBuffer1<<(6*4))+(pcWriteBuffer1[i+1]<<(4*4))+(pcWriteBuffer1[i+2]<<(2*4))+
( (unsigned portCHAR) pcWriteBuffer1[i+3]));

as you can see the pcWriteBuffer1[i+3] is converted to unsigned as it is the only number with FFFF
the rest are already positive
how come? should it be like that?

regards


RE: using vTaskStartTrace with terminal

Posted by Ricky on September 26, 2007
2) if so how come task (1,0) took zero tick to run (5005 to 5005), shouldn't it be at least one tick.

If a running task blocks on a semaphore or queue, it can run for less than a tick before another task executes.

RE: using vTaskStartTrace with terminal

Posted by Richard on September 26, 2007
The timing used by default is the tick count, so any context switches that occur with a higher frequency than that do not have accurate timing information - although the order of execution shown is correct. When I use the utility I change the behaviour to use a high resolution free running timer, but the timer used depends on the processor on which it is running so this is not portable and cannot therefore be the default behaviour.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists