Перейти к содержанию
    

о технологии программирования TMS320F28235

Вот что нашел по поводу формата DAT Файла Code Composer Studio:

dat_file_format_in_Code_Composer_Studio.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я извиняюсь что немного в сторону от хода диалога. Зато по сути вопроса.

Я год назад подсел на матлаб и генерирую код TMS320F28335 исключительно из квадратиков симулинка.

Сделал на F28335 позиционный регулятор на безколлекторном двигателе. Работа в ручную (по моим оценкам) заняла бы 6 мес., работа на матлабе - меньше двух. Качество генерироуемого кода (я бы сказал) изумительное. Гибкость очень большая (вплоть до того, что можно желаемый квадратик поместить в желаемую секцию и соответственно в ОЗУ или во флэшь). Программа - это симулинковская модель с подсистемами. Использую также матлабовский профайлер и на лету вижу в виде диаграмм какое прерывание у меня когда кого перехватило и т.д. Удобство. Осцилограф подключать не надо.

Только надо всё равно разбираться в деталях, что он нагенерировал. Но генерирует славно! проверять за кем то это ведь не самому писать.

 

ЗЫ На DSP/BIOS писал раньше под 5509а. Надо сказать вещь достойнейшая.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я год назад подсел на матлаб и генерирую код TMS320F28335 исключительно из квадратиков симулинка.

У меня есть огроменное желание освоить подобное. называется , вроде, модельно ориентированное программирование (МОП). вещь классная =). вот если б Вы могли какие-нибудь статьи написать. я для себя пишу в блог свои потуги - и себе полезно и людям, быть может. А вы не пишите отчеты по результатам работы, статьи в блог ?? ....

поделились бы с народом! подняли всеобщий российский уровень разработчиков, а то аж за родину обидно - китайцы числом берут! и всяческие технологии осваивают быстрее нас, пока мы впорознь какждый в своей конторе в углу сидим и с народом не делимся =((((

 

 

А, вообще это МОП ( ссылка1, ссылка2 и т.д.) относится к визуальному программированию, которое, как мне кажется, является следующей ступенью "эволюции". Мы, люди, лучше оперируем с образами, абстракциями - так уж устроены. Поэтому визуальное программирование ближе к человеку, но оно невозможно без других ступеней, как текстовое программирование (на самом деле ужасное). Ужасное потому. что представляет собой 1D-программирование, с кучей строчек кода, которые в симулинке выражаются в достаточно лаконичную систему.

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

мне бы гуру стать в 1D-программирование, а потом уж переходить на 2D =)).

Изменено пользователем beaRTS

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня есть огроменное желание освоить подобное. называется , вроде, модельно ориентированное программирование (МОП). вещь классная =). ....

Поэтому визуальное программирование ближе к человеку, но оно невозможно без других ступеней, как текстовое программирование (на самом деле ужасное). Ужасное потому. что представляет собой 1D-программирование, с кучей строчек кода, которые в симулинке выражаются в достаточно лаконичную систему.

Что бы так призадуматься

на FPGA все-таки большие проекты перешли с графического создания схем в текстовое описание(verilog и VHDL), наверно не спроста :laughing:

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

на FPGA все-таки

 

Так везде.... Есть программисты и схемотехники, которые делают всю работу, а есть пользователи, соединяющие сделанные ими квадратики и гордо говорящие "я сделал девайс"!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так везде.... Есть программисты и схемотехники, которые делают всю работу, а есть пользователи, соединяющие сделанные ими квадратики и гордо говорящие "я сделал девайс"!

ну так то если вы не знали то есть программисты разработчики, и прикладные программисты (за знаниями к Эккелю), которые благодаря трушным программерам, сочинившим STL, делают более эффективные проги...

а схемотехника что??? есть обычный СМЕХОтехник, который соединяет микросхемки по типовым схемам включения, которые даны в даташитах, а есть мужи, которые эти микрухи разрабатывают и рождают эти даташиты и типовые схемы включения.

 

Мир делится и это неизбежно. И это правильно.

 

P.s. просто мне не понравился контекст употребления слова "пользователи .. гордо говорящие "я сделал девайс"". Как-то чересчур уничижительно звучит.

Изменено пользователем beaRTS

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

P.s. просто мне не понравился контекст употребления слова "пользователи .. гордо говорящие "я сделал девайс"". Как-то чересчур уничижительно звучит.

 

Так ведь так оно и есть! Чтобы иметь такую точку зрения, достаточно поиметь опыть разработки все этих частей иерархии девайса. И тогда сразу становится все на свои места - сколько времени и сил уходит на низкий уровень (если не транзисторный, то хотя бы гейтовый при разработке ИМС в схемотехнике, и низкоуровневый в программировании на уровне оптимизации под архитектуру) - работа с готовыми и отлаженными блоками близка к отдыху на любимом курорте по сравнению с рутиной разработки самих блоков. Поэтому очень даже корректно будет сказать - что девайс сделали те, что сделал сами "кубики", а не тот, кто их соединил между собой. И деление заработанных средств "по понятиям" было бы правильным - 90% тем, кто делал блоки, и 10 тому, кто их соединил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По поводу статей как програмировать на кубиках - устанавливаете матлаб, берёте кит TMS320F28335 и прогоняете все примеры. Там их море. С каждым разбираетесь. 1-2 месяца и вы будете плавать как рыба в воде. Это будет получше, чем статьи. Заодно и всю периферию процессора освоите.

 

Так ведь так оно и есть! Чтобы иметь такую точку зрения, достаточно поиметь опыть разработки все этих частей иерархии девайса. И тогда сразу становится все на свои места - сколько времени и сил уходит на низкий уровень (если не транзисторный, то хотя бы гейтовый при разработке ИМС в схемотехнике, и низкоуровневый в программировании на уровне оптимизации под архитектуру) - работа с готовыми и отлаженными блоками близка к отдыху на любимом курорте по сравнению с рутиной разработки самих блоков. Поэтому очень даже корректно будет сказать - что девайс сделали те, что сделал сами "кубики", а не тот, кто их соединил между собой. И деление заработанных средств "по понятиям" было бы правильным - 90% тем, кто делал блоки, и 10 тому, кто их соединил.

 

Да я, собственно, с этим не спорю. Кубики конечно сделали они. И примеры дали они. Но их, извините, в MathWorks Inc - 2500 программистов в 14 странах (данные по прошлому году). Как мне одному с ними тягаться? Собственно, в целях экономии времени пришлось освоить технологию, т.к. начальство стояло над душой. Как всегда, требовался результат. До того я писал на 5509a в DSP/BIOS и, сравнивая, скажу, что чтобы глубоко освоить технологию матлаба - т.е. понять как генерируется код, и, далее, как его сгенерировать так, как ты хочешь - требуется больше усилий, чем для освоения и DSP/BIOS и CCS (для написания несложных многопоточных приложений с очередями, семафорами и др. функционалом этой оси). Зато после понимаешь, что время потратил не зря. Писать-то надо по-минимому. Однако, согласитесь, что одному человеку разобраться в том, что нагородили 2500 программистов (ну пусть даже не 2500, а всего каких-то пару десятков, вовлеченных в интеграцию с Техасом), и далее на этом сделать законченную работающую вещь - это не мало.

В конце концов, все мы используем готовые компиляторы, готовую CCS-среду, CSL-библиотеки, DSP/BIOS (попробуйте его написать сами), готовые FPGA - коры; далее мы пишем программы, делаем прибор, в итоге, говорим, что вот - мы сделали девайс! То что в этом девайсе нашего-то - не более 5% - мы об этом скромно умалчиваем. Я сделал то же, и сказал - вот - законченная вещь. Не вижу никакой разницы между разработчиком из-под матлаба и любым другим разработчиком, который использует готовые среды, готовый компилятор, готовые библиотеки, готовые стэки протоколов, готовый ISE или Квартус с библиотеками программных коров и наборами аппаратных ядер внутри плисов, готовый Modelsim для оценки результатов своей работы, готовый expedition для разводки плат. Мы (и вы и я) - живём-то на всём готовом :rolleyes:.

И наше участие (и ваше и моё) в конечном устройстве - минимально. Согласитесь. То, что у кого-то есть опыт разработки разных уровней от ассемблера и VHDL до C++ и матлаба: так что с того? И у меня он есть.

Но компиляторы и среды мы-то с вами не писали? А только пользовались всем готовым.

 

По поводу сил, которые уходят на низкий уровень скажу, что сил много на низкий уровень не уходит... Чтобы прийти к более-менее конечному результату - уходит много времени, а не сил.

(Все мы нормальные люди, работаем по 8 часов в день с выходными и праздниками. Если есть другие - то не это надолго, потом тоже скоро становятся нормальными :rolleyes: ). Инженер на каждом уровне программирования (высоком или низком) - решает задачи (сложные или простые). Если кто-то за вас уже написал хороший компилятор, создал хорошую библиотеку коров, написал хороший FPGA - симулятор, то вы по-просту решаете другие вопросы, которые за вас ещё не сделали. И всё. Никогда нельзя сказать, что задачи низкого уровня сложнее задач высокого уровня. Всякая задача (ИМХО) становится простой (или очень простой), если её грамотно дефрагментировать. Независимо от того, это множество конечных автоматов, взаимодействующих между собой внутри ПЛИСы или программа разводчика печатной платы.

 

Далее по теме:

Мне пришлось самому сделать только несколько кубиков: первый кубик реализовывал интрефейс с датчиком ЛИР (абсолютный датчик положения), в этот кубик была записана S-функция, которая запускала один из УАРТов в пакетном режиме (там хитрый УАРТ: он может работать в аппаратном пакетном режиме) и в процессе работы получала от него данные. Такого кубика не было в стандартной библиотеке - пришлось реализовывать самому.

Второй кубик - вызывал стандартную техасовскую библиотеку FIR-фильтра. Этот кубик значительно быстрее работал, чем если бы делать FIR-фильтр из стандартных кубиков simulink-а. Прежде чем его сделать пришлось конкретно по-потеть.

Достаточно сложной была подсистема определения скорости ротора, особенно на малых скоростях. Датчика скорости не было, был только датчик положения. Дифференцирование данных от датчика положения - задача, как известно математически некорректная. Пришлось делать кубик осуществляющий калмановскую фильтрацию.

А всё остальное: стандартный УАРТ для онлайновой регистрации графиков работы устройства на экране ПК, стандартный CAN для получения уставок позиционирования со стороны управляющего ПК, стандартные два АЦП для оцифровки данных от датчиков токов фаз, различные ПИД регуляторы и нелинейные звенья - всё было взято из стандартной библиотеки матлаба для F28335.

В итоге программа задействовала след. периферию: 2 АЦП, 1 CAN, 2 UART-а, 3 сдвоенных PWM-а, одна trip-зона.

На разработку ушло где-то два месяца. По моим оценкам - такая же разработка без матлаба - полгода.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...