[repstosw 18]

Quote

DASM said: 

 

Выход std vector

 

Это уже C++ с редактированием большого количества исходников :)

 

 

1 hour ago, gosha-z said:

1. В цикле у вас как минимум две ошибки: очевидный вылет за границу массива и использование неинициализированной переменной в качестве  rvalue.

2. Область видимости переменной i - тело цикла, за его пределами ее не существует, так что в return - undeclared variable.

3. gcc надо явно сказать, что используется C99 (--std=c99)

 

Да, верно, ошибки  1) и 2).  При исправленных, 3) не помогло - такого пункта нет в настройках.

Проблема описана здесь и её решение: https://e2e.ti.com/support/tools/ccs/f/81/t/501095

 

Если вкратце:  использовал CCS v5 с компилятором C6000 7.4.8.  Штатный апдейт доводил до v. 7.4.24.  Всё то же - нет опции -C99 в Dialog.

 

Поставил 6-ю версию CCS (она также лечится путём удаления  mdex.dll как и 5-я версия), которая имеет App Center, из которого удалось скачать версию компилятора 8.3.3.

 

 

Переделал проект под 6-ю CSS и поставил компилятор 8.3.3.

 

 

 В опциях появилось C99:

 

 

Теперь код такого типа компилируется без ошибок:

 

int Test_Shlak(int n)
{
 int m[n];
 for(int i=0;i<n;i++)m[i]=m[1];
 return m[3];
}

 

Что и нужно было.

 

Попутно поборолся с удалением неиспользуемых функций в проекте.

В компиляторе поставил:

 

 

В линковщике:

 

 

И только тогда создаётся выходной файл без лишнего.

Проверяем так:

 

C:\CCS_DIR\ccsv6\tools\compiler\ti-cgt-c6000_8.3.3\bin\ofd6x.exe --func_info Project.out > Project.csv

И смотрим Экселем полученный Project.csv - который содержит все объекты которые в бинарнике.

 

Только тонкая оптимизация, только -C99, только хардкор! )))

 

P.S. А Страуструповское творение(C++) так и не умеет массивы переменной длины :)

Изменено 7 марта, 2019 пользователем repstosw

[repstosw 18]

Подскажите, есть ли пример работы с SDIO у TMS320C6745 ?  Планирую SD карту подключить и наладить общение с ней (на первых порах - инит, чтение, запись сектора).

Может даже в сторону OMAP-L137 копнуть и пусть даже ARM-ядро  (C он и в Африке Си)

Изменено 7 марта, 2019 пользователем repstosw

[Grizzly 0]

13 часов назад, __inline__ сказал:

она также лечится путём удаления  mdex.dll как и 5-я версия

CCS в свободном доступе с 2017 года. Все версии.

[repstosw 18]

7 hours ago, Grizzly said:

CCS в свободном доступе с 2017 года. Все версии.

С самого сайта TI?  Или в закрома лазить прийдётся?

15 hours ago, __inline__ said:

Подскажите, есть ли пример работы с SDIO у TMS320C6745 ?  Планирую SD карту подключить и наладить общение с ней (на первых порах - инит, чтение, запись сектора).

Может даже в сторону OMAP-L137 копнуть и пусть даже ARM-ядро  (C он и в Африке Си)

 

Нашёл csl-phytec-master там есть модуль для работы с MMCSD.

 

Новая проблема:  с ужасом заметил что  пины для работы с SD-картой перекрывают EMIFA, которая тоже нужна.  Мультиплексировать(разделять во времени) SDIO и EMIFA - не вариант.

EMIFA будет в 8 битном режиме, можно только на запись, обязательно работа через DMA.  На EMIFA будет  LCD с 8 битной шиной.

Для SD-карты нужен 4-ибитный режим.

 

PRUSS поможет? Через него можно работать с SDIO, но так чтобы пины были переназначены на другие?  Или только ногодрыгом проблема решается?

И TI опять зажала PRUSS тулзы для C6745

 

 

[Grizzly 0]

1 час назад, __inline__ сказал:

С самого сайта TI?

http://processors.wiki.ti.com/index.php/Download_CCS#Free_license_for_older_versions

Для новых версий лицензия не требуется.

[repstosw 18]

1 hour ago, Grizzly said:

http://processors.wiki.ti.com/index.php/Download_CCS#Free_license_for_older_versions

Для новых версий лицензия не требуется.

ЗдОрово! Я даже и это успел проспать! :)

 

3 hours ago, __inline__ said:

PRUSS поможет? Через него можно работать с SDIO, но так чтобы пины были переназначены на другие?  Или только ногодрыгом проблема решается?

Нет, не поможет.  Потому что в C6745 нет вывода GPO,GPI на GPIO (в PINMUX нет таких функций.)  Зато в C6748 уже есть.

 

И всё-же есть ли способ работать с SD-картой в режиме 4 бита способом кроме как SDIO?

[jcxz 242]

3 часа назад, __inline__ сказал:

EMIFA будет в 8 битном режиме, можно только на запись, обязательно работа через DMA.  На EMIFA будет  LCD с 8 битной шиной.

Значит придётся урезать осетра. Или LCD на SPI или SD на туда же. Или на McASP/McBSP. Или и то и то  

Зачем Вам SD именно на SDIO?

Цитата

PRUSS поможет? Через него можно работать с SDIO, но так чтобы пины были переназначены на другие?  Или только ногодрыгом проблема решается?

В C6745 есть PRUSS? Если так, то PRUSS-ом можно, но может лучше не SDIO, а LCD. И именно ногодрыгом - он на то заточен.

[repstosw 18]

38 minutes ago, jcxz said:

Значит придётся урезать осетра. Или LCD на SPI или SD на туда же. Или на McASP/McBSP. Или и то и то  

 

McASP он максимум 192 кГц и не годится. Это для звука больше.

Quote

Зачем Вам SD именно на SDIO?

Да мне главное 4-битный режим задействовать.  Надо будет читать видео-потоки с разной плотностью сжатия  и отрисовывать на экране видео.

Quote

В C6745 есть PRUSS? Если так, то PRUSS-ом можно, но может лучше не SDIO, а LCD. И именно ногодрыгом - он на то заточен.

Даташит говорит что целых два - PRU0 и PRU1.  Но в референс мануале нет мультиплексирования GPO/GPI через PINMUX, что странно.  В C6548 eсть и в утилите PINMUX тоже есть.

 

Кое-как нашёл асм для PRUSS. Было бы здорово его задействовать для реализации интерфейса для  SD карты (4 бита данные,  CLK, CMD, CS) или LCD (8 бит, CS, WR, A0).  Только как тогда DMA будет с этим всем работать?

 

И какой максимально возможный SPI CLK допустим? В даташите пишут: SPI_Module_Clock/3. Только чему равен SPI_Module_Clock - не написали.

Вместо SD карты ещё рассматриваю микроновскую SPI  MT29F4G01ADAGDWB   -  на 133 МГц она лучше будет чем SD-карта на 25 МГц даже с 4 битами

 

 

Изменено 8 марта, 2019 пользователем repstosw

[jcxz 242]

29 минут назад, __inline__ сказал:

McASP он максимум 192 кГц и не годится. Это для звука больше.

Странно. У меня на L137 он на 2.048МГц работал. И это было не предел.

Цитата

Даташит говорит что целых два - PRU0 и PRU1.  Но в референс мануале нет мультиплексирования GPO/GPI через PINMUX, что странно.

Что значит нет? Нельзя GPIO переключать на ввод или вывод?

Цитата

Кое-как нашёл асм для PRUSS. Было бы здорово его задействовать для реализации интерфейса для  SD карты (4 бита данные,  CLK, CMD, CS) или LCD (8 бит, CS, WR, A0).  Только как тогда DMA будет с этим всем работать?

На wiki доки есть.

А зачем с PRUSS ещё и DMA? PRU-ядро - это и есть собственно DMA, для которого Вы сами программу пишете.

Цитата

И какой максимально возможный SPI CLK допустим? В даташите пишут: SPI_Module_Clock/3. Только чему равен SPI_Module_Clock - не написали.

Не знаю. У меня был L137. И на SPI висела только флешка для начальной загрузки ПО, больше ни для чего. Всё остальное SPI-ное (3+1 чипа) у меня висело на McASP.

[repstosw 18]

5 minutes ago, jcxz said:

Что значит нет? Нельзя GPIO переключать на ввод или вывод?

У PRUSS своё мультиплексирование пинов, не совпадающее с GPIO.  Контроллируется с помощью PINMUX0..19. Только вот в C6745 там в битовых полях стоит Reserved,  а в C6748 уже обозначены GP PRU.  В техасовских утилитах (которые пины помогают назначить) - также.

Quote

А зачем с PRUSS ещё и DMA? PRU-ядро - это и есть собственно DMA, для которого Вы сами программу пишете.

Я упустил из виду, что PRUSS - отдельные процессоры и DMA действительно становится не нужен.  Нужна параллельность отрисовки в дисплей.

Quote

У меня был L137. И на SPI висела только флешка для начальной загрузки ПО, больше ни для чего. Всё остальное SPI-ное (3+1 чипа) у меня висело на McASP.

Тоесть используя часть линий McASP можно полностью  реализовать SPI ?  Тогда зачем SPI сделали отдельно?

 

 

[jcxz 242]

29 минут назад, __inline__ сказал:

У PRUSS своё мультиплексирование пинов, не совпадающее с GPIO.  Контроллируется с помощью PINMUX0..19. Только вот в C6745 там в битовых полях стоит Reserved,  а в C6748 уже обозначены GP PRU.  В техасовских утилитах (которые пины помогают назначить) - также.

Ну так я же вам и посоветовал - использовать его для драйвера LCD по параллельной шине. Там ведь наверное не нужно направление передачи переключать? И регистры данных GPIO доступны из PRU-ядра? Тогда сконфигурите как надо пины DSP-ядром, а используйте PRU-ядром.

Странно - насколько помню PRU в L137 имел доступ ко всем регионам памяти и всей периферии. Я на нём UART эмулировал. 

Цитата

Я упустил из виду, что PRUSS - отдельные процессоры и DMA действительно становится не нужен.  Нужна параллельность отрисовки в дисплей.

Ну вот. А заодно они могут и ещё какие-то преобразования над пикселями делать. Если нужно. Там регистры многоразрядные и команды насколько помню - многооперандные, код там хитро пишется, трудно сразу привыкнуть. Но зато можно такого параллельного навернуть!  

В моё время (когда я тот проект делал) для PRU существовал только ассемблер, си не было. Но я вроде как-то недавно слышал, что для PRU появился и си-компилятор. Может стоит и его попробовать. По-крайней мере для DSP CCS создаёт вполне себе оптимальный код. Уже CCS3.3. Так что и для PRU может оказаться вполне годным.

Цитата

Тоесть используя часть линий McASP можно полностью  реализовать SPI ?  Тогда зачем SPI сделали отдельно?

У меня в проекте на одном McASP (McASP1) висело 3 чипа ADS1298 (TX/RX) и ещё один кодек TLV320DAC32 (только TX). Причём - ADS-ы требовали SPI, а TLV - I2S. Но мне удалось запустить всё это на одном McASP так что работало это одновременно в режиме непрерывного потока. И обслуживалось всё сразу (и все ADS и TLV - одним DMA-каналом). Помню, что какие-то проблемы были с созданием нужным времянок для ADS, но с чем именно - не помню (они ещё стояли за разными ADUM-ами, и вроде эти проблемы были связаны с различием задержек ADUM-ов по разным каналам). но потом я эти проблемы как-то решил.

Хотя помню, что тогда подумал, что надо было сразу делать драйвер обмена с ADS на PRUSS (если б заранее знать). Но в начале проекта было много работы и с PRUSS разбираться было некогда, а потом сделал уже на McASP и переделывать плату не стали.

SPI у нас использовался только для загрузки с SPI-флешки ПО. Всё. С McASP так не загрузишь. И повесить всё на SPI не получалось - пины нужные перекрывались - было много периферии и PRUSS я сразу не изучил. если вешать все ADS на SPI (CS-ов там хватало на все чипы), то там вроде получался конфликт по пинам или с EMIFB или с USB или с SDIO (он у нас тоже использовался).

Общий состав периферии был примерно такой:

SDRAM - EMIFB;
USB;
UART;
ADS1298 * 3 + TLV320DAC32 - McASP1;
W25Q64 - SPI;
TLV320DAC32 + FM24CL16 - I2C;
TiWiR2 (WiFi + BT) - SDIO;
ещё довольно большая куча GPIO для управления всем хозяйством.

если ничего не забыл...

[repstosw 18]

On 3/8/2019 at 8:19 PM, jcxz said:

Общий состав периферии был примерно такой:

SDRAM - EMIFB;
USB;
UART;
ADS1298 * 3 + TLV320DAC32 - McASP1;
W25Q64 - SPI;
TLV320DAC32 + FM24CL16 - I2C;
TiWiR2 (WiFi + BT) - SDIO;
ещё довольно большая куча GPIO для управления всем хозяйством.

 

Вы здОрово всё расписали, интересно было почитать!  Вылезла другая проблема - с какого-то момента загрузка по UART0 перестала работать и включается очень редко.

Ошибка такого плана:

 

Но загрузка с SPI EEPROM при этом идёт!

 

В чем может быть дело?

 

[repstosw 18]

UART0 то работает, то нет.

 

Переключился на загрузку с UART2 - работает стабильно: более 0.5 МБ гружу в SDRAM.

 

Настроил EMIFA и прикрутил дисплей 480x320.  Всё работает.  С картой памяти наверное поступлю проще - повышаю её на SPI1 (на SPI 0 висит Boot EEPROM).

 

Видео дисплея в работе: https://www.youtube.com/watch?v=CzOtunjHsSg

 

Исходник проекта для CCS v6 ниже:

 

LCD_ILI9486.rar

 

 

Изменено 10 марта, 2019 пользователем repstosw

[repstosw 18]

On 3/10/2019 at 2:36 PM, __inline__ said:

Вылезла другая проблема - с какого-то момента загрузка по UART0 перестала работать и включается очень редко.

В чем может быть дело?

Меня эта проблема достала и на UART2 - то грузится, то нет.  Замерил логические уровни на бут-пинах: там где должна быть лог. "1" напряжение 1.8V  вместо положеных 3-3.3V.  Подтягивающие резисторы на 9,1 кОм оказались многоваты.  Заменил на 1,1 кОм - теперь лог. уровень 3.1V что в норме.

Глючить перестало!

А я уже думал что UART'ы подпаливаются )))