Jump to content

    

__inline__

Участник
  • Content Count

    762
  • Joined

  • Last visited

Everything posted by __inline__


  1. У меня есть все PDF-ки которые были тут: https://01.org/linuxgraphics/documentation/driver-documentation-prms/2014-intel-processors-based-bay-trail-platform Ага :) Опен хард такой опен-хард - что доступно ограниченное количество времени........ То же самое и с фриской было с их i.MX. Было SDK под баре-метал и сплыло... Мудачество со стороны производителя железа. Мол пишите под андроид... да нах он сдался мне? (зла не хватает!)
  2. Перенес эмулятор Capcom Play System 1 и 2. За основу брал caname. Задолбался его вычищать. Учитывая большую любовь MAME к точности эмуляции и универсальный системный подход, большой скорости ждать не пришлось. caname - огрызок от MAME заточенный на CPS1,2. И ещё, 32 МБ мало - там только куча требует 16 МБ чтобы создать среду эмулятора. Оптимально - 64 МБ как было в TF. Лучше 128. Эмулятор ворочает на C6745 на 35..40 FPS, вместо целевых 60. Но это лучше, чем ничего. Можно конечно пропуск кадров сделать - но это не моё. Лучше честно видеть все кадры на медленной скорости, чем половину вообще не видеть )) Размер экрана в CPS1,2 384x224 пикселей (логически до 512x256 - скролл). Игры специфические. Видео-профит: https://www.youtube.com/watch?v=D_TOI35BflI Также - используется PRU1 для отправки кадра на LCD, предварительно декодировав палитру
  3. Нубу в BGA как проверить что первая пайка упешна или нет? И где взять "собак на опыты"? К тому же, портить микросхемы - дорогое удовольствие
  4. Бегло просмотрел даташиты... Ну что-же... Внушает! ))) Чем-то даташит видеокарты 3Dfx Voodoo3 напомнило. По идее, польза от этих pdf-ок должна быть. При условии что если базовый адрес регистрового файла известен.
  5. Более младшие версии этого драйвера есть в исходниках? Аппноты кто-нибудь составлял? Или реверс GPU прийдётся заменить на реверс исходников драйвера Linux? Для меня любая ОС - как пятая конечность человеку. Ибо громоздко и лишнее. Ну может только срубить бабла по-быстрому на электронике. Для души применять я бы не стал. Исключение только для крохотных ОС делаю типа u-Cos, FREE RTOS и им подобным, которые ничего кроме как переключателя контекста не представляет. Хотя как моя практика показала, что прерываний достаточно. Может задачи пока такие не попадались, где ОС нужны.... Но псевдо-многозадачность спокойно делается DMA, таймерами и прерываниями. Mali400 - это классический GPU всех АРМ-ов. Ненавидимо по причине закрытости.
  6. Я вообще слабо представляю себе как можно запаять BGA без инфра-красного визора. Практически пайка вслепую выходит.
  7. Да присматривался я к OMAP-L137, в QFP корпусе есть только на 300 МГц. И в Россию их поставку ограничили. А вот C6745 ещё лежат на складах нашей Родины со старых времён ))
  8. Тоесть будете программировать этот камень под Win10 ? А как же ваше утверждение с другой темы по поводу: "... пускать под линуксом аудио ... совсем не улыбает..." ? И почему Win10 ? То что видеоядро закрыто - минус в карму интела. Не mail400 случайно? Если да, то давить бульдозером! Даёшь свой блиттер на FPGA! )))
  9. Исходники автора теперь находятся здесь - переработаны под отладочную плату STM32H7 Nucleo: https://vrtp.ru/index.php?showtopic=30174&st=0 Там же и референсный код (который брался за основу) эмуляторов. Эмуляторы которые выложены: 1) NES - "Дендик" 2) GB(C) - "Геймбой" ч/б, цветной 3) Atari Lynx 4) SMS - SEGA Master System (простая, не путать с МегаДрайвом который навороченее) 5) PCE16 - Turbo Grafx 16 Для начального освоения более чем достатчно.))
  10. BGA :) Обидно, хоть учись паять их... Доки открыты? Аппноты? На регистровом уровне их программировать можно будет?
  11. Андроид и малина всё испортили. Люди зажрались. Форумы умерли. Обсуждения как раньше нет и не будет.
  12. Всё просто как "дважды два": Во-1: мне это интересно Во-2: интересно было пощупать C6745 DSP на предмет уделывания им Блекфина и STM32H7 (сравнить производительность на мультимедиа-приложениях) В-3: макет заточен как отладочная плата на C6745 - лишней не будет, архитектура крайне удачна: на этой доске очень удобно изучать неизведанные перифералы, отлаживать алгоритмы (не только для хобби!) В-4: коммерческого выхлопа нет. Дай бог хотя бы частично отбить затраты. По первому - навеяно вот этими темами: 1) https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=61161 - я - автор данных приставок и мои посты. 2) https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=146347 - всё-же после небольших колебаний, я решился 3) https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=142964&page=6 - немного тут (с 6 страницы) Кстати, некоторые товарищи в другом форуме считают, что STM32H7 уделают C6745 DSP - причем свято и непогрешимо в это верят, что начинают лезть своими дебатами, аж смешно! )) Переписал рендеринг на ассемблере для PRU1, включил unaligned word access для эмулятора СЕГи. В итоге скорость возросла ещё больше!!! https://www.youtube.com/watch?v=c7B8XvB4c7c Да у меня Блекфин BF532 давился от этого эмулятора на 400 МГц, а на 600 - 700 МГц получилось впритык:60 FPS. А тут C6745 на 456 МГц + PRU 228 МГц переваривают код эмулятора намного быстрее!!! Только положительные впечатления! Самый лучший микроконтроллер, который я только использовал (после AT91RM9200, BF532, BF533, STM32F407, STM32H743)
  13. Ещё пара эмуляторов: SNES: https://www.youtube.com/watch?v=EpVDKmqD0zw Аркадный автомат NEO-GEO: https://www.youtube.com/watch?v=mdpIz6Zkh78 Во всех эмуляторах исполюзуются 2 PRUSS: PRU0 - опрашивает кнопки джойстика, PRU1 - отрисовывает буфер на LCD дисплей (с конверсией палитры, где надо)
  14. SEGA, пришлось использовать PRUSS для отрисовки. Видео - сравнение двух режимов : без PRUSS и с ним: https://www.youtube.com/watch?v=O1g8AbYWrzE Здесь показана максимальная производительность всей системы (CPU+PRUSS), убрана кадровая синхронизация. Чисто для наглядности https://www.youtube.com/watch?v=1JhDl9Cbn9I Видео работы эмулятора SEGA Megadrive: https://www.youtube.com/watch?v=NY6x8q0-Xjo
  15. Довёл до ума - джойстик теперь на PRU0. Перенес один из эмуляторов: https://www.youtube.com/watch?v=kTSq8R1Dnzk
  16. Написал свой загрузчик для C6745, который с SD карты по SPI загружает в SDRAM программы. Всё блестяще работает на всех моих примерах. Есть одна проблема - при указании в опциях линкера (CCS v.6, TI Compiler 8.x.x) большого размера кучи (heap) бинарник вырастает до огромных размеров - идёт резервация памяти. Так как куча допускается непроинициализированной, как сделать так, чтобы при построении бинарника он не включал кучу? Из OUT делаю в BIN двумя утилитами (узнал в e2e): делаем эльфа 1) strip6x.exe -p -o app_elf.bin app.out делаем бинарник 2) objcopy -I elf32-little -O binary app_elf.bin app.bin Кто что подскажет?
  17. Загрузчик в действии: https://www.youtube.com/watch?v=51LJgZygHt8
  18. Решил проблему, поделив все секции на Read-Only и Read-Write. Ввёл границу раздела памяти (между RO и RW). Скрипт для линкера такой: #define SDRAM_BASE 0xC0000000 #define SDRAM_SIZE 0x02000000 // 32 MB #define RO_SIZE 0x0004B000 //300 kB -c -stack 0x00008000 //32 kB -heap 0x01E00000 //30 MB MEMORY { RO o = SDRAM_BASE l = RO_SIZE RW o = SDRAM_BASE+RO_SIZE l = SDRAM_SIZE-RO_SIZE } SECTIONS { .text:_c_int00* > SDRAM_BASE .text > RO .const > RO .switch > RO .cinit > RO .rodata > RO .sysmem > RW .far > RW .stack > RW .bss > RW .neardata > RW .fardata > RW } Тут только те секции, что использую. Остальные выкинул за ненадобностью. В случае Страуструпа (C++) надо добавить другие секции. Проверил - всё пашет как надо! Обширный попкорн теперь не создаётся (файл не раздувается)!
  19. Проблема из-за вот этого: .text:_c_int00* > 0xC0000000 Если убрать, то бинарник становится маленьким, но entry point плавает. И в map-файле почему-то куча со стеком на младших адресах, ниже идёт код, данные...... Как можно принудительно заставить линковщик засовывать секции .stack и .sysmem в самый конец? (по старшим адресам) Пока ничего кроме как указать стартовый адрес стека, вычислив его дефайнами не приходит в голову.
  20. Я взял тот файл для линковщика, который мне CCS для C6745 предложил - называется он C6745.cmd. Это его содержимое. Хотите сказать что он неверный? Моя отсебятина там только - загон функции c_int00 в начало SDRAM. Атрибуты это что ? Можете выделить жирным в ваших скриптах линковщика? NOINIT - оно? PS: Ещё можно убедиться по map-файлу, что нет каких-то ещё выходных секций в несмежных с EMIFBSDRAM областях памяти. Может какие-то регистры периферии при старте прописываются. Тогда дырка между ними и EMIFBSDRAM будет заполнена. а вот это уже интересно! Я тоже сам писал. И что? нафига мне AIS в самописанном загрузчике?
  21. Всё хорошо, до тех пор пока программу пишите Вы сами. Приключения начинаются, когда занимаешься портированием чужих программ. К примеру декодер H264 - вся работа построена на куче, ибо туча буферов постоянно выделяются-высвобождаются туда-сюда, поверьте если оно б ненужно было, то никто кучу и работу с ней не изобретал,....... Мой файл для линковщика - всё как обычно: Так я ж сам загрузчик пишу, кладу файл бинарника сразу в SDRAM. Для чего мне заморачиваться с AIS? Файл разрастается на 2 этапе: objcopy -I elf32-little -O binary app_elf.bin app.bin .text:_c_int00* > 0xC0000000 Этим мы принудительно заставляем точку входа в программу быть с адреса начала SDRAM. HINT: И попутно эта функция ещё сбивает режим округления, так что только в main() его выставлять
  22. Фины же нордическая (белая) раса, чёрной она быть не может ) BlackFin - если что "Чёрный Плавник"... У AD всё с рыбами связано - вон Tiger Shark'и тоже - акулы.... А вообще смотрю я на STM32 и понимаю, что то чему рукоплещут миллионы хомячков по всему миру, это уже "дела давно минувших дней"... - многомерные DMA, память-память, видео-ускорители, наличие плавающей точки... - всё это уже давно было со времен DSP.
  23. А не пофиг ли, если для хобби (насколько я понял из этой темы "про вечное")? sitara туда же Честно говоря, мне непонятна озабоченность техасцев индусской стилистикой - в техподдержке у них почти все индусы. Вот докатились, что имена процессорам тоже дают индусские. У меня при слове "sitara" вот такая картинка в голове сразу рисуется: Эдакий, гуру микроконтроллеров, освоивший ситары )))
  24. У меня была аналогичная проблема с I2S на McASP в C6745. Нужно было избавиться от 32-битных пересылок - просто оттюнинговал оффсет в EDMA3 на значение =2 вместо 4, в итоге DMA стал отправлять в порт McASP 16-битные данные. Затем я избавился от второго канала и превратил I2S в I1S (просто надо MONO было, а не Stereo) - задал только один тайм-слот. Теперь память на второй канал не расходуется и он молчит (что и требовалось). EDMA3 настроил так: первое измерение ACNT=2 или 4 (размер семпла в байтах), второе измерение BCNT=64 (максимальный размер Audio FIFO), и наконец третье измерение = число кусков Audio FIFO в семплах. Качает до 16 МБ памяти в звук разом! В прерывании по окончанию DMA пересылки перезагружаю дескрипторы EDMA (PaRAM). Всё! Такого замечательного DMA я ещё нигде не встречал! АRМ-ы со своими 64K-DMA давятся в сторонке! =) Да, пришлось потрахаться с мануалами, порой даже на другие процессоры этого семейства, читать e2e, форумы, пережевывать китайские исходники, и.т.п. За 4 дня разобрался