7 сегментов и динамическая индикация Опции

[_Pasha]

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

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

[Eddy71]

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

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

О май гад... В асме это проще выглядит... ;-)
Во всяком случае, мысли впихнуть перекодировку ASCII->LED у меня не возникало..
На семисегментнике ведь много не нарисуешь и в 99% хватает минимума типа Err F-1 F-2..
Постараюсь подумать, как свою мысль перевести на общечеловеческий (Си) язык..

[_Pasha]

В асме это проще выглядит... ;-)

Вы ж поймите: тут задачи другие. Помимо того, что на индикатор может выводиться с тех пинов, с которых удобнее развести на плате, и не обязательно эти пины будут на одном порте,  так еще появляется соблазн делать программу переносимой на любой МК. На асме выполнима только первая часть.

[VladimirYU]

Вы ж поймите: тут задачи другие. Помимо того, что на индикатор может выводиться с тех пинов, с которых удобнее развести на плате, и не обязательно эти пины будут на одном порте,  так еще появляется соблазн делать программу переносимой на любой МК. На асме выполнима только первая часть.

У нас конструктор печатных плат тоже любит развести платку "как проще". Работаем на С++, поэтому я в этом случае делаю очередной производный класс, в котором определяю "виртуальную" шину, например для того же ЖКИ. А все остальные функции уже используют ее и не требуют изменения в своей реализации. ИМХО сдесь объектно-ориентированный подход очень хорошо ложиться.
А вот с переносимостью пока только в пределах семейства, все-таки организация на физическом уровне может отличаться. MCS51, PIC, AVR, 196, 166. Нужно писать порты под каждую платфому.

[_Pasha]

Нужно писать порты под каждую платфому.

Если Вы смотрели то, что я выкладывал, то там переносимость обеспечивается отвязкой от прерывания через опрос тиков системного таймера, PROGMEM тоже легко будет на const _flash или чего-то подобного - сделаю, как и чтение этого PROGMEMа. И еще мой вариант учитывает возможный опрос линий возврата клавиатуры:

Код

#include "keyb.h"
#include "led7.h"
#define T5ms 5000

static timer_t screen_time =0;

if(time_diff(screen_time) > T5ms)

{
 screen_time = get_time();

// в таком случае связи модулей led7 и keyb нет вообще
 do_keyboard(le7s.pos);
// делаем то,что надо с экраном
 do_screen();
}

В принципе, можно определить указатель на экран как входной параметр
do_screen(led7_scr_t *screen)
Тогда можно описывать do_screen где угодно - например в главном модуле. Что думаете?

[Eddy71]

В принципе, можно определить указатель на экран как входной параметр
do_screen(led7_scr_t *screen)
Тогда можно описывать do_screen где угодно - например в главном модуле. Что думаете?

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

Причина редактирования: Удалена лишняя часть цитаты.