Jump to content

    

AVI-crak

Участник
  • Content Count

    239
  • Joined

  • Last visited

Everything posted by AVI-crak


  1. SDIO+FatFS+STM32F4 CMSIS

    Проблема не только кучности, но и в размазывании зависимостей. По мне так любой код поддержки сложной периферии должен делиться на три уровня. Уровень конкретного железа - уникальный для каждого камня, в некоторых случаях это даже ногодрыг. Уровень внешней периферии, конкретно здесь - несколько типов распространённых sd карт. У каждой разные возможности, а так-же скорости доступа. И уровень пользователя - банальные и очень простые функции чтения/записи. Здесь, как и в хавоских проектах, как и в сотнях себе подобным - всё свалено в кучу. Какова чёрта я должен вручную запускать карточку? Это должен делать отдельный процесс, полностью автоматически. Переписать можно, это более удобно чем с примерами хала.
  2. SDIO+FatFS+STM32F4 CMSIS

    Очень странный проект, выглядит как огромная куча всего и вся. Там и fpga, и атмел, и кучка st, и даже россыпь периферийных чипов - всё в месте. Просто не верится что в один КВ приёмник можно столько деталей установить. sdcard придётся обрезать и частично переписывать.
  3. SDRAM необходимо регенерировать каждые 64мс независимо от частоты клока. Выше частота - быстрее получается регенерация, остаётся больше времени на рабочее состояние. Зачем в конструкциях хала одинаково повторяющиеся команды? а фиг его знает. После десятого рекурсивного дифлайна на хале - у меня теряется терпение. Да и зачем, если с прямым обращением в регистры - код получается намного проще и понятнее.
  4. Код инстала для stm32f439, с небольшими исправлениями кочует из проекта в проект. CODE///Install SDRAM stm32f439 FMC_Bank5_6 -> SDCR[0] = FMC_SDCR1_NC_9bits |FMC_SDCR1_NR_13bits |FMC_SDCR1_MWID_16bits |FMC_SDCR1_NB_4banks |FMC_SDCR1_CAS_2cycle //|FMC_SDCR1_SDCLK_3x |FMC_SDCR1_SDCLK_2x |FMC_SDCR2_RBURST |FMC_SDCR1_WP |FMC_SDCR1_RPIPE_1delay; //FMC_SDCR1_RPIPE_1delay FMC_SDCR1_RPIPE_3delay FMC_Bank5_6->SDTR[0] = (0x00000001) /// TMRD время между записью в MODE-REGISTER и ACTIVATE/1 /2 |(0x00000005 << 4) /// TXSR время между SELF-REFRESHING и ACTIVATE (exit self-refresh mode)/5 /7 |(0x00000002 << 8) /// TRAS минимальное время между SELF-REFRESH/2 /4 |(0x00000006 << 12) /// TRC время между двумя командами REFRESH/5 /7 |(0x00000003 << 16) /// TWR задержка между командой WRITE и вызовом PRECHARGE/1 /2 |(0x00000001 << 20) /// TRP время между командой PRECHARGE и любой другой командой/1 /1 |(0x00000002 << 24); /// TRCD время между подачей команды ACTIVATE и появлением данных на шинеС/1 /2 ///TWR >= TRAS - TRCD and TWR >= TRC - TRCD - TRP FMC_Bank5_6->SDCMR = FMC_SDCMR_CTB1 | FMC_SDCMR_MODE_Config_Enable; tmp = FMC_Bank5_6->SDSR & 0x00000020; timeout = 0xFFFF; while((tmp != 0) && (timeout-- > 0)) { tmp = FMC_Bank5_6->SDSR & 0x00000020; } delay(10000); /// PALL command FMC_Bank5_6->SDCMR = FMC_SDCMR_CTB1 | FMC_SDCMR_MODE_PALL; timeout = 0xFFFF; tmp = 10; while((tmp != 0) && (timeout-- > 0)) { tmp = FMC_Bank5_6->SDSR & 0x00000020; } /// Auto refresh command FMC_Bank5_6->SDCMR = (0x00000003 << 5) | FMC_SDCMR_CTB1 | FMC_SDCMR_MODE_Self_refresh; /// Количество рефлеш минимум 2 timeout = 0xFFFF; tmp = 10; while((tmp != 0) && (timeout-- > 0)) { tmp = FMC_Bank5_6->SDSR & 0x00000020; } // MRD register program tmp = (((((HSE_gz / (((RCC->PLLCFGR)<<26)>>26))*(((RCC->PLLCFGR)<<17)>>23))/(((((RCC->PLLCFGR)<<14)>>30)<<1)+2))/2000)*64)/8192; FMC_Bank5_6->SDCMR = (tmp << 9) | FMC_SDCMR_CTB1 | FMC_SDCMR_MODE_Load_Mode; /// 64mc/(размер блока Row Addresses(8192)) * (тактовая частота чипа) timeout = 0xFFFF; tmp = 10; while((tmp != 0) && (timeout-- > 0)) { tmp = FMC_Bank5_6->SDSR & 0x00000020; } tmp = (((((((HSE_gz / (((RCC->PLLCFGR)<<26)>>26))*(((RCC->PLLCFGR)<<17)>>23))/(((((RCC->PLLCFGR)<<14)>>30)<<1)+2))/2000)*64)/8192)<<1) | FMC_Bank5_6->SDRTR; FMC_Bank5_6->SDRTR = (tmp | (0x000002C5<<1)) | 1<<14; // время регена + вкл регена /// Refresh rate = (COUNT) * SDRAM clock frequency /// SDRAM refresh period = 64 mc /// COUNT = (SDRAM refresh period / Number of rows ) /// Refresh rate = 0.064 / (8192rows + 4) ) * 84000000 , ~ 656 ( 0x290 ) FMC_Bank5_6->SDCR[0] &= (~FMC_SDCR1_WP);// снятие защиты от записи // timeout =0; for(tmp = 0xc0000000; tmp < 0xC1FFFFFC; tmp += 4) ///32Mb 0.873 ms { *((volatile uint32_t *)tmp) = 0x00000000;// timeout; } Для файла линкера нечто подобное (у меня иначе, возможны ошибки) CODEMEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 2048K RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 192K SRAM (rwx) : ORIGIN = 0xD0000000, LENGTH = 64K CCRAM (rwx) : ORIGIN = 0x10000000, LENGTH = 64K SDRAM (rwx) : ORIGIN = 0xC0000000, LENGTH = 16384K BKRAM (rw) : ORIGIN = 0x40024000, LENGTH = 4K } -------------- /* размещение констант в SDRAM */ _sicsdram = LOADADDR(.csdram); .csdram : { . = ALIGN(4); _scsdram = .; /* глобальный символ начала SDRAM */ *(.csdram) *(.csdram*) . = ALIGN(4); _ecsdram = .; /* глобальный символ конца SDRAM */ } > SDRAM AT> FLASH --------------- *.s файл bl SystemInit ldr r0, =_scsdram ldr r1, =_sicsdram ldr r2, =_ecsdram LoopCopySdram: cmp r0, r2 ittt ne ldrne r3, [r1], #4 strne r3, [r0], #4 bne LoopCopySdram bl main --------- макрос #define SDram __attribute__((section(".csdram"))) ---------- глобальные переменные SDram const uint16_t Font[размер] ={дата}; Таким образом можно объявить функции и даже часть данных что не могут физически уместиться во внутреннюю флеш чипа. В этом случае из асмы *.s вызывается функция чтения внешней флешки, например 25q64, и есно запись в sdram. Сделать это необходимо до входа в майн. Естественно размещение дампа на внешней памяти - отдельный разговор, он станет актуальным после получения бинарного файла прошивки размером за 2 гигабайта. Исправляется ситуация весьма оригинально, но это потом.
  5. Цитата(Sharf @ Oct 1 2016, 20:31) Что еще можно проверить? Например адреса чтения/записи - у вас кстати второй банк 0xD0000000 ++. Соответствие выставленных таймингов с тактовой и временем из доки на память. В доке большая часть параметров привязана к времени а не к тактовой. А у вас тактовая памяти получается 80мгц !!! - ниже некуда. Первый PLL не может корректно умножать пограничные частоты в 1мгц и в 2мгц - середина умножается корректно и гладко, 1,5мгц - идеально. Кубик игнорирует установку подтяжки на используемые ноги, а делать это ручным способом весьма утомительно. Дата в землю, адрес без подтяжки, управление: sdclk, nbl0, nbl1 - в землю, - остальное в плюс. После чего становится доступным спящий режим. Забыл: ноги нужно лочить, чтоб не слетали при дальнейшем неаккуратном инсталле. Ну и наверное главное, хотя уже упомянули создание раздела в линковщике - забыли напомнить про копирование инициализированных переменных из флеша. Сделать эту операцию корректно из С кода - весьма проблематично. А в случае применения хала - практически не реально. Так-шта в выигрыше старый добрый SystemInit запускаемый до копирования в sdram кучи переменных, с таким расчётом чтоб майн запустить на всём готовом.
  6. Цитата(truppik @ Sep 30 2016, 21:41) а не проще ли для всего этого ставить просто внешний детектор? к примеру MAX811 Этому супервизору мозгов хватит только на ресет чипа, с чем кстати прекрасно справляется аппаратный ресет преференции ядра самого чипа. От сбоя отложенной записи флеша - не спасёт, от защиты BKRAM - то-же, ну и есно вращающийся движок надолго останется на выбеге, и последнее - стоимость выше ста рублей. Задействовать PVD - два smd резистора!!!
  7. Цитата(Forger @ Sep 30 2016, 18:35) Это от чего нужно питать камень, чтобы так плавало питание? От батарейки? От любого автономного источника питания, наличие плохого контакта не должно гробить прошивку, как и работу самого алгоритма чипа. Входное напряжение стабилизатора, через делитель на лапу PVD, её входной ток в пределах 80мка в сторону от VDD, (не в землю!!!). Можно сказать что между VDD и лапой PVD - измерительный мост. Последовательность: сработал внутренний ресет - старт работы ядра чипа, по факту напряжение 1,8в. Активируем прерывание по нарастанию PVD до напряжения нормы для внешнего стабилизатора, особо торопящиеся могут запустить инстал части периферии, потом уход в ожидание прерывания. В прибывании PVD переключаем вектор обработки на спад, и установка нижней границы безопасного уровня напряжения внешнего стаба, перезапуск прерывания. После ожидания внешнего прерывания - код автоматом стартует при выходе из PVD. Можно безопасно выполнять программу. При снижении напряжения внешнего стаба ниже порогового уровня - снова срабатывает PVD. Дальше уже всё зависит от требований надёжности алгоритма. Запасённой энергии во ВНЕШНЕЙ ёмкости на входе внешнего стабилизатора - хватит на 10-500мс. При этом напряжение питания самого чипа будет стабильным. Времени хватит на завершение записи сектора флешпамяти например, или на аварийное гашение внешней периферии с сохранением всех требуемых таймингов. В любом случае после цикла обработки аврала - необходимо произвести программный сброс, либо программное выключение (с бесконечным циклом). Например для векторного движка можно применить только программное выключение, потому как механика ещё вращается. А для системы сбора инфы - достаточно программного сброса. И ещё, вешать большие ёмкости на ноги чипа - нет смысла, но на входное питание стаба - да.
  8. Не понимаю, зачем внешний супервизор - при наличии собственного в мк, более крутого. При работе мк от солнечной батарейки - начинаются "весёлости", которые простым способом в лоб не решить. Я юзаю PVD на нарастание а позже на спад - два разных уровня.
  9. Цитата(arhiv6 @ Sep 25 2016, 18:24) Даже ассемблер не нужен, всё сделает компилятор. Очень большое заблуждение. GCC настолько оптимизирует код - что функции ос размазываются по всему контексту. Прямые вставки на асме заставляют выполнятся код в нужном месте, в уникальном порядке. Второе, сам переключатель не столь важен, он просто должен быть быстрым. Важна сама организация стеков. Тут всего три подхода: Глобальное использование препроцесора, при этом новых задач создать невозможно, так-же как и удалить - но зато моментальный старт. Создание/удаление задач в области хелпа, когда маллок выделяет кусок памяти единый для переменных и стека одной задачи - применяется почти всеми ос, недостатки - система деревянная по пояс. В случае когда в задаче временно используется массив большого размера - остальное время получим перерасход памяти. Третий вариант: статический стек прерываний + динамический стек задач - есно вниз. Динамическое выделение памяти под переменные в области хелпа - есно в верх. Ещё больше гибкости, но и больше накладных расходов. Четвёртый вариант: аналог третьего с небольшим исключением - плавающая граница между нижней планкой стека и верхней планкой памяти переменных. Позволяет впихнуть невпихуемое в самый маленький мк, и заставить двигаться то - что двигаться чисто физически не может. (почти автоваз) Литература для обучения и создания собственной ос http://badembed.ru/assembler-pereklyuchenie-konteksta/ Моё https://bitbucket.org/AVI-crak/rtos-cortex-.../branch/default на орфографию не обращать внимания - это глюки.
  10. LTDC + ChromART в STM

    Когда требуется сложить два слоя с разным форматом и разной площадью - то смещение считается не в пикселах, а в байтах!!! Точно так-же как и в простом dma. Сам модуль DMA2D достаточно тупой для таких подсчётов, он просто гонит поток данных через свою матрицу, заниматься расчётами приходится пользователю. Перед смешиванием оба потока преобразуются в ARGB 32бита, и выхлоп уже считается в пикселах. Для того чтобы юзать DMA2D в полном масштабе - придётся написать собственную функцию, с прямым обращением в регистры. При этом глубина изменений (количество меняемых регистров) - напрямую зависит от разнообразности режимов. Универсальный модуль есно меняет всё, но и запускается медленнее всех, хал - это универсальный способ!!! Посему выбирается некий компромисс, с отбрасыванием неиспользуемых режимов - вот тогда будет всё летать.
  11. Флэшка W25Q256FV + STM32F4xx

    Цитата(hd44780 @ Aug 6 2016, 13:47) Подключалась в плате с процами всегда проводками ~10см. может наводки прилетели и убили её? Аурдиновские ноги из под рухнувшего проекта. Всё что работает на частотах выше мегагерца - необходимо устанавливать на печатную плату, на длинных проводах такие вещи просто не работают. Второе - режим записи устанавливается не мгновенно, чипу необходимо время для входа в режим. Пока чип в режиме ожидания - все остальные команды игнорируются.
  12. Посоветуйте RGB дисплей

    ER-TFT070-4 , но не советую покупать через али - там перекупка. Дисплей с одним питанием цифровой части - 3,3в, подсветка 27в внешнее питание, тач весьма хитрый - если нет желания потерять часть изображения - проще купить у производителя дисплеев. И это не ips, хотя это уже странно, за такие-то деньги.
  13. Изменение частоты SDRAM.

    Цитата(jcxz @ Jun 21 2016, 19:59) Проект на LPC1788 + SDRAM. Необходимо в ходе работы изменить тактовую частоту CPU. У sdram есть собственная команда глубокого сна. После такой команды не требуется внешний клок, можно вообще всё остановить. Но есно мк должен быть настроен на реген sdram силами самого sdram. Сейчас уже трудно найти чипы без таких функций.
  14. STM32F439IIT6 + LTDC дисплей

    Цитата(hd44780 @ May 5 2016, 01:39) Хотя после откровенной неправды в ДШ насчёт напряжения подсветки (указано 9.9в, оказалось 18-19в), я вообще сильно сомневаюсь в его корректности. По докам этот дисплей имеет весьма оригинальную последовательность подачи напряжений при запуске и гашении. Для таких типов дисплеев существуют спец чипы: с собственной двойной-тройной экранной памятью, куче "аппаратных" графических функций, и множество типов входных сигналов (от 8080 до композитного). Чип аккуратно на аппаратном уровне регулирует подачей-снятием напряжений с матрицы. Сама матрица весьма нежная в этом плане, управляющие полевики в пикселах умудряются сдохнуть миллионом вариантов. Хотя обычно выдерживают разряд статики в экран. Чего собственно у меня и произошло. RGB матрица без контролёра. Питание шимом двумя полевиками от ног st, с обратной связью. И такой облом, в режиме отладки забыл разрешить тиканье именно этого таймера. В результате, пока жахал кнопку нехт на отладчике - дисплей терял целостность.
  15. Электрические помехи и STM32

    Непонятно, в чём смысл возврата в точку сбоя при аппаратном сбое периферии мк. В таких случаях просто необходим сброс периферии, и новая начальная инициализация. Есть вариант хранить критические переменные в защищённом месте, с двойным тройным резервированием - для восстановления стартовой рабочей точки. Но возврат в точку слома - просто невозможен. Для развязки управления по высокому напряжению, и высоковольтным импульсным помехам - применяют воздушные оптопары. Это единственный способ изоляции от искры.
  16. ARM c TFT контроллером и RAM > 2M

    Цитата(Шаманъ @ Apr 26 2016, 02:01) Нету там багов. Не путайте попытку посадить на одну шину SDRAM и ТФТ со своим контроллером и то, о чем пишу я SDRAM+LTDC. Кубик настраивает sdram на "ручное" управление регенерацией, то-есть сохранением памяти занимается контролёр интерфейса sdram от мк. Это выгодно при малом объёме памяти и включённом LTDC - сам реген чудесным образом попадает на нужные адреса памяти при чтении экранной области, страницы оставшиеся в тени обновляются контролёром шины - их мало и проблем не возникает. Это приметно так-же выглядит как старинном спектруме, там тоже память обновлялась при скане экранной области. Но всё меняется при повышении жирности памяти. Self регенерация уже не настолько эффективна при объёме памяти 64 метра. А при наличии дополнительных девайсов на внешней шине - self даёт откровенный сбой. Особенно ярко это заметно при записи флеш памяти. Но если применить чип sdram с автоматической регенерацией - то все задержки по барабану. Собственно найти чип без внутренней автоматической регенерации очень сложно, обычно это очень древние чипы с космическим ценником. Авторегенерация включается в первом обращении по шине памяти к чипу sdram, собственно это первая запись в чип при настройке.
  17. STM32 + RTC & BACKUP

    Цитата(esaulenka @ Apr 19 2016, 23:23) Пролёт "мощных ступенек" не зафиксирован. Также очень хочется подтверждений. Цирк начинается при использовании двух разных стабилизаторов для Vdd и Vdda. Потребление по линии батарейки - мизерное, даже внутренний ключ имеет сопротивление в сотни ом. Но вот стабилизатор для питания часов очень нежный - ступеньку передаёт на ура. Это видно при подключении к часовому кварцу, иных внешних линий от этого домена не существует. amiller - функции для работы с часами необходимо переписывать самостоятельно, по докам на выбранный чип. Кубик заточен под макетки st - там просто нет батарейки.
  18. STM32 + RTC & BACKUP

    Vss и Vssa - должны иметь общую точку. Vdd и Vdda - даже при использовании двух отдельных стабилизаторов - должны иметь мостик связи через диоды (+-0,5v). При включении и выключении чипа на этих ногах напряжение должно расти синхронно. После может колбаситься на +- пол вольта - в зависимости от ваших стабов. Похожий дефект во всей серии st с разнесёнными линиями Vdd и Vdda - логика делает ошибочное раннее/позднее переключение режимов внутренних стабов, отчего собственно и сбоит. Ёмкость на батарейке лишняя, точнее: чем выше сопротивление батарейки - тем система устойчивее. Нормальный человек подключает резервное питание через диод. Но в компании st работают инопланетяне, там резервное питание включается полевым транзистором. А когда уровни коммутируемого напряжения не совпадают - на стаб прилетает мощная ступенька, которая без проблем передаётся дальше по всем линиям.
  19. LTDC + ChromART в STM

    Кстати, у чипов st их ускоритель имеет всего две полезные функции: заливка цветом и копирование памяти с прозрачностью. Именно для последней функции требуется огромное количество памяти, иначе теряется смысл dma2d. Тут встроенной памятью не обойтись.
  20. LTDC + ChromART в STM

    Цитата(mantech @ Apr 15 2016, 01:02) Вы какое хоть разрешение экрана используете? Проверял на 2х ядерном LPC(не помню номер его) ... Внешняя sdram с безграничным презрением смотрит на любой чип рядом с собой - она не будет работать быстрее чем записано в её доке. Для описания скорости "работы" nad памяти - у меня не хватит ругательных слов. Лично я жду доступную оптическую память на кристаллах. Уже наверное скоро изобретут.
  21. LTDC + ChromART в STM

    Цитата(Шаманъ @ Apr 14 2016, 15:56) По сему как раз разница между 16 и 32 битными шинами будет очень приличной Или Вы про что-то другое? Сухие цифры: самый не оптимальный режим - 2 слоя, запись в буфер, и его-же отображение на rgb выхлопе - пред выборка по 8 32b слов. 8 бит: адрес 10 тиков + 64 тика на чтение = 72 тика на заполнение буфера. 16 бит: адрес 10 тиков + 32 тика на чтение = 42 тика на заполнение буфера. 32бит: адрес 10 тиков + 16 тиков на чтение = 26 тика на заполнение буфера. 32бит sram 10nc: 2 тика на чтение = 16 тиков на буфер из восьми выборок. Разница в скорости между 16b и 32b - 1,6, до двойки не дотягивает - зато освобождает сражу 16 линий мк. А вот для sram уже не жалко все 32b выделить, и даже махнуть рукой на прожорливость системы. Потому как скорость чтения/записи практически равна скорости выборки из внутренней sram (необходимость каждый раз качать права на шине арбитра - 1 такт). Но вот из всего многообразия современной и быстрой sram памяти 10nc - самая дешёвая на 8 метров имеет ценник в 3 бакса, и не совсем гуманный бга корпус. А ценник на 64 метра - просто улетают в космос, получается в сто раз дешевле поставить 8 восмиметровых чипов.
  22. LTDC + ChromART в STM

    Вся разница в 16 и 32 бита шины sdram на st чипе - буквально 2 тика. Латетность совершенно одинаковая, и составляет в лучших вариантах 10 тик + 2 тика первое чтение. Попав на потоковое чтение выбранной страницы - чтение/запись будет без выборки адреса. У ускорителя st производится непрерывная предвыборка в половину буфера - это 8/16 32d слов. По сему разница в скорости от ширины памяти не столь заметна. Максимальная скорость достигается при использовании внешней sram памяти, очень желательно на 10nc. У st есть макетки с использованием такой памяти, но чего-то они не прижились - ценник ломовой.
  23. Освоение ARM контроллеров

    Цитата(zltigo @ Apr 13 2016, 04:52) Это Вы маятесь дурью НЕ задавая размера стека в безосновательной надежде, на то, что он не наедет на кучу. Желаю вам научится читать чужие сообщения.
  24. Освоение ARM контроллеров

    Цитата(zltigo @ Apr 13 2016, 01:49) Как и любое выделение памяти. Нулевой это перебор. Можно указать в для статической линковки какой-то минимальный размер для старта системы. Потом уже при запуске узанать верхнюю границу памяти и сказать мереждеру, что от начала статически слинковоного блока и до конца свободной памяти все его. Ну я и вижу как вы мучаетесь, в ручном режиме считая байты. Нижняя граница свободной памяти равна стартовому адресу heap, этого более чем достаточно для моего менеджера памяти. Хотя я надеялся увидеть хитрую трёхэтажную запись мнемониками перепроцесора самого GCC.
  25. Освоение ARM контроллеров

    Цитата(zltigo @ Apr 12 2016, 23:13) Следует слегка постараться и отдавать хипу всю память от конца статически распределенной компилятором до конца памяти контроллера. Интересно, каким способом??? Я например точно знаю что GCC не умеет считать размер стека прерываний в режиме перепроцессора. Уже потом в отладке, фоновым процессом самого отладчика контролируется нижняя граница, и только в одном режиме ядра - для ос это уже недоступно. Копал долго и упорно, но возможно что-то упустил. Для себя эту проблему решил простым способом: heap условно растёт в верх, на встречу стеку. Условно, потому-что свой heap, для gcc он нулевой, используется только точка старта. При заполнении всей памяти - новые задачи и новый маллок морозится, пока жирность не спадёт. Очень удобно однако.