Easyelectronics.ru

Электроника для всех
Текущее время: 03 июл 2020, 15:52

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/5шт. два слоя. $5/5шт. четыре слоя
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 407 ]  На страницу Пред.  1 ... 9, 10, 11, 12, 13, 14, 15 ... 17  След.
Автор Сообщение
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 13 сен 2017, 16:26 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1204
axill писал(а):
cудя по отладчику он таки их вызывает

У меня не вызывает. Ты же отладчиком по релизной сборке ходишь?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 13 сен 2017, 16:49 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
проверял на нерелизной, должно быть отличие?

к вопросу о списке параметров переменной длины
может быть рекурсию для этого использовать?
Код:
class dummy {};
template <int n, class A=dummy> class B {};

template <class B> class C {};

typedef C< B<0,  B<1,  B< 2, B<3> > > > > c_class;


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 13 сен 2017, 18:23 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
и еще вопрос
почему static_cast здесь не работает?
Код:
uint8_t *ptr;
struct D { int i; };
D* d_ptr = static_cast<D*>(ptr);


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 14 сен 2017, 10:44 
Старожил
Аватара пользователя

Зарегистрирован: 06 ноя 2013, 16:07
Сообщения: 675
Откуда: Германия
А это как раз и есть проверка компилятора - uint8_t и struct D не наследуют друг от друга, поэтому их нельзя кастить. Тут нужно обычное приведение (D*).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 14 сен 2017, 13:11 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1204
dev писал(а):
А это как раз и есть проверка компилятора - uint8_t и struct D не наследуют друг от друга, поэтому их нельзя кастить. Тут нужно обычное приведение (D*).

Сам же говорил, что в С++ принято использовать static_cast, но в общем виде это означает, что не рекомендуется использовать старое сишное приведение, тогда вместо (D*) нужно воспользоваться reinterpret_cast, хотя лично я эти громоздкие касты в очевидных случаях не использую, например, при приведении перечисления к целому.

axill писал(а):
проверял на нерелизной, должно быть отличие?

Очень странный вопрос для разработчика унифицированной кросс-платформенной библиотеки :)

Цитата:
к вопросу о списке параметров переменной длины
может быть рекурсию для этого использовать?

Если нашел решение, то пробуй, сравнивай генерируемый код, тем более у тебя 3 разных компилятора...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 14 сен 2017, 14:00 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
Reflector писал(а):
Очень странный вопрос для разработчика унифицированной кросс-платформенной библиотеки :)

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

Reflector писал(а):
Если нашел решение, то пробуй, сравнивай генерируемый код, тем более у тебя 3 разных компилятора...

пробуй не пробуй, а альтернативы пока не видно

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

без шаблонов в С++ для этого есть виртуальные абстрактные методы коотрые описываются в родительском классе с тем, чтобы их код был реализован в потомках
но виртуальные методы это моветон для МК - под них надо выделять место в RAM
к тому же они не возможны для static, что опять же минус для МК

есть ли какой то иной способ описать базовый интерфейс с тем, чтобы его в реализации не описывать заново, а только реализовывать код?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 14 сен 2017, 15:52 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1204
axill писал(а):
попробовал Release, отлаживаемый новый проект сдулся с 2800 до 1100
но отладка не работает с ним - можно ходить только по машинным кодам, привязки к исходнику нет
так что фиг поймешь вызывает он пустые функции или соптимизировал

Огради нужный участок кода, например, вставив в начале и конце NOP, можно еще добавить софтовый брейкпоинт, чтоб не пролетало дальше.

axill писал(а):
вот скажем есть некоторая сущность которую обычно называют интерфейсом - набор методов с предопределенным входом и выходом
и есть реализация кода для них под разные задачи разные

без шаблонов в С++ для этого есть виртуальные абстрактные методы коотрые описываются в родительском классе с тем, чтобы их код был реализован в потомках
но виртуальные методы это моветон для МК - под них надо выделять место в RAM
к тому же они не возможны для static, что опять же минус для МК

есть ли какой то иной способ описать базовый интерфейс с тем, чтобы его в реализации не описывать заново, а только реализовывать код?

Виртуальные методы не так и плохи, но нужно смотреть в реальном коде. Страуструп писал, что эффективнее сделать не получится, у Майерса в "Effective C++ in an Embedded Environment" написано, что but compared to C alternatives: faster and smaller than if/then/else or switch-based techniques... У меня виртуальные функции всего в паре мест и по одной, за скорость не скажу, но размер точно стал меньше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 14 сен 2017, 16:19 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 2471
Reflector писал(а):
У меня виртуальные функции всего в паре мест и по одной, за скорость не скажу, но размер точно стал меньше.

По идее вызов виртуальной функции разворачивается в вызов по указателю из таблицы. Это, насколько я понимаю влияет на скорость выполнения только в одном месте - предвыборка инструкций (плюс выборка по индексу из VMT). Любой if или switch даст ровно такую же задержку, плюс время на вычисление условия. В целом должно быть так на так, как по мне. За счет более компактного кода можно получить и выиграш в скорости.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 14 сен 2017, 16:31 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
evsi как бы да, но в одном случае все расположено во флэш, а во втором требуется дополнительный расход RAM
и вы говорите про задачу где в одной программе есть несколько экземпляров одного интерфейса с разной реализацией
только тогда в альтернативе сищным if/switch будет виртуальная таблица

я же спрашивал для ситуации когда скажем в шаблон1 передается другой шаблон с раскрытием шаблон2
внутри шаблон1 используетчя ряд методов от шаблона2
шаблон2 может иметь разные реализации - шаблон2_1, шаблон2_2 и тд
поэтому чтобы обеспечить преемственность между разными реализациями шаблон2 и шаблон1 хотелось бы иметь некий механизм когда интерфейс между ними описывался бы ОДИН раз
сейчас этот интерфейс я вынужден описывать столько раз сколько реализаций шаблон2 я имею
и более того - совместимость во время компиляции не проверяется если нет раскрытия одновременно шаблона 1 и шаблона2

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 14 сен 2017, 22:42 
Только пришел

Зарегистрирован: 03 сен 2017, 22:47
Сообщения: 26
мне кажется вы накручиваете сами себя, или я не понял, что вы имеете в виду:
дело в том, что если вы передаёте "шаблон2" в качестве шаблонного параметра в "шаблон1" и используете из "шаблона1" методы "шаблона2", то вам так и так придётся реализовывать в "шаблон2" все необходимые методы для "шаблон1". Наличие необходимых методов в "шаблон2" и будет своеобразным интерфейсом (если не ошибаюсь это называется "стратегией" в шаблонном метапрограммировании, см. Александреску). Если чего-то не допишите, то либо компилятор выдаст ошибку, либо это ему не нужно.
Код:
//typedef TDevLCD_HD44780_1602 < TDrvLCD_HD44780_4bit > DevLCD;
typedef TDevLCD_HD44780_1602 < TDrvLCD_HD44780_8bit > DevLCD;

здесь как раз передаётся в шаблонный класс "драйвер" для работы с LCD-индикатором. Классы драйверов TDrvLCD_HD44780_4bit и TDrvLCD_HD44780_8bit имеют все необходимые методы для работы класса TDevLCD_HD44780_1602.
Если же драйвер "не подходит" к шаблонному классу, то на уровне компилятора будет ошибка, т.к. драйвер имеет строку (количество контроллеров HD44780 в индикаторе)
Код:
enum { HD44780 = 1 };
, а шаблонный класс статическую проверку
Код:
STATIC_ASSERT((Driver::HD44780 == 1), "Type of the driver not correct");

т.е. следующая строка выдаст ошибку компиляции, т.к. индикатор имеет 2 контроллера HD44780, а драйвер умеет работать только с одним контроллером HD44780
Код:
typedef TDevLCD_HD44780_4004 < TDrvLCD_HD44780_4bit > DevLCD;
правильно будет так
Код:
typedef TDevLCD_HD44780_4004 < TDrvLCD_HD44780x2_4bit > DevLCD;


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 14 сен 2017, 23:01 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
technik-1017 Я не о таком простом спрашиваю

Что не устраивает:
- при определении кода методов вне класса хотелось бы не описывать прототипы методов в теле каждого шаблон2
- хотелось бы иметь заранее описанный "интерфейс" шаблон2 и чтобы соответствие ему проверялось при компиляции ДО раскрытия

И первое и второе упростило бы написание и отладку
Что то типа виртуальных методов не класса, а шаблона

Похоже нет такого


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 15 сен 2017, 07:57 
Только пришел

Зарегистрирован: 03 сен 2017, 22:47
Сообщения: 26
у меня описание методов находится в заголовочных файлах (*.h) из небольшого объёма кода (файл *.cpp отсутствует). Поэтому проблемы интерфейса у меня пока не существует.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 15 сен 2017, 10:44 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
Рад за вас
Но распределение кода по файлам не влияет на ситуацию
Видимо не смог вам обьяснить суть


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 15 сен 2017, 14:39 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 2471
axill писал(а):
evsi как бы да, но в одном случае все расположено во флэш, а во втором требуется дополнительный расход RAM

VMT вполне может лежать во флеше, это константные данные, которые не меняются во всемя выполнения.

axill писал(а):
и вы говорите про задачу где в одной программе есть несколько экземпляров одного интерфейса с разной реализацией только тогда в альтернативе сищным if/switch будет виртуальная таблица

Естественно. Иначе нет смысла городить виртуальные методы вообще.

axill писал(а):
в описанной проблеме виртуальный функции нв исполняемом коде не несут никаких плюсов, одни минусы
получается решение проблемы компиляции через runtime - совсем плохо

Так тут и свичей/ифов тоже как бы нет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 15 сен 2017, 21:26 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
Понял я, что много хочу)
Чтож, буду дальше копипастить и проверять код при раскрытии


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 17 сен 2017, 01:23 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
поясните по синтаксису
есть необходимость внутри класса дать набор статических данных
чтобы потом их не объявлять по одному полю. хочу объединить в структуру:
Код:
template <int a>
class A {
  struct D {
    int i;
    int j;
  } data;
};


далее почему то в IAR проходит так:
Код:
template <int a>
A<a>::D A<a>::data;


а gcc требует так:
Код:
template <int a>
typename A<a>::D A<a>::data;


что этого правильно?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 23 сен 2017, 14:12 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
вопрос на логику-железо

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

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

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

какие могут быть еще варианты решения?

сейчас удалось снизить вероятность такого события перенеся чтение железного счетчика в начало процедуры обработчика и делаю сброс железного иаймера (от чего хотелось бы отказаться)

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 24 сен 2017, 16:19 
Старожил
Аватара пользователя

Зарегистрирован: 05 фев 2010, 16:57
Сообщения: 2189
Откуда: Нальчик
>> пишу универсальный код для драйвера с манчестерской кодировкой

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


>> хотелось бы обойтись без изменения режима работы таймера в процессе приема-передачи чтобы можно было обрабатывать несколько каналов на одном таймере

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


>> но возникла проблема
>> от момента входа в прерывание по RX до момента проверки на середину интервала железный счетчик вполне вероятно может переполниться
>> и тогда логика проверки рушится, возникает ошибка на величину максимального счета

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


>> какие могут быть еще варианты решения?

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

В твоем случае можно применить следующим образом... Один обработчик - по изменению уровня на линии - записывает измеренные данные в кольцевой буфер. Другой обработчик периодически смотрит, есть ли данные и разгребает завалы в буфере... При этом не нужно иметь большой буфер, декодирование происходит быстро, достаточно наверное буфера на прием пару байтов (это 16 бит, в манчестере это может быть до 32-х перепадов) соответственно это кольцевой буфер на 32 байта.
Ну это так, мало ли пригодится инфа в будущем.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 24 сен 2017, 16:37 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
Сергей, спасибо за ответ

Ну да) но все это хобби, делается в удовольствие
Мне не хватало знания современного си++ с шаблонами
Сейчас уже есть рабочий прототип именно то, что хотел

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

Идея с буфером интересная. Но что она может дать в плюс?
И что хранить в буфере?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 24 сен 2017, 16:51 
Старожил
Аватара пользователя

Зарегистрирован: 05 фев 2010, 16:57
Сообщения: 2189
Откуда: Нальчик
axill писал(а):
Идея с буфером интересная. Но что она может дать в плюс?
Это я так... поделился вариантом реализации... для разнообразия...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 24 сен 2017, 23:09 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
а что в буфер сохранять? значение пина + отсчет времени?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 25 сен 2017, 00:55 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
проверил алгорит при разнице частоты приемника и передатчика в 2 и 4 раза
2 раза работает по прежнему за счет синхронизации, 4 не работает
и это на 8-ми битном счетчике

update: увеличил ожидание после получения pinchange и заработала синхронизация при разнице даже в 8 раза
приемник настроен на частоту в 8 раз больше передатчика

в обратную сторону на 8 битном таймере думаю будет 2-4 раза предел синхронизации

нормально?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 25 сен 2017, 02:34 
Старожил

Зарегистрирован: 10 июн 2011, 23:01
Сообщения: 3412
Цитата:
от момента входа в прерывание по RX до момента проверки на середину интервала железный счетчик вполне вероятно может переполниться

для чего считать переполнения? счётчик успевает переполниться больше одного раза за время одного бита?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 25 сен 2017, 04:15 
Старожил

Зарегистрирован: 20 мар 2013, 11:27
Сообщения: 5354
_pv писал(а):
для чего считать переполнения? счётчик успевает переполниться больше одного раза за время одного бита?


Во первых, если частота приемника и передатчика один в один совпадают то переполнение (а в данном случае корректнее говорить - обновление) счетчика происходит как раз где то после прерыванич по пину. Во вторых если частота отличается и/или если мы счетчик не сбрасываем и он считает асинхронно к получаемым данным то обновление (переполнение) происходит в случайный момент времени

Проблема в том, что переполнение это +256 (для 8 битного счетчика) к софтверному счетчику который используется для распознования середины бита и ошибка на 256 дает рассинхронизацию

Мой алгоритм сейчас работает четко, но выжать я из него на чтение могу максимум 500 бит/сек. На скорости 1000 бит/сек чтение ломается. Пока не понял с чем это связано. Скорее всего с ростом ошибки, код pin change исполняется с той же скоростью, а счетчик таймера считает быстрее


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Унифицированная кросс-платформенная библиотека Си
СообщениеДобавлено: 25 сен 2017, 11:34 
Старожил

Зарегистрирован: 10 июн 2011, 23:01
Сообщения: 3412
я не про это спрашивал
частота таймера по которому манчестер декодируется больше чем битовая скорость * 512?
если нет, для чего тогда нужен софтверный таймер считающий переполнения таймера?
неатомарность которого вам и мешает?
а если да, то зачем она такая большая?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 407 ]  На страницу Пред.  1 ... 9, 10, 11, 12, 13, 14, 15 ... 17  След.


Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB