Всё по DS1307 и прочим часам Dallas (Maxim)

[ARV]

идёт регенерация SD-карты

что такое регенерация SD-карты?

иллюзии

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

я не пытаюсь доказать, что не бывает проектов, где без ассемблера не обойтись. я лишь обращаю ваше внимание на то, что заявление "не существует работающей программной реализации на Си для и2ц" - это громкое, но ложное утверждение. вам, как сисадмину (с наверняка логическим образом мышления) это должно быть ясно без комментариев.

[BOB51]

I2C штука неспешная - допускается вплоть до полного останова. Дрыголап на Си в примитиве на ардуинке "расширенными функциями" практически постоянно мучат.
Если аккуратненько распределить задачи - вполне реализуемы весьма сложные проекты.
А когда ресурсов недостает - берем МК "посолиднее" (шас он мня пилят рекламой тех же АРМов).

[ARV]

меня в некотором роде даже заинтриговала задача сишной реализации программного и2ц "по прерываниям". предположим, что мы используем таймер или любой иной источник прерываий для асихронной, т.е. фоновой, выдачи в и2ц. думал я не долго, но совершенно не вижу проблемы сделать автомат состояний, который каждое прерывание будет выдавать 1 бит в эту шину или считывать его оттуда... точнее, не бит, а смену уровней на шине делать, бит будет реже выходить... Обработчик этого прерывания будет, ну, не знаю... на глазок, если извратиться с "табличным goto", то тактов 100 занимать, не более. это 6,25 микросекунд при 16МГц тактовой - разве такое прерывание может помешать какому-то "нагруженному" процессу?! не понимаю, нафига это все нужно, но по-моему, сделать можно и даже не сильно сложно.

самое ужасное, с моей точки зрения, в фоновом обмене с периферией, заключается в том, что надо все равно время от времени "интересоваться", уже выполнена транзакция обмена или нет еще. по-моему, "последовательный" алгоритм куда проще... стараюсь по мере сил делать именно последовательно всё, чем углубляться в дебри виртуального параллелизма.

[BOB51]

Так любой 8-битный МК выполняет только одну последовательность команд в текущее время.
Иногда можно организовать псевдопараллельный процесс за счет аппаратных расширений (он то и работает на прерываниях).
В разумных пределах это касаемо светодиодного контроллера дисплея совмещенного с клавиатурой, канала последовательного обмена (если таковой представлен аппаратным модулем) и АЦП(и аналогичными схемами) плюс незадействованные таймеры (ШИМ, разнообразные модуляторы).
Там главное время исполнения программы обслуживания прерывания свести к минимуму - дальше диспетчер задач по флажкам-запросам исполнение разбросает.

[DrLithium]

[uquote="ARV",url="/forum/viewtopic.php?p=3342538#p3342538"]что такое регенерация SD-карты?[/uquote]
Согласно протоколу общения с SD-картой, должны формироваться посылки в её сторону с определённой частотой. Это накладывает свои "прелести" на остальной код. По этому чаще для общения с носителями используется отдельный контроллер, который и занимается обслуживанием всех процессов и обменом данными.

[uquote="ARV",url="/forum/viewtopic.php?p=3342538#p3342538"]это да... я, конечно, не сисадмин, но администрирование и сборка компов это как бы не совсем программирование... меня вот на протяжении, наверное, лет 5, не меньше, пытаются убедить, что метод поллинга для кнопок - это просто ужас что, тормозит весь проект, и надо обязательно работать по прерываниям. убедить пытаются, а я продолжаю без этого обходиться... и много еще чего мне пытаются доказать, да не убедительно получается...

я не пытаюсь доказать, что не бывает проектов, где без ассемблера не обойтись. я лишь обращаю ваше внимание на то, что заявление "не существует работающей программной реализации на Си для и2ц" - это громкое, но ложное утверждение. вам, как сисадмину (с наверняка логическим образом мышления) это должно быть ясно без комментариев.[/uquote]

Для кнопок (когда их много), я делают чаще опрос по таймеру. Тупо с какой-то частотой делаю снимок, и если он не равен снимку отжатых кнопок, то взвожу флаг. А после, в коде когда удобно, проверю флаг и обслуживаю нажатие если было.

Я утверждал следующее: "Программный вариант на СИ не существует - тупо не успевает, только через ассемблерную вставку." - в рамках проекта, когда нельзя было использовать аппаратный вариант, программный (а перебрал и проверил я не мало) не смог ни каким образом успеть выскочить из обслуживаемого прерывания и успеть заняться прерыванием по I2C. Что бы я не брал - не работало! Если вы вообще ни чего не делаете в проге на прерываниях, кроме самого I2C, то да тут я ошибся. Но вопрос в том, а такое сейчас бывает? Как писал выше, что то что выкладываться, должно работать всегда и везде. И если при каких-то условиях не работает, то я для себя (в первую очередь и как предупреждение другим) объявляю этот код - НЕ РАБОЧИМ! Именно так и громко, что б после не пиняли на то, что я им подсунул!

Добавлю, в моём случае регенерация SD-карты жрала большую часть ресурсов. Что и как я там решил позже, может уже и не вспомню. Но знаю одно - ассемблерная вставка справилась там, где программная реализация СИ не смогла... ни одна из найденных!

[ARV]

ну с SD-картой меня всегда устраивал вариант работы в SPI-режиме, где никакой регенерации не надо. с другой стороны, "нормальный" режим для карты (типа как параллельный) достаточно замороченный и на AVR с ним я бы вообще не стал заморачиваться - там и обмен не байтами, и всякие контрольные биты и т.п. ересь (не помню всех тонкостей). да еще и регенерация, как вы говорите - нафига оно такое?! или вы видео писали туда в реальном времени?
что за загадочная задача была, что SPI-режим не подошел?

[DrLithium]

Сам контроллер SD-карты требует. Дело не в режиме SPI. Проблема была в том, что библиотека ChaN-а ни как не хотела садиться на другие свободные вводы, для освобождения, SCL и SDA под аппаратную реализацию.

Задача была, не особо сложная, но на тот момент я не нашёл другого решения и потратил на её решение уйму времени, т.к. ни где ни чего подобного не было. А теперь отполировал её до: по разрешающему сигналу с управляющего МК, открывается временное окно для забора времени и даты с 1338 этим МК. Далее надо было сформировать имя файла и открыть его для чтения. Если ошибка открытия, то перезагрузка, иначе проигрываем файл. При этом должен работать фильтр для неопределённых жестко данных в имени файла. Пример: в 14:30 времени, файлы XXXXXX30.wav и XXXXXX1430.wav - д.б. взять для проигрывания второй, т.к. более редкий.

[ARV]

ваше умение решать проблемы, конечно, заслуживает уважения. как и умение попадать в проблемы.
какой контроллер SD требует? если мы говорим о библиотеке Чена, то там никакой регенерации нет. в AVR тоже нет никаких контроллеров SD. внутри SD есть, конечно, но не понимаю, чего он там требует... если можно, поподробнее об этом - хотя бы ссылки.

ну и вот это меня сильно удивило:

библиотека ChaN-а ни как не хотела садиться на другие свободные вводы

она что, дралась с вами? как она может чего-то не хотеть, если там ЕДИНСТВЕННАЯ функция для работы с SPI вводом-выводом? переписка этой функции на программный дрыгоног позволит использовать для карты абсолютно любые пины МК! правда, при заметном падении скорости обмена... опять чудеса какие-то вы рассказываете, не понимаю...

в моём последнем проекте я использовал SPI для вывода данных на линейку WS2812b и одновременно (!) задействовал SPI для обмена с SD-картой при помощи Ченовской либы. при этом оба обмена совершались на предельной для AVR-ки скорости обмена 8 МГц. причем для SD карты и для светодиодов были нужны разные режимы работы SPI, приходилось переключать. и вполне себе нормально выходило... ни о какой регенерации не беспокоился... самое удивительное: ни для WS-ок, ни для SD-карты я никаких прерываний не задействовал! вообще в проекте все делается абсолютно "линейно", только ИК дистанционное управление по прерываниям и синхронизирующий таймер.и я уверен, что приспичь мне в тот проект добавить обмен по и2ц, то я бы запросто это сделал в том же "линейном" стиле: почти в любом режиме моей цветомузыки в главном цикле оставалось еще примерно от 1 до 5 миллисекунд для этого - можете прикинуть, сколько байт я мог бы "программным дрыгоногом" за это время протолкнуть по шине за это время...

что я делал не так?

[DrLithium]

Проблемы, есть как и те кто ни когда не поможет когда они решаются и те кто умничает, когда проблема уже решена. Вы то уважаемый, где раньше были, когда мне ни кто помочь не мог? Теперь поздно бить себя пяткой в грудь. И кстати, не я находил проблемы, тупо был поставлен перед фактом наличия того, что работало из того, что было в свободном доступе. Это спустя пять лет, каждый школьник может почитать и посмеяться как герой.

Ещё раз и внимательно: контроллер SD-карты требует, а не МК и не библиотека. Это я помню из статей, но дальше уже не полез, понял что МК тупо не успевал. Решил задачу и спокоен как удав.

Дралась. Ни знаю как у вас, а у меня версия 0.02а, после переопределения выводов тупо не работала. Т.е. в моём случае "абсолютно любые пины" это только те, которые были назначены по умолчанию, други не работали совсем! И это факт. Что там было дальше я не знаю. Биться лбом о стену не стал, выкрутился по другому.

Может теперь бы сделал по-другому, но то что читал в сети, ни каким чудом не помогало. Ваши статьи есть где-нить?

Вообще бы не помешало найти хотя бы видос по программному I2C на СИ. Может ещё пригодится, если будет работать. Но уже не верю...

[ARV]

Вы то уважаемый, где раньше были, когда мне ни кто помочь не мог?

не знаю, где я был в тот момент, когда вы кричали о помощи... может, в туалет отлучался но вообще-то я тут постоянно, как минимум, просматриваю темы. ну и ЛС, конечно - куда ж без этого

Ещё раз и внимательно: контроллер SD-карты требует, а не МК и не библиотека. Это я помню из статей, но дальше уже не полез

ещё раз и внимательно: я прошу вас дать ссылку на инфу, где это разжёвано. хочу повысить свой уровень...

Ваши статьи есть где-нить?

на Радиокоте - есть, но очень древние, сейчас я с этим завязал. есть и на моём "персональном" сайте, есть и на Простых устройствах, и теперь вот на Паяльнике

Вообще бы не помешало найти хотя бы видос по программному I2C на СИ

какой видос?! там все примерно в одном цикле получается

Код: Выделить всё

void send_byte_i2c(uint8_t d){
   for(uint8_t mask = 1; mask; mask <<=1){
      SCL(0);
      SDA(d & mask);
      SCL(1);
   }
}

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

[DrLithium]

[uquote="ARV",url="/forum/viewtopic.php?p=3343254#p3343254"]я прошу вас дать ссылку на инфу, где это разжёвано. хочу повысить свой уровень...[/uquote]
Не, не полезу искать. Давно было, да и наверное легко находится. Вот что нашёл сейчас:
http://s-engineer.ru/mikrokontroller-ra ... -sistemoj/

И цитата: "Но учтите, простой карты после инициализации должен быть не более 5 мс, иначе вам нужно заново подать команду инициализация SD карты, т.е. CMD1 или ACMD41 в зависимости от версии."

[uquote="ARV",url="/forum/viewtopic.php?p=3343254#p3343254"]какой видос?! там все примерно в одном цикле получается[/uquote]
Чей-нить, где показано, что и как и есть успех.

[uquote="ARV",url="/forum/viewtopic.php?p=3343254#p3343254"]void send_byte_i2c(uint8_t d){
for(uint8_t mask = 1; mask; mask <<=1){
SCL(0);
SDA(d & mask);
SCL(1);
}
}[/uquote]

Цикл наверное вещь офигенная, но меня он не спас тогда, не спасёт и сейчас.

Неверное я всё таки забыл добавить, что брал не просто библиотеку, а модифицировал проект http://ra4nal.qrz.ru/wav861.shtml

[ARV]

Я, конечно, не поручусь за сказанное далее головой, но в ваших рассуждениях и в статье по вашей ссылке явно есть какая-то "неточность". Например, в статье написано, что обмен с картой ведется только блоками по 512 байт и никак иначе... А Ченовская библиотека Petit FafFs (которая, кстати, применена в рассматриваемом проекте и в вашем тоже) уверенно обходится всего 42 или 44 байтами ОЗУ. Откуда же эта библиотека берет недостающие почти пол-килобайта? откуда, кстати, в тиньке столько памяти?! Я в своём вышеобозначенном проекте использую буфер в 256 байт - и все, как можете видеть, отлично работает!

Возможно, какие-то ограничения на время готовности карты к работе после инициализации и есть, но это не имеет ничего общего с "регенерацией", и на практике ни в проекте Чена (его плейер на тини85), ни в том, на который ссылаетесь вы, ни в моем собственном, никаких ОСОБЫХ мер по "исключению простоев" более 5 мс не предпринимается. То ли и в самом деле все быстрее отрабатывает, то ли проблема надуманная, но факт есть факт.

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

Цикл наверное вещь офигенная, но меня он не спас тогда, не спасёт и сейчас

ну что ж, остается вам посочувствовать... всем помогает, а вам нет. пичалька

[DrLithium]

Возможно я уже за давностью событий что-то путаю. Вполне может быть. Но как не странно выводы сделанные тогда, помогли решить проблему. Как ни как прошло 4-5 лет как я начал проект на базе wav-плейера.

Основной факт в котором я уверен, тот что я так и не смог запустить ни одну программную библиотеку I2C на СИ, найденную мной в сети в рамках проекта параллельно. На ассемблере заработало, но позже мне пришлось рубить всё на корню. И в итоге, развёл всё во времени...

Т.ч. тут просто делюсь набитыми шишками и выводами сделанными по дорогу. Т.с. имейте ввиду, что... см. выше.

Да пичалька, наверное потому, что мои циклы с успехом трудятся под ассемлером...

[ARV]

в рамках проекта параллельно

я вот пытаюсь понять, и никак не могу: нахрена параллельно-то? даже если допустить, что между обращениями к карте должно проходить не более 5 мс - это ведь чертовски много!

[DrLithium]

Это решение (распараллелить), мне пришло не сразу. Т.е. надо было понять, что и как работает в том проекте. И только спустя время нашёл красивое решение. Но по пути выяснилось, что СИ-шные "циклы" обработки I2C, генерят такой жуткий код, который тупо не успевает обработать I2C. И как оказалось какой бы период там не был, на той частоте общения которая была выбрана в проекте для I2C, не хватало совсем немного тактовых импульсов. Т.ч. ни одна библиотека на СИ не смогла победить, ни самый короткий СИ-шный код. Наверное случай единичный, но думаю показательный.

З.Ы. Наверное надо сворачиваться, т.к. оффтопик. Успехов.

[ARV]

на той частоте общения которая была выбрана в проекте для I2C, не хватало совсем немного тактовых импульсов

и2ц совершенно все равно, на какой частоте работать. похоже, проблема в изначально некорректной постановке задачи

[DrLithium]

[uquote="ARV",url="/forum/viewtopic.php?p=3344033#p3344033"]

на той частоте общения которая была выбрана в проекте для I2C, не хватало совсем немного тактовых импульсов

и2ц совершенно все равно, на какой частоте работать. похоже, проблема в изначально некорректной постановке задачи[/uquote]

Задача была следующая: сделать звуковой модуль на базе выше указанного проекта. О какой тут некорректности может идти речь? При чём она (корректность) тут? Были рамки и задача родить рабочую версию из того, что бесплатно, доступно и работает. Что тут может быть не корректного?

Я извиняюсь, а как в вашем случае звучала бы корректная постановка задачи?

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

То что, "I2C всё равно на какой частоте работать" здесь подобное уточнение неуместно - не отражает сути. Это и так всем известно, что I2C сама генерит синхроимпульсы, с частотами определёнными протоколом. Но следует понимать, что чем выше частота, то тем короче период. Отсюда следует, что количество тактов МК для обработки события по прерыванию, убывает. В описанном мной случае сказано, что обработчик не успевал СИ-шным кодом, т.к. ему ещё надо было завершить то, что было принято в обработку ранее. Ну нельзя же взять и прервать обработчик чужой библиотеки на полуслове и приказать начать обрабатывать своё. Иначе вылет на повторную инициализацию. Добавить здесь нечего, просто факт.

[ARV]

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

у нас с вами одинаковое понимание
а теперь, мои "домыслы". вы сделали какой-то информатор, который брал время (да?) по и2ц и в зависимости от него воспроизводил какой-то файл.
проект-первоисточник воспроизводил файл "в главном цикле", т.е. сам ШИМ генерировался по прерываниям таймера путем выборок данных из буфера, а буфер пополнялся, как я понимаю, путем чтения в главном цикле.
и такой подход мне представляется логичным и нормальным.
теперь вы добавляете работу с и2ц. вы сделали это, как я понял, по прерываниям, только не понял, каким именно. и поимели проблемы, т.к. прерывания могли тормозить основные, "звуковые" прерывания, что явно отражалось на качестве звука. конкретная реализация мне неизвестна, и если я рассуждаю неверно, можете меня поправить.
что бы сделал я.
я бы и2ц читал в главном цикле. так как время меняется 1 раз в секунду, то чаще его считывать просто нет нужды. и вряд ли разумно, т.к. воспроизведение любой фразы длится соизмеримое время. считать 10 байт из и2ц - на это надо примерно 100 циклов шины, или 200 изменений уровня на пинах МК. при тактовой частоте 16 МГц на это не может потребоваться больше 2 мс, что при любом программном ногодрыге более чем реализуемо элементарно. пауза между воспроизведением файлов в 2 мс никак не может быть обнаружена.

итак, воспроиводим текущую фразу до конца. считываем время и решаем, какой файл воспроизводить следующим. запускаем его на воспроизведение. в чем подвох? уверен на 100500%, что никаких проблем с программным и2ц в этом случае не возникнет, прерываний, кроме тех, что уже есть в проекте, не потребуется. качество работы изделия никак не изменится.

ваш ход

[DrLithium]

Что ж, чуть распишу...

Естественно ни кто не мог сказать как себя поведёт инъекция в чужой проект в виде прерываний на I2C. Потратилось время на понимание, почему...
Поскольку ассемблер знаю, сделал альтернативу СИ-шному варианту, но не успокоился на этом.

Позже пришла в голову мысль, что "а не перезагружать ли мне МК по финалу проигрывания?". Сначала мне показалось, что идея достаточно бредовая. Ну ни кто ж не перезагружает МК после того, как он например зажжёт светодиод. Но позже, взвесив все за и против получил такой расклад:
1. Не доходя до инициализации SD-карты, ждём разрешения от управляющего МК по одному выводу.
Ранее писал раба, но! Оказалось, что мастера написать выгоднее, т.к. главный выдал разрешение на занятие временного окна этому МК, сам будет заниматься своими делами. Это решение тоже далось не сразу. И позволило в корне пересмотреть принцип реализации задачи.
2. Получив разрешение, этот МК как мастер запрашиваем время и дату у 1338 и на внешний раздражитель от управляющего МК, вообще больше не реагирует.
3. Составляем имя файла, проходя до дна фильтра. И если по пути находиться файл (который позволяет себя открыть), то проигрываем его. Если не находится, то ничего.
4. Перегружаем МК, выходим на дежурный режим, снова ожидая разрешения...

Вытянули всё ж из меня секретный рецепт! А я и не заметил как был разведён на интерес... ))

[ARV]

Вытянули всё ж из меня секретный рецепт! А я и не заметил как был разведён на интерес...

ну, во-первых, так хоть какой-то смысл в нашем флуде, может даже другим наука
во-вторых, из вашего алгоритма тем более не видно, для чего и2ц по прерываниям и почему что-то может не успевать! я укрепляюсь в уверенности, что вы переусложнили себе задачу и, соответственно, перемудрили с решением.