Rokl

Видел я на Радиокоте вертикальный скролл в часах на матричных СИД 24х8.
Только там 4 разряда, а не 6 и вертикальный скролл часики выполняют раз в минуту, а не постоянно. Да и не один МК этим занимается, а в паре со сдвиговым регистром. Ну, это частности и профессионализм автора не умоляет, отличный проект.
Или вы ещё какой проект нашли с 6 разрядным вертикальным скроллом на МК ?

Rokl

Спасибо за ссылку. Сами часы там устроены на чипе DS1307, а не на МК. МК лишь занимается выводом на матрицу 48х8 показаний с DS1307. Да и без 7 шт. сдвиговых регистров в помощь МК в том проекте было не обойтись.
Есть и недостатки работы МК в виде неравномерного вывода скролла и как следствие, артефакты в разрядах. Это происходит из-за програмной обработки алгоритма вывода и от этого в МК ни куда не деться.
В моем проекте такого безобразия в принципе быть не может.
Проект замечательный, но до конца к сожалению не доведен, оборван мартом 2013г.
Так что рекомендовать сырой проект под протеусом, без изготовления работающего образца, в котором устраняются "подводные камни" протеуса, по меньшей мере, странно.

korsaj

А разве минус схемы если она имеет в своем составе DS1307? И что такого страшного в 7-ми регистрах? Со скролом все хорошо, нет там артефактов, больше замечаний к камере на которую снималось видео.
Проект может и сырой, но реализован в железе.
 

У мк возможностей больше, намного больше, потому что он гибче чем набор логики.

Rokl

Так где законченое устройство в корпусе? Авторы решили добавить пульт ДУ, датчик температуры, и где демонстрация всего комплекса?
Из этого я сделал вывод, что устройство либо ушло в коммерцию и потому публикация прервана, либо авторы не закончили проект.
Кстати, даже на последних видеороликах, где изменен шрифт, видны артефакты. Цифры меняются рывками. То быстро двигается вниз, то чуть привстанет, потому съемка такая неважная получается (в моем варианте все тайминги постоянны 0,5 сек вывод, 05 сек стоим. У авторов 0,7 сек вывод 0,3 сек стоим(по словам авторов). У меня 0,5 сек/8 строк каждая строка индицируется ровно 0,0625 сек, потому изображение на видио идет плавно и чисто, как и если глазом смотреть. У авторов 7 строк /0,7 сек получаем 0,1 сек, да еще и изменяется из-за занятости МК(возможно не успевает МК быстрей программу обработать). Т.е. даже при равномерной индикации в 0,1 сек строки, уже будут заметны дерганые смещения строки вниз, а когда интервал увеличивается, или уменьщается, возникают ощущения неравномерности движения цифры сверху вниз, а на экране заметны из-за этого возникающие артефакты в разрядах. Так что в конкретном случае жемткая логика имеет явные преимущества.

Rokl

Да не минус схемы, просто ваше утверждение, что часы сделаны на одном МК не верно и всё. МК лишь работает с дисплеем, а не считает время. Просто вы слишком широко трактуете свое утверждение .... сделано на одном МК... и я указал на это.
Вот вот, и авторы грешат на видео, а на самом деле смазаные цифры на видео следствие неравномерности вывода цифры на индикатор.
У меня же таких артефактов нет из за жесткой синхронизации по времени, или вы думаете, что мой вариант снимался на профессиональную камеру?

По поводу железа... на экране присутствует только плата индикации со светиками, и только. Это далеко не весь девайс. Да ни кто и не спорит, что МК гибче. Да, гибче, но когда нужно выполнить всего одну конкретную, но сложную функцию, то бывает, что простой МК не справляется.
Наверняка, какойнибудь DSP проц вполне корректно бы выводил вертикальный скроллинг даже на 8 строках.

korsaj

Любой 8-ми битный мк справится со всем.
Далеки вы от программирования. Почему вы решили что мк не может обеспечить "тайменги"?
То что вы пишете в отношении мк - это бред.

Любой начинающий программист знает что в мк есть прерывания от таймера, и что точность их возникновения равна точности кварца от которого работает мк.

Rokl

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

korsaj

Чем больше вы пишете, тем больше видно что ваши познания в данном вопросе мизерны.
Обмен данными с DS1307 ведется по протоколу I2C, который не имеет жестких "таймингов", так как является синхронным.

Если даже возникает такая ситуация что необходима "жесткая" привязка к временным параметрам протокола (например DS18B20), все можно переместить в прерывания от таймера используемое для индикации. Тогда каждое прерывание будет попадать в "жесткие" рамки протокола обмена. Все что нужно - выбрать нужный период генерации прерывания.

korsaj

Ничего не будет пропущено..
Нет, не скажется, она будет выполнятся с одинаковыми временными интервалами.

korsaj

Зато вы в логике хорошо разбираетесь, за что огромный респект.