Сведение программных модулей к неким стандартам

@dimyurk1978 · Регистрация: 06.12.2016

Студворк — интернет-сервис помощи студентам

Что-то в голове на данный момент каша. Проблема на данный момент следующая: вывод информации. Вывод может осуществляться на ЖКИ дисплей, на 7 сегментные индикаторы, в UART, наконец.
И каждый раз приходится переписывать модули. Так как на дисплей в своем формате, на светодиодные индикаторы в своем. В данный момент нужно выводить на 7 сегментные индикаторы. Притом по SPI (сдвиговые регистры). Это переделывать модуль чтобы вывести не на порты МК, а по SPI. Переделывать преобразование чисел, так как модуль написан под ЖКИ дисплей. Вдобавок, нужно определиться, чем считать SPI в данном случае. Этаким графическим модулем, или все-таки самостоятельным модулем, который не только вывод информации осуществляет.
Может кто-то уже двигался в этом направлении. Помогите определиться, свести свои наработки к некоему стандарту.

@Riftistor · 06.11.2016, 12:11

Сообщение от dymyurk1978

Проблема возникла в том, что многие функции и переменные модулей ЖКИ и семигментников созвучны.
dsp_buf,
clr_dsp_buf,
prymt_char,
prymt_buf,
prymt_val_u08,
prymt_val_u16,
prymt_val_u32,
Вот тут я и застопорился. Как мне быть. Соответственно обзывать переменные и функции или тут нужон другой подход.
Тут подсказали, что нужен C++. А я на нем не пишу.

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

@dimyurk1978 · 06.11.2016, 12:36

Сообщение от vt340

...

Примеры, плиз.

@itysiy · 06.11.2016, 12:53

Функции работы с сегментными индикаторами и дисплеем лежат в разных модулях. У каждого модуля свое название. Соответственно в каждом модуле в названиях открытых функций есть название модуля:

Code
1
2
3
4
5
6
7
8
Lcd_Init();
Lcd_PrintChar();
Lcd_GoTo();
Lcd_Process();
 
Segment_Init();
Segment_PrintChar();
Segment_Process();

И тут они уже становятся не созвучны и хорошо различимы глазу. А если еще не сокращать слова в названиях, то будет еще удобнее.
Массивы, переменные внутри модуля у меня почти всегда приватные, и для доступа к ним из вне завожу специальные функции (с названием модуля в названии функции).

@vt340 · 06.11.2016, 12:57

Сообщение от dymyurk1978

Примеры, плиз.

Щас, всё брошу, чтоб примеры на форум постить )
Какие слова непонятны?

@Myrmyk · 07.11.2016, 13:04

Универсальный подход, используемый в том числе, в ядре линукса предполагает использование интерфейсного объекта (в контексте posix также известного как Открытый Файл, но эта абстракция гораздо щире той, что нам необходини).

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

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
struct output_object {
void* pryvate_data;
int (*write)(struct output_object*, void* data, size_t len); //Это указатель на функцию!
//функции также передается  указатель на сам объект, что была возможность обращаться к pryvate_data.
 
int (*anotherFunction)((struct output_object*, void* arg);
}
 
struct output_object lcd_out = {lcd_write};
struct output_object usart_out = {usart_write};
struct output_object sivimseg_out = {sivimseg_write};
 
//Создание и разметка экземпляра pryvate_data:
...
struct lcd_pryvate_data {...};
...
lcd_out.pryvate_data = malloc(sizeof(struct lcd_pryvate_data));
struct lcd_pryvate_data* data = (struct lcd_pryvate_data*)lcd_out.pryvate_data;
data->...;
...

Сами же функции вывод будут работать поверх этих объектов.

Code
1
2
3
4
5
uprinf(struct output_object*, const char* format, ...);
uwrite(struct output_object*, void* data, int len);
uprymt_int32_dec(struct output_object*, int32_t val);
uprymt_int32_hex(struct output_object*, int32_t val);
uprymt_string(struct output_object*, const char* str);

И так далее.

Можно так же сделать специальный интерфейсный объект для спама сразу в два канала.
В случае, если есь два lcd экрана, можно иметь по объекту на каждый и использовать pryvate_data для хранения индивидуальной информации (адрес или текущая позиция).

@Myrmyk · 07.11.2016, 13:09

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

Для применения Указанной выше концепции с позиционными средствами вывода (вроде семисегментного индикатора) можно ввести специальную команду для задания положения (как еще одну функцию интерфейсного объекта) или интерпретировать перенос строки.

@Riftistor · 07.11.2016, 13:24

Сообщение от Myrmyk

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

Я в принципе это и предлагал, только на плюсах.

@Myrmyk · 07.11.2016, 13:29

Сообщение от Riftistor

Сообщение от Myrmyk

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

Я в принципе это и предлагал, только на плюсах.

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

@Otixomdr_1 · 08.12.2016, 20:54

Сообщение от dymyurk1978

использовал ЖКИ как и обычно, как отладочный инструмент. Чтобы выводил наружу требуемые переменные, состояние периферии МК.

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

@dimyurk1978 · 09.12.2016, 10:01

Вывод информации на экран предполагает использование UART и соответствующие кварцы.

Новые блоги и статьи Все статьи Все блоги /
Из невошедшего на форум (диалог с ИИ-гугла) zorxor 29.07.2026 А вот, что интересно, сказал мне ИИ-гугла: Этот текст — эмоциональный пост пользователя под ником zorxor на интернет-форуме (вероятно, посвященном мистике, непознанному или альтернативной науке). . . .	Был праздник вчера, а я и не знал. kumehtar 28.07.2026 27. 07. 2026г. Intel Core 2 Duo исполнилось 20 лет Новости компьютерного мира и их обсуждение (4) Салют, шампанское, овации! :drink:	Нейтральные знания, чистый код - бла-бла-бла-бла, на самом деле кликбейт и самореклама, плагиат, и вот почему Hrethgir 27.07.2026 То-есть отклонение такой публикации говорит само за себя, и пусть только возьмут на вооружение после отклонения публикации - это будет чистейшим актом плагиата. Отклонял Хабр. Дословно, отклонённая. . .	тв 16 бой ии anaschu 27.07.2026 Великий Перелом ИИ: Как уравнения ОДУ Radau дожали цензурные фильтры Алисы Фиксируем в мемофонде Теории Всего беспрецедентный факт в истории ИИ-зондирования. В затяжном многораундовом. . .
мв 15. непроверенное, возможно, глюк anaschu 27.07.2026 НАУЧНО-АНАЛИТИЧЕСКИЙ ОТЧЕТ. РАЗДЕЛ 1. 1: «НАУКА» (РАСШИРЕННАЯ СТЕХИОМЕТРИЧЕСКАЯ И ГЕНЕТИЧЕСКАЯ ВЕРСИЯ)Тема: Теоретическое обоснование инвариантности 19-мерного тензорного ядра непрерывных ОДУ и. . .	Очистка реквизитов и табличных частей документа при копировании (вариант 2) Maks 26.07.2026 Алгоритм из решения ниже разработан на примере нетипового документа "ЗаявкаНаРаботу", разработанного в КА2. Задача: Заменить алгоритм запрета копирования документов для сотрудников с ролью "Стажер",. . .	Доктрина интенционального знания - Доктрина для портала "Срез". Hrethgir 25.07.2026 Может найдётся кто захочет оценить доктрину. . . Написания правил участия для меня роскошь, требующая лимита времени, поэтому все сообщения не прошедшие модерацию будут видны только участникам портала,. . .	сукцессия 44. Решил подать на припринт в межународные сервисы препринтов. Но нужно одобрение от ученых anaschu 25.07.2026 Английский вариант. Пока кто то не одобрит мою личность, мне не получиться это опубликовать на препринте. Но заявку на публикацию статьи я сегодня подам.

@dimyurk1978 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 3,044

	Сведение программных модулей к неким стандартам 05.11.2016, 01:15. Показов 7527. Ответов 29 Метки нет (Все метки) Что-то в голове на данный момент каша. Проблема на данный момент следующая: вывод информации. Вывод может осуществляться на ЖКИ дисплей, на 7 сегментные индикаторы, в UART, наконец. И каждый раз приходится переписывать модули. Так как на дисплей в своем формате, на светодиодные индикаторы в своем. В данный момент нужно выводить на 7 сегментные индикаторы. Притом по SPI (сдвиговые регистры). Это переделывать модуль чтобы вывести не на порты МК, а по SPI. Переделывать преобразование чисел, так как модуль написан под ЖКИ дисплей. Вдобавок, нужно определиться, чем считать SPI в данном случае. Этаким графическим модулем, или все-таки самостоятельным модулем, который не только вывод информации осуществляет. Может кто-то уже двигался в этом направлении. Помогите определиться, свести свои наработки к некоему стандарту. 0

@Myrmyk 0 / 0 / 0 Регистрация: 20.07.2012 Сообщений: 620
	07.11.2016, 13:09
	Что касается SPI, он не ложится в формат потокового ввод-вывода... Так что к его лучше спрятать за более потоковую асбстракцию. Для применения Указанной выше концепции с позиционными средствами вывода (вроде семисегментного индикатора) можно ввести специальную команду для задания положения (как еще одну функцию интерфейсного объекта) или интерпретировать перенос строки. 0

@dimyurk1978 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 3,044
	09.12.2016, 10:01
	Вывод информации на экран предполагает использование UART и соответствующие кварцы. 0