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

AlanDrakes

Участник
  • Публикаций

    104
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о AlanDrakes

  • Звание
    Частый гость
  • День рождения 31.01.1988

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Россия, Омск
  1. stm32f407 SPI обнаружил косяк

    Такое поведение я бы понял при наличии буферов FIFO на кристалле (в частности, для STM32F745 / F3xx / F030 такое поведение нормально. Данные загружаются в регистр данных, но попадают в FIFO буфер, в очередь передачи (размер - 32 бита), и фактически буфер передачи в этот момент становится пуст. Но в указаном Вами кристалле, FIFO не описан, значит его и быть не должно. Если есть логический анализатор - можете попробовать выводить отладку на пины. Сверьтесь с графиком 248 (параграф 25.3.9) по передачи данных со стороны ведомого контроллера. Естественно, внутренние сигналы придётся выводить во вне во время прерываний. И помните, что последние будут отставать от фактического события. Но можно сильно увеличить делитель частоты для SPI, чтобы минимизировать отставание.
  2. Как-то у меня с аналогичным дымом сгорел STM32F103. Просто очень неудачно упал силовой провод (+12V) на тестовую плату. Естественно, щёлк, вспышка, снесло крышу одному сдвиговому регистру, контроллер задымил. Самое странное при этом, что он продолжал работать. Естественно, минус несколько IO портов, но в консоль он продолжал слать отчёты о загрузке системы, видимости части переферии (вокруг него) и даже мог связаться с соседним контроллером по внешней шине. Ток потребления, конечно, ушёл куда-то за 100мА. Но через минуту и это перестало работать. Да, пробой по кремнию прямо внутри кристалла это очень печальная штука. :(
  3. +1 Бэкапы-то сделали? А вообще, какой же он стал страшный :( Шрифты - ладно, читаемы. Переносы в блоке профиля пользователя - позабавили (слово "Микроконтроллеры" слегка порвалось, но это так, менлочи на самом деле). Половина заголовков на русском, половина - на английском. Постоянно запрашивает какие-то разрешения для сайта. Зачем? Раньше такого не было и было нормально (лично мне). И, да. Здравствуй, гигантизм кнопок :(
  4. stm32f4 + Chan's FatFS

    Пилил я как-то свой тест скорости карточек. Не оптимальный до ужаса. Тем не менее, результат был таким: File created. Write test... [0000000030.080] File write done. Total bytes written: 5242880 bytes. Time: 27684 ms. Avg: ~189 kBps Read test... [0000000036.114] File read done. Total bytes read: 5242880 bytes. Time: 6033 ms. Avg: ~869 kBps Здесь кристалл работал на ~96МГц, возможно, меньше. SDIO тактировалось от PLL на 48МГц. Если тактирование SDIO было быстрее тактирования ядра - работать с картой памяти было невозможно. Были у меня ещё какие-то весёлые проблемы с записью больших блоков через FatFS, хотя библиотека собиралась с неправильными параметрами, и объём памяти под неё старательно ужимался. В итоге, при записи огромных буферов из памяти (как раз размером в несколько секторов) получал странные зависания в случайных местах. В причинах не разобрался, добавив костыль, заставив код писать мелкими блоками.
  5. stm32f4 + Chan's FatFS

    Помнится мне, что вся работа с секторами происходит в файле ff.c, а работа с низкоуровнемыми командами записи - в diskio.c, где уже Вы, по желанию, можете делать запись мультисекторно, или посекторно. При наличии больших буферов ФС - драйвер технически может вызывать функцию disk_write с параметром "Количество секторов", отличным от единицы. Фактически, единственный такой вызов я нашёл в функции f_write() в том случае, если ЕСТЬ свободные сектора, куда это поместится, и размер данных больше чем на один сектор. Так что, весь разбор что и куда писать, находится выше. Драйверу же карты передаются только команды "Пиши вот это, вот сюда, в таком-то количестве".
  6. stm32f4 + Chan's FatFS

    Гарантия есть. Она в самой команде CMD25, которая пишет сектора последовательно, не получая номеров в процессе выполнения. Для её окончания даже есть команда CMD12 - STOP_TRANSMISSION. Документ SD Phisical Layer Specification так же говорит: CMD25: [Address (PTP) data transfer command] Args: [31..0] - Data Address Continuously writes blocks of data until a STOP_TRANSMISSION follows. Block length is specified the same as WRITE_BLOCK command. Переводим. "Последовательно пишет блоки данных до получения команды STOP_TRANSMISSION. Длина блока определяется аналогично команде CMD24 - WRITE_BLOCK" Для карт высокой ёмкости длина блока ВСЕГДА равна 512 (размеру сектора). Для карт обычной ёмкости её можно задавать командой CMD16 - SET_BLOCK_LEN
  7. stm32l

    На всех платах STM32* установлен ST-Link V2, которым можно программировать и отлаживать ЛЮБЫЕ кристаллы STM32. Используйте выведеный на отладчике 6-ти пиновый разъём для подключения к другому контроллеру.
  8. 2 stm32 на одну шину fmc

    Судя по рабочим диаграммам в мануалах, сигнал WAIT принимается контроллером в расчёт уже ПОСЛЕ начала обращения к микросхеме памяти. Считается, что микросхема ВСЕГДА готова к обращению после завершения предыдущей операции. По поводу же арбитража - лично я бы предложил использовать бит выбора чипа памяти в качестве сигнала арбитража шины. К сожалению, ведомый контроллер сможет узнать о том, что шина недоступна только косвенно, например, дополнительно перечитав этот самый сигнал. Никакого DMA в этом случае не будет и в помине. Обращение - только атомарное, с логикой контроля ошибки и отказа арбитража. Я бы предположил в этом случае использовать аппаратную логику типа триггера, указывающего, было ли обращение к микросхеме памяти от мастера во время обращения ведомого, или что-то похожее. Либо попробовал поискать двухканальную память, умеющую работать на два устройства паралельно.
  9. У Вас есть кристалл с уникальным ID, прошитым на производстве. Напишите что-то совместимое с CAN шиной, что будет использовать какой-нибудь специфический канал для настройки именно ведомых. Допустим, при запуске все кристаллы одновременно ломятся в шину с сообщением и посылают свой номер в какое-то поле. Происходит коллизия. Коллизия решается, выигравший забирает первый диапазон адресов. Повторить до окончания коллизий. Допустим, адреса 0x00 ~ 0xFF, каналы по 16 адресов (0x10) Посылка -> Коллизия -> Разрешение -> Выигравший забирает адреса 0x00 ~ 0x0F и замолкает. Посылка -> Коллизия -> Разрешение -> Второй выигравший забирает 0x10 ~ 0x1F и тоже замолкает. И так далее. UPD: Я тут подумал. Эту же процедуру можно проводить только в случае возникновения коллизии при ответе контроллера. То есть, сеть может организовываться полностью сама. Разве что мастер не будет знать кто где. Настройка можно хранить в выделеной странице (двух) Flash-памяти, либо на врешней EEPROM микросхеме, а перенастраиваться только при обнаружении ошибки. Я сейчас мыслю, абстрагировавшись от работы шины данных. Есть знатоки работы CAN протокола? Как можно реализовать подобное, используя стандартные методы? Хотя, в моём случае, при построении сети, работа ведётся исключительно между мастером и ведомыми. И он же выдаёт им сетевые адреса. Да, слизано с больших сетей с DHCP сервером. При этом работает по двухпроводной схеме (нет, не RS-485).
  10. SMI протокол

    Поддерживаю вариант с ногодрыгом. Интерфейс хоть и имеет близкого родича - SPI, но момент переключения данных - середина тактового импульса, плюс двунаправленность шины... в общем, когда экспериментировал - написал ногодрыг для AVR кристалла (что было под рукой) и он даже корректно заработал. Во всяком случае, отклики на команды приходили без ошибок. Удалось даже настроить подключеную физику в режим петли... и получить ругань от коммутатора, в который это всё было включено, и блокировку порта. На STM32 изначально имеется возможность подключения к интерфейсу, при наличии Ethernet модуля на борту.
  11. STM32F4. Пишем свой загрузчик.

    [zanuda mode ON] Были варианты двустороннего обмена данными с контроллером (при прошивке) с использованием шифрования и ключём на основе UID чипа. Фактически, прошивка даже клиенту попадает в шифрованом виде. Были варианты обновления прошивки по воздуху (по сети), так же, без использования прошивки в чистом виде. Аналогично, шифрованая по сети. В чём отличие именно этого загрузчика от других? [zanuda mode OFF] Точно так же, можно привязать саму прошивку к UID чипа. Таким образом, её можно сделать бесполезной для всех остальных пользователей. Дело только в сложности алгоритма и проверках.
  12. STM32F745 FMC + LCD 16-bit i8080 mode

    О, снова знакомая тема вылезла. Где-то ранее я уже с этми же бился и даже победил. И ровно та же ситуация. Ремаппинг памяти и ВСЕ проблемы сразу же ушли.
  13. Прошивка AVR через STM32F7

    На практике такое возможно. На STM я бы рекомендовал разделить память на две секции, или даже три. Первая - собтвенно, загрузчик, который должен уметь необходимые интерфейсы - SDIO/WiFi/(добавить_нужное). Вторая - приложение Третья - какие-то данные, которые лучше хранить на плате а не на внешней памяти. Естественно, загрузчик должен иметь возможность читать/писать карту, проверять версии прошивки основного приложения и (возможно) ведомого контроллера. Мегу, кстати, очень просто программировать через интерфейс ISP (SPI + Reset в качестве /CS). Где-то я подобное использовал у себя. Суть в том, что большой контроллер переводит ведомого в режим программирования, сверяет прошивку, если нужно - стирает и загружает новую. После чего отпускает сброс и позволяет тому работать уже самостоятельно. Удобно тем, что интерфейс SPI позволяет передавать и данные и сразу же прошивку (когда нужно). Можете посмотреть в документации на любой AVR* как происходит последовательное программирование. Ничего сложного там нет. А вот с загрузчиком - как раз будут сложности.
  14. Кстати, у меня в одном типе плат стоит контроллер (STM32F103). В цепи питания стоит обычный электролит на, кажется, 4700uF. Настроен PVD на уровень 2.9V (номинальное - около 3.2). Когда внешнее питание пропадает - контроллер ловит прерывание от PWD и быстро отправляет в консоль ругань, что его обесточили. Согласен, не Ваш вариант. Но в это же время можно отключить всю мощную нагрузку (хотя велик риск не успеть) и быстро доделать какие-то вещи, пока ёмкость не истощилась. Могу ещё предложить контролировать входное напряжение и при его пропадании - так же всё отключать, пока не разрядились ёмкости. Но две секунды на запись - это минимум сам контроллер + память... память - не более 25мА, судя по даташиту. Контроллер, если сбросить частоту - можно получить около 10-20мА. Берём наихудшие значения (20+25), накидываем разные утечки и всё, что нельзя обесточить (+50мА). Необходимо: 45+50 = 95мА суммарно на 2 секунды. При этом нельзя ронять напряжение ниже 2.7V для памяти. При начальном питании в 3.3 получаем разницу в (3.3 - 2.7) = 0.6V. Негусто. Теперь считаем заряд 2.7 * 0.095 * 4(с) (снова берём худший вариант и накидываем ещё резерв времени) = 1.026J Неслабо так. Минимум, который у меня получается, без использования преобразователей, просто на шине питания - 0.6F Это при токе почти в 100мА. После разряда от 3.3 до 2.7, в конденсаторе останется ещё ~1.8J. Если использовать дополнительный преобразователь: IN -> BoostCap -> Main_3.3, то можно вытянуть из него порядка 2.5J, а это около 8-10 секунд работы. Естественно, минимум потребителей и высокий КПД. Ёмкость на 3F можно просто оставить на питании и мониторить вход. Начальная энергия - 16J, Конечная - 11J (3.3 -> 2.7). А вот запуск с таким конденсатором будет довольно тяжёлым.
  15. Цитата(AVI-crak @ Apr 23 2018, 22:55) Размер BKRAM 4к. Размер сектора флеша может быть 32к-128к-256к-512к-1м - зависит от жирности и параллельности архитектуры чипа. Оно туда не влезет. Хотя для внешней памяти 25-той серии - весь сектор стирать не обязательно, и такой вариант защиты вполне приемлем. Согласен, но хотя бы иметь буфер для тех данных, которые собираемся записывать. Как вариант подобной структуры: typedef struct { uint64_t StartAddress; uint8_t WriteStarted; uint8_t WriteDone; uint8_t WerifyOK; uint16_t DataSize; uint8_t DataArray[512]; } WriteBuffer; Про размеры сектора - согласен, но я имел в виду хранение сектора перед записью. Вроди бы, большинство чипов позволяет записывать иногда даже по байту в сектор (хотя и не все), подавляющее большинство - пол килобайта. Хотя, могу быть неправ. Очень большие микросхемы пока не трогал - не приходилось.