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

@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 и соответствующие кварцы.

Новые блоги и статьи Все статьи Все блоги /
Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .	Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .
Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .	Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия	Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .

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

	Сведение программных модулей к неким стандартам 05.11.2016, 01:15. Показов 7542. Ответов 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

Опции темы