Jump to content

    

Грендайзер

Участник
  • Content Count

    380
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Грендайзер

  • Rank
    Местный

Информация

  • Город
    Array

Recent Profile Visitors

3955 profile views
  1. Добрый день! Хотел попробывать себя в программировании сигнальных процессоров и embedded linux, для чего у одного из форумчан приобрёл плату TMDSEXPL138 Experimenter Kit на базе микросхемы OMAP-l138. Однако в следствии изменившихся личных обстоятельств и завала на работе, времени для освоения деавйса в обозримом будующим не предвидится. Так что хочу, как говорится продать за что купил а именно 7т.р. В комплекте: -базавая плата; -мезонин с OMAP-l138; -дисплей; -блок питания; -2 sd карты. Так же отдельно на али заказал переходник с RS-232 на USB с нуль-модемным переходником. Его отдам впридачу. Возможен торг. Пересылка по России.
  2. Вот если можно поподробней. Я если честно ничего не понял. На плате имеется кардридер, в который вставляется флешкарта (на ней я так понял установлен некоторый дистрибулив линукса, который будит крутиться на ARM). Так же там есть набор переключателей, который, который определяет откуда будит загружаться ARM (переключатели подключены к пинам BOOT). Но... Вообщем сразу после ресета ведь DSP уже живёт... и я ведь могу его заставить светодиком поморгать а не пытаться там что то с ARM ядром делать? P.S. Касательно фирмы ядер ф. ARM я имел дело лишь с серией cortex-m. И всякие линуксы для ядер ARM9 или там cortex-a для меня вообще тёмный лес. Так что хотя бы с чего то начать то...
  3. Не, это я не потяну... Ой всё Я отношусь к поколению, будущее и жизнь которого без галочек и кнопочек - не мыслима!!! Нашёл таки в мануле следующие строки про загрузку: Following deassertion of device reset, the DSP intializes the ARM296 so that it can execute the ARM ROM bootloader. Upon successful wake up, the ARM places the DSP in a reset and clock gated (SwRstDisable) state that is controlled by the LPSC and the SYSCFG modules. Правильно ли я понимаю, что всё же первым стартует ядро DSP, которое чё то там шаманит с ARM, а тот уже ресетит первое и... ну что то там дальше происходит?
  4. А что нибудь дишманское с алика (типа такого) подойдёт? А что это значит и зачем они нужны? И главное, в папке где установлен CCS есть папка expkitomapl138 а в ней 3 файла: EXPKITOMAPL138_ARM.gel, EXPKITOMAPL138_DSP.gel, OMAPL1x_debug.gel. Ну первый 2 понятно, а последний? И как их CCS то подсунуть? А CCS создаёт только один. Правда там и впрямь дериктивами #ifdef/#ifndef выбирается тип ядра. А про это гдет то... по человечески есть почитать? А чего там искать? Если я выбираю проект "hello world" то он мне туда только #include <stdio.h> подключает, а если empty, так и того нет Так там мануалов до одного места, и все как один по 1000 с лишним страниц. Какой из них читать сразу и не поймёшь...
  5. Добрый день коллеги. Имею опыт прогаммирования контроллеров (stm, atmel(RIP)), и всегда хотелось поковыряться с dsp. И вот не давно разжился платой omap-l138 experimenter kit. И всё... Чего с ней делать, вообще не пойму. Ситуация усугубляется тем, что штуковина мягко говоря уже не новая, и вся литература по ней (и самое главное по софту) сильно устарела. Установил CCS9.3. И тут опять - ничего не аонятно от слова ВООБЩЕ! Вообщем промялся несколько дней и решил таки обратиться с следующими вопросами (може и глуповатыми, но с такими штуками я вообще незнаком): 1) Философия: в мануалах по stm (и др.) чётко написано, что при включении питания есть некоторый тактовый сигнал, на котором работает ядро ну и т.д. В тексасовских доках ничего так и не нашёл (возможно плохо искал, но просто даже изнаю кода смотреть, документации просто море, и что читать не понятно). Единственное, что понял - сначала стартует ядро ARM (какимто образом) и дальше выводит DSP ядро из ресета(опять таки как - непонятно). Что там происходит и где прочесть то про это? 2) Где то прочитал, что в плате реализован отладчик XDS100v1, но в установленном CCS есть лишь XDS100v2. Они как то совместимы? И ещё, я так понял, что с помощью XDS100v1 установленного на плате я смогу запрограммировать лишь DSP а ARM нет. Правильно? 3) Создание проекта для OMAP - ну тут вообще трэш! Чего этому CCS надо я вообще никак не воткну. Пытался подгрузить проекты, те что шли на одной из карт памяти из комплекта платы... Но эта сволочь (ССS) ругается на то что не видит функции и пр. в подключённых файлах, а когда полез в settings начал что то там про компилятор бухтеть. Одним словом как создать проект (ну хотя б светодиодиком то поморгать), я не понял. Но догадываюсь, что суть в следующем: а) Создаём проект, указываем целевой крисалл и загрузчик. б) В проект нужно как то подключить .gel файл(ы) - они собственно настраивают pll и ещё что то. в) В проект нужно как то подключить .cmd файл - это типа скрипта линковщика. 4) При созданиии проекта не никаких инклюдов. Т.е. файл с адресами регистро нужно самому писать? Если кто то поможет пролить на это дело свет буду очень признателен! P.S. На форуме вроде как полно всего про OMAP, но там везде уровень явно выше моего.
  6. Ну во первых, не надо столько писсимизма! Во вторых - да, STM32 (на мой скромный взгляд куда круче, как по параметрам так и по цене, впрочем как мне кажется сама политика ST куда более дальновидна и "мягко-агрессива", чем у покойного Atmel). Но, в своё время, знакомство с cortex m4 да и вообще с 32-х разрядными процами я начал именно с этой вот платы (ну точнее говоря с SAM4S-EK2). Её тут один товарищ, вместе с программатором не то за 5 не то за 10 рублей продавал. Мне она (за такие деньги) естественно, не нужна, на али за эту сумму можно STM32MP157C-DK2 (кстати, если на неё кто то хочет аукцион от 100 рублей устроить, то я весь готовый) подрезать. Но по старой памяти (и с учётом старых наработок и "аукциона невиданной щедрости") готов сразу поднять ставки до 1000р. Единственное вопрос, блок питания в комплекте?
  7. Я не разабрался с ethernet драйверами от stm, а функции lwip настравивают (с помощью всё тах же драйверов) mac контроллер и пересылают/принимают с помощью него данные.
  8. Добрый день, коллеги и всех с пршедшим праздником космонавтики! Встала такая задача, прегонять "сырые" ethernet пакеты через stm32. Т.е. к MAC сонтроллеру в STM32 приходит ethernet пакет (физика lan8742), его необходимо принять и как есть передать дальше (например по SPI или UART - не важно). На другом конце стоит такой же STM32 который принимает пакет всё по тому же (UART или SPI) и должем с помощью своего MAC отправить его в сеть, опять же как есть! Т.к. с STM-овскими драйверами не получилось разобраться, использую ф-ции lwip NETCON (те что для FreeRtos): ethernetif_input - та, что создаётся в дефолтной задаче и low_level_output(netif, p). Для проверки использовал плату Nucleo-f767 переписав ethernetif_input следующим образом: void ethernetif_input(void const * argument) { struct pbuf *p; struct netif *netif = (struct netif *) argument; uint8_t *pbuf_test; for( ;; ) { if (osSemaphoreWait(RxPktSemaphore, TIME_WAITING_FOR_INPUT) == osOK) { do { LOCK_TCPIP_CORE(); p = low_level_input( netif ); if (p != NULL) { /* Здесь просто меняю байт в адресе назначения для проверки */ pbuf_test = (uint8_t*)p->payload; pbuf_test = pbuf_test + 3; *pbuf_test = 0x44; /* и отсылаю обратно */ low_level_output(netif, p); pbuf_free(p); } UNLOCK_TCPIP_CORE(); } while(p!=NULL); } } } Наблюдаю ситуацию в wireshark - всё нормально, в качестве адреса назначения FFFFFF44FFFF в качестве адреса источника (АИ) - адрес моего ПК. Однако теперь нужно сделать то же самое на STM32h743 и тут засада. Контроллер прерсылает в качестве АИ свой MAC адрес. Как объяснить этому мерзавцу, что б он так не делал? В его мак контроллере есть регист ETH_MACCR в котором можно указать из какого MAC регистра брать этот адресс, но вот что б отключить это дело, как я понял необходимо подшаманить в содержимом дескрипторов, и тут чё то я ничего не понял...
  9. Так для того, что бы увидеть сигнал, его ведь надо чем то простробировать. Если Вы смотрите сигнал данных, то его значения берутся в момент фронта тактового сигнала(тс). А чем Вы сам тактовый сигнал собираетесь стобировать? Если самим собой, то наверно ничего интересного Вы не увидите... Ну разве что постоянный уровень.
  10. Коллеги, очень признателен за помощь. Теперь кое что стало доходить. Всем большое спасибо :)
  11. Не, про метостабильное состояние это понятно... не понятно другое. Вот картинка. Допустим частота clk1 < частота clk2. В какой то момент триггер d2 вошёл в это самое метостабильное состояние. Допустим, что время этого состояния было не долгим (скажем < чем период clk2). Теперь, кто сказал, что после выхода триггера из этого состояния в точке С будет присутствовать верный уровень... тут ведь как карта ляжет... Например если на момент нихода фронта clk2 в точке B была '1'. Триггер вошёл в метостабильное состояние... а после выхода у него на выходе (в точке С) появился '0'. Тогда триггрер d3 в момент прихода следующего фронта clk2 защёлкнет '0', а должен был защёлкнуть '1'. Ну и пошло поехало... Или я в чём то неправ?
  12. Ну во первых сама по себе задача увязки клоков весьма важна и интересна. Во вторых я и впрямь хочу поэкономить ресурсы, т.к. плиса у меня маленькая, а помимо указанных блоков там будет стоять несколько КИХов, которые пожрут почти все умножители нуууу и ещё кое какая переферия. Что же касается констрейнов, то как мне кажется, в моём случае 100МГц частота вполне съедобная. К сожалению всё равно не понимаю, как синхронизатор поможет, если на выходе триггера присутствует неправильное значение. Ну да Бог с ним... Я так понял, что всё же фифо самый простой и надёжный вариант. Подскажите ещё такой вот вопросик. Допустим у меня есть 2 разных тактовых сигнала. При том один больше второго. Допустим я хочу отловить фронт более медленного. Допустимо ли завести более медленный сигнал на информационный вход триггера (пусть клоки синхронны) в схеме определения фронтов?