Fun Electronic

А вот и снова я!

Надеюсь, не заскучали тут без меня?

У меня есть уважительная причина — я отлавливал баги в софте плеера. И довольно таки много отловил.

В прошивке ПЛИС от Xlilinx заменил модуль выбора банков памяти на VHDL аналог, написанный с учетом всех особенностей адресации памяти и схемы.

В софте, соответственно, сделал изменения в системе Кучи (Heap), так как она напрямую связана с адресацией внешней памяти.

Теперь у меня используются все банки памяти.

Нашелся старый баг, заложенный мною же пару лет назад по тогдашней неопытности — в системе проигрывания MP3 файла использовался один из банков, и так как в то время я еще не совсем знал, на что мне потратить такое количество банков (30 штук), то я выбрал второй, с номером 1 (нумерация идет с 0, как мы помним). И вот он сейчас вылез боком, когда банк с этим номером использовался так же для хранения технической информации о всех файлах, найденных при сканировании дисков.

Система работала до первого проигрывания файла, играла первый файл хорошо, но при попытке выбора следующего — зависала и перезагружалась Вачдогом.

А не находился этот баг так долго потому, что я, по тогдашней неопытности, сделал выбор банка в обход интерфейса управления банками памяти, напрямую записывая в регистр банка его номер. Вот нам и урок на будущее — организовывайте доступ к какому либо модулю посредством интерфейса, и используйте только его!

В самом софте пока что сменил команды доступа к дисками с простых присваиваний на свои функции, которые пишут и читают не черех интерфейс внешней памяти контроллера, а путем прямого управления портами PORTA, PORTC и пинами N_RD, N_WR и ALE. На такой шаг замедления процесса чтения я пошел из-за того, что текущая прошивка CPLD немного подтормаживает при обработке адреса, и с момента выставления сигналов N_RD или N_WR проходит около 100 наносекунд, что очень много, так как нам надо успеть еще установить сигналы выбора дисков, немного подождать и потом установить сигналы чтения дисков. Если между этим двумя событиями не ждать, то что диск, что карточка, нас не поймут, и мы ничего не считаем с них. Временные параметры надо выдерживать.

Так вот. Пока мы это все выставляем тут и ждем, процессор нифига не ждет, надо сказать. И соответсвенно, ничего не считывает, или же очень малый процент считываний проходит успешно. На жестком диске это все как то еще работало, а вот карточка уже не успевала. И это была еще HS карточка, т.е высокоскоростная. А я попробовал поставить карточку помедленней — так ее даже не распознал плеер. Т.е. вообще никакой инфы не считалось.

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

Но я, естественно, собираюсь оптимизировать прошивку cpld, не без помощи своего друга из Москвы, McSim, что бы увеличить скорость. А то уж больно медленно получается, чем было до этого.

А пока, как и обещал в прошлый раз, поговорим о методах работы с шиной M-Bus. О том, как считывать даный из нее, и как в нее писать что-либо.

Процессы чтения шины и записи в нее управляются посредством перерываний. Для чтения мы используем внешнее прерывание от ноги процессора, на которую предварительно завели сигнал с шины. А для записи — используем таймер.

Процесс чтения начинается по прерыванию по падающему фронту:

Разберем его по порядку.

В строке 188 мы проверяем, а надо ли нам воомще что-то принимать. Иногда бывают такие моменты, что лучше вообще ничего не слушать.

Если же мы решили, что нам все таки стоит послушать, что в мире творится, то далее смотрим, в каком месте находится наша система приема сообщений — в каком состоянии приема.

Всего их 4:

case MBR_WAITING: — Тут мы находимся, когда мы только только начали прием, или же мы уже приняли очередной бит, и ждем, когда же нам пошлют следующий, этакое междубитие. От этого пункта мы переходим к следующему без задержек.

case MBR_FALLING: — И так — пин упал в 0. Самое время засечь то самое время, сколько наш пин пробудет в этом состоянии 0.

Выставляем параметры таймера, обнуляем его счетчик и устанавливаем способ следуюго входа в наше прерывание, уже по восходящему фронту.

case MBR_RISING: — Тут начинается самое интересное — определение времени, которорое прошло между спадающим и восходящим фронтом по значению счетчика таймера. И в соответствии с длительностью уже выставляется текущий бит в 0 или 1. Далее мы увеличиваем счетчик принятых битов, ставим способ входа в наше прерывание опять по спадающему фронту, и ставим статус приема уже в MBR_FALLING.

И так по кругу.

Опытный читатель скажет, а как же мы определим, когда пакет закончился то? А то ведь так можно безконечно биты принимать, когда-то надо бы и определиться, что биты для этого пакета закончились и пошли уже биты следующего.

Правильно! Для этого в строке 227 стоит вызов функции SWTLoad (SWT_MBUS_PACKET_TIMER, SWT_MBUS_PACKET_TIMER_VAL);, которая устанавливает софтовый таймер на 6 милисекунд. Я тут пробовал разные значения и именно с этим получил самые хорошие результаты определения конца пакета.

Значит, таймер запустили, теперь надо бы его и обработать:

В аппаратном таймере происходит проверка нашего софтверного таймера:

И, если софтверный таймер сработал, вызывается функция MBus_ReceivedPacket ();:

в которой мы ставим наш приемник в состояние неприема — то самое 4-е состояние MBR_DONT_RECEIVE, вывешиваем флаг, что данные приняты, и запускаем уже другой таймер для задержки между приемом и отправкой ответа. Я опять же поэкспериментировал, и понял, что вот прямо сразу после того, как мы внимательно выслушали команду, лучше не болтать, а малость подождать, а то не поймут ведь.

Ну а далее все просто — в функции, которая у нас работает на каждом проходе основного цикла программы, мы проверяем этот флаг MBRProcess.bReceived на предмет наличия в нем 1, и обрабатываем данные.

Про то, как мы общаемся с шиной, я расскажу через часик, а то тут много текста получилось. До скорого!

P.S.:

Совсем забыл. Обновленные прошивки: mmp3p_v_01_01 и xilinx_v_01_01.

Вот.