Изучаем Code Composer Studio: работа с Graph tool, загрузка *.dat файла данных в процессор в точке останова

Подключу-ка  я к проекту образцовый *.dat файл из, например, этого проекта:  C:\CCStudio_v3.3\tutorial\dsk2812\volume1\sine.dat . 

sine.dat оформлен в 16-ричной системе счисления и имеет целые значения сэмплов

//sine.dat
1651 1 0 1 0
0x0000
0x000f
0x001e
0x002d

//volume.c
#include "volume.h"

/* Global declarations */
int inp_buffer[BUFSIZE];       /* processing data buffers */
int out_buffer[BUFSIZE];

    Т.к. сэмплы целые, то в своем проекте на время изменю тип данных в массиве с float-> int :


а также:
float   g_sample;    →  int   g_sample;

     С кодом проекта можно ознакомиться здесь

    Но из-за этого изменения придется изменить кишочки класса вирутального АЦП: благо - я внутренний используемый тип данных обозначил через typedef (очень удобно, как альтернатива шаблонам - имею в виду, что тоже самое можно было сделать сложнее с применением шаблонов (templates), но озарения в них я пока , как и опыта, не постиг). Поэтому меняем:

                               

Компилится - норм!! Коннектимся к девайсу. Заливаем прогу и меняем настройки точки останова у функции dataIO:




Настраиваем теперь Graph Tool : View -> Graph -> Time/ Frequency


Нажимая ОК появляется окно с непонятным графиком, видимо, т.к. не запускал еще программу на отладку и т.к. это область RAM памяти, то там хранится мусор:


Запускаем! F5
Потыкался, поперезапускал отладку в конце-концов увидел такой график:
Да. синус есть, но почему-то всего половина


Все дело в настройках отображения сигнала в Graph tool.  Вообще, эту тулзу лучше представлять себе, как реальный осциллограф (например, как цифровой lecroy waverunner 64mxi-a - няшка =) ).

Экспериментируем:
нажимаем на окне с графиком ПКМ ->Properties...  :

Graph Property Dialog -> Acquisition Buffer Size = 500 (ровно половину входного массива данных, считываемых из файла sine.dat !!)

Graph Property Dialog -> Display Data Size = 1000

(Все значения можно менять в режиме Run, т.е. во время отладки!)
Видим:


Параметр Display Data Size является “как бы“  ручкой Развертки реального осциллографа. Display Data Size может принимать любые значания больше 1. Почему??? Потому что мы в параметрах точки останова (breakPoint’s parameters), которая читает данные из *.dat файла, установили галочку Wrap Around, чем создается бесконечный входной, т.к. зацикленный, сигнал.


    Обсудим Graph Property Dialog -> Acquisition Buffer Size параметр.

В ходе экспериментов с его значением, стал подозревать, что в Code Composer Studio вывод в Graph tool организован по схеме Round-Robin scheduling алгоритму, т.к. при значениях Acquisition Buffer Size > ½ количества сэмплов во входном сигнале ( т.е. > ½  буфера в вашей программе, который подсоединен к *.dat файлу ) отображение будет происходить неверно и мы увидим грязь/мусор, который хранится в переменных RAM ( идея! что если использовать этот мусор, когда нужен какой-нибудь random’ный сигнал для отладки алгоритма - не надо будет лишний раз мучить МатЛаб или писать лишние функции.... )

Скорее всего, Code Composer создает минимум два одинаковых буфера, размер каждого из которых равен указанному в параметре Acquisition Buffer Size. Тогда длинна входного сигнала разрезается от его начала на две одинаковые части, первая из которых кидается в первый Acquisition Buffer , а вторая нарезка входного сигнала кидается во второй Acquisition Buffer. Затем идет вторая итерация “нарезок” и уже 3я нарезка входного буфера идет в 1й Acquisition Buffer, 4я нарезка - во 2й Acquisition Buffer - это все в том случае, когда Graph Property Dialog -> Acquisition Buffer Size < ½ длинны сигнала. Если меньше во много раз, то будет вот такая картина:


Если не во много раз меньше, то такая картина (тут уж как подгадаем с размером буфера Acquisition Buffer ) :


    Попробую объяснить происходящее. Для примера примем что мы установили Acquisition Buffer Size = 750 (случай, соответствующий этому рисунку есть выше).
Приведем рисунок для понимания работы, если действительно CCS создает два буфера: 1й и 2ой.

Входной буфер пилится CCS’ом на две чати: 750 и 250 сэмлов. Первые 750 сэмплов кидаются в 1й буфер, остальная часть во 2ой, но во 2ой буфер записывается еще 500 сэмплов мусора. Здесь понятно. Как это отображается в осциллографе (Graph Tool)?

Сначала  в осциллограф заходит  справа налево (!!!) 750 сэмплов нашего синуса и они располагаются от 250 до 999 по оси абсцисс на графике. Затем их пропихивают вперед (левее) следующие 750 сэмплов, причем сдвиг влево во втором случае происходит (судя по всем картинкам эксперимента) строго на половину оси ОХ (т.е. на 500), а затем та часть 2го буфера, что не помещается в графике отсекается и циклически переносится в начало графика ( как в модулярной арифметике : 750%500 = 250 шумовых компонент и идут в начало графика потому и получаем такой рисунок) :

Вывод: из проделанных экспериментов стало ясно, что нужно переводить числа из десятичной системы в 16-ричную и потом только скармливать эти данные в виде *.dat файла процессору. 

P.S. Добавлю, что есть старый даташит за 2000 год на Code Composer Studio  Literature Number: SPRU328B. Вот ссылка .
       В этой ссылке подробно описаны возможности Композера, в том числе по работе с Graph tool.