- Silabs C8051F064: использование старших портов (P5-P7) как GPIO. PiTeK(405 знак., 06.08.2020 11:33 - 11:38, MCU, полностью)MBedder
- Приведи пожалуйста ссылку на C стандарт подтверждающую слова: "про
невыравненный доступ сказано -- поведение неопределено"? Уточню:
речь идет о void* указателе. - RxTx(24.07.2020 14:49 - 26.07.2020 13:02, MCU, полностью)fk0
- Сонму копьеметателей: Пощупал конкретнее: В MDK ARM v4 пофиг всякие
#pragma pack(1), __align(4), __packed и их полное отсутствие.
Похоже компилятор, имея в командной строке " --cpu Cortex-M3",
всегда генерит __aeabi_memcpy() в соответствии со здравым смыслом,
имея указатели (void *)... Тут другое интересно - третий параметр в
"шибко грамотном" MDK ARM v5. Что там вещает стандарт?
Руководствуясь тем же здравым смыcлом, там должно быть количество
БАЙТ и компилятор должен Гyдвин(82 знак., 27.07.2020 12:30)
- Где я говорил про void*? Речь про указатель на int. fk0(281 знак., 24.07.2020 15:23)
- Ты написал в прошлом сообщении (цитирую твои слова): "а с некой
абстрактной моделью вычислительной машины заданной СТАНДАРТОМ
ЯЗЫКА". Ты выражение "стандарт языка" понимаешь как-то не так как
все люди? Какие еще "оптимизаторы", какие "кодогенераторы" в
стандарте языка C? Вот я тебя и прошу подтвердить твою же фразу.
Мне еще в 2-3х сообщениях требовать с тебя цитату из стандарта? Или
не будем валять дурака, и ты уже все понял, что по стандарту языка
C прав именно RxTx(558 знак., 24.07.2020 15:53)
- ISO/IEC 9899:201x, разделе 6.3.2.3 Pointers, параграф 7: fk0(851 знак., 24.07.2020 17:18)
- Баг в GCC, а не в Clang и вообще совершенно про противоположное,
мол нет оптимизации. Остального не понял -- научись выражать мысли
на понятном языке. Гудвин не прав, т.к. при использовании
стандартных же любых конструкций языка (без упакованных структур)
"баг" воспроизвести невозможно. А то, что он воспроизводится при
использовании упакованных структур совершенно естесственно, и
кстати в баге gcc есть на это комментарий (см. ссылку) -- вот так
проблему можно обойти. Какие fk0(1225 знак., 24.07.2020 16:56, ссылка)
- Давай укоротим проблему, насколько это возможно, т.к. нет времени и
я устал. С GCC и багом вряд ли я был прав, несмотря на то что
внутри armcc.exe v4 v5 масса строк "GCC" и отсутствует "CLANG",
armcc это отдельный компилятор. В v6 он называется armclang. Со
стандартом вышло смешно. Формально ты привел действительно ровно
то, что я спросил. И бессмысленно утверждать что разумеется вопрос
был о прямых виновниках разговора: о функции memcpy (она оговорена
в стандарте) и о 6.2 RxTx(1116 знак., 24.07.2020 22:30)
- На счёт memcpy: с одной стороны да, ты можешь подсунуть
невыравненный адрес и всё должно работать. И действительно, если ты
руками там как-то аллоцировал память, посчитал адрес, он оказался
невыравненный -- всё будет работать. Будет вызвана "неоптимальная"
версия memcpy. А в случае с гудвиновским багом компилятор был
обманут: ему сказали, что будеут копировать вот такой-то тип, а
этот тип никак не может лежать на невыравненном адресе,
следовательно, компилятор знает, если fk0(1323 знак., 25.07.2020 02:24, ссылка)
- Извини, но ты загнался. LightElf(632 знак., 26.07.2020 14:26)
- Чего ты привязался к memcpy. Я рассказал выше как получается баг. Вместо memcpy может быть любое обращение по указателю/ссылке. К слову и gcc и clang даже варнинг имеют специальный:
-Waddress-of-packed-member. Его невозможно выполнить в любом коде.
А ты хочешь сказать, мол memcpy на 32-битной машине должен
копировать по байтику вместо 4-х за раз, а на 64-битной по байтику
вместо 8, а на машинах где есть векторные инструкции... вообще
страшно. И да, оптимизатор fk0(728 знак., 26.07.2020 15:24)
- Я привязался к memcpy ровно потому, что ее параметры прямо декларируются как void*. void* означает, что указатель может быть любым. И компилятор обязан этот факт учитывать. Тяготы и лишения
компиляторописателей меня интересуют постольку-поскольку. - LightElf(26.07.2020 15:35)
- И он работает с любым типом корректно. Пока ему голову не
заморочили взятием указателя на выровненный тип в упакованной
структуре. В каком-то смысле, это недоработка компилятора, но
стандарт не нарушается. - Nikolay_Po(26.07.2020 15:39)
- Мы говорим о нестандартном (но весьма распространенном) расширении.
Причем тут ссылки стандарт? - LightElf(26.07.2020 15:42)
- ОК. С точки зрения работы расширения проблема налицо. Но fk0
принялся ругать говнокод и защищать компилятор. За что ему большое
спасибо! Всё подробно разжевал, ссылки привёл. Тема была - супер!!! - Nikolay_Po(26.07.2020 15:47)
- Тогда на что ссылаться? По стандарту всё ок. А по мнению LightElf
не ок? Нужен какой-то формальный документ, который описывает
поведение компилятора. - fk0(26.07.2020 15:44)
- На документацию конкретного компилятора - LightElf(26.07.2020 15:48)
- Где в документации описывается что должно происходить в случаях: fk0(232 знак., 26.07.2020 15:59)
- А знаешь почему не описывается? Сям (компилеру и стандарту) просто
чхать, какая там структура. Осознай это. Упакованная, не
упакованная - именно сишечке по барабану. Осознай: требования по
default data alignment (вообще по типам, не только выравнивание, но
и размер) оно существует только для конкретной CPU платформы, не у
компилятора. И padding (выравнивание) структур делает не компилятор
следующий стандарту C, а бэкенд, именно он отвечает за платформу,
ее выравнивание, RxTx(223 знак., 26.07.2020 17:22)
- Логично, что implementation defined behaviour должен быть описан в
документации конкретного implementation. Разве не так? - LightElf(26.07.2020 17:21)
- Я выше сказал, что проблема возникает не в memcpy, а в выражении
&IH.conag. Что там после -- уже не важно. Результат данного
выражения не валиден. Он содержит корректное числовое значение, но
некорректный тип, из-за чего оптимизатор принимает не верное
решение. - fk0(26.07.2020 15:39)
- Опыт жизни и общефилософское наблюдение показывают: дискуссия
(разговор, беседа) только тогда здрава, заканчивается познавательно
и позитивно, когда ее участники имеют одну и ту же цель и
заинтересованы в одном и том же результате. Моя цель в данном
случае - выяснить четкую практическую истину. Где что сломалось,
почему, кто виноват и что делать. Твоя цель явно в том чтобы либо
образовать меня/нас, либо просто изложить (насколько ты понимаешь и
способен) свои представления о RxTx(484 знак., 25.07.2020 10:11)
- Нет, это не баг. Потому, что это UB. Потому, что изначально взяли
указатель на int и присвоили ему что-то, что не является указателем
на int (об чём есть строчка в стандарте). Далее уже не важно. Более
того, ещё раз повторю, в рамках СТАНДАРТНОГО C/C++, возникновение
такого "не бага" -- в принципе невозможно. Оно появляется из-за
"бажной" реализации упакованных структур. Ты прицепился к memcpy и
считаешь, что мол баг. Но класс проблем же НАМНОГО ШИРЕ, чем только
memcpy. fk0(858 знак., 25.07.2020 16:40)
- Вчера я прочитал что ты написал и планировал самостоятельно
поэкспериментировать. Слова это одно, а когда начинаешь разбираться
сам легко может быть другое. Не вышло, нет времени, поэтому все что
я здесь пишу основано на исходных данных этой темы. Кстати беглое
изучение документации на тему memcpy показывает что существует
большое пространство для маневра не только с тривиальными ключами
компилятора, прагмами и атрибутами но и что важно, с подключаемыми
либами/выбором obj RxTx(5329 знак., 26.07.2020 12:46)
- UB значит, что возможное дальнейшее развитие сценария писателями
компиляторов не рассматривается. Такого мол изначально не может
быть, программист не допустит. Поэтому если при анализе ситуации
возникает UB, то нет смысл думать что если то, или если это -- оно
в принципе невозможно в корректной программе. Выражение
"&IH.conag" само по себе UB. Поэтому заявить, что мол в
компиляторе баг и притягивать дальнейшие преобразования типа и
вызов memcpy не нужно: в корректной fk0(4348 знак., 26.07.2020 13:47)
- Я считаю мы с тобой обменялись мнениями. Дальше пойдет уже
непринципиальное, и смысла обсуждать мелочи не вижу. Ты видимо
по-инерции, все еще не осознав или невнимательно, невдумчиво
прочитав мой пост, прибегнул к обсуждению стандарта C. Напрасно,
так как твои посты я перечитывал несколько раз, обдумывал, и даже
заметил что самое первое что ты написал в эту тему - это именно то,
что memcpy должна работать без всяких проблем! А потом у тебя
что-то сломалось :) Так вот, RxTx(758 знак., 26.07.2020 16:46)
- Опять за рыбу деньги. Расширение в виде #pragma pack в GCC есть?
Есть. memcpy в GCC есть? Есть. Где-нибудь в доке GCC написано, что
к элементам пакованной структуры применять memcpy нельзя? Нигде.
Бага GCC очевидна. Чего спорить-то? Хоть бы warning выдавал, как
тот же IAR делает (Used the address of unaligned structure member). - LightElf(26.07.2020 15:08)
- Именно в gcc бага нет, как и в clang последних версий. Они
применяют атрибут меняющий alignof на 1 автоматически. И там
получаются инструкции ldrb при обращении и медленная версия memcpy.
Но ты _доказать_ что это баг в keil или ранних версиях clang -- не
сможешь. Баг в чём? Я выше привёл доказательство, что это UB, a
следовательно не баг. - fk0(26.07.2020 15:27)
- Если компилятор рассматривает void* как int*, то это его
обязанность убедиться в допустимости такой замены в каждом
конкретном вызове. - LightElf(26.07.2020 15:39)
- Так для типа int -- всё корректно. Некорректно для того типа, что
лежит в упакованной структуре. Это не int, потому, что int не может
лежать на невыравненном адресе. Это другой тип. Но в структуре
записано что int, что и приводит к краху. - fk0(26.07.2020 15:43)
- Компилятор знает, что в общем случае void* нельзя приводить к int*.
Компилятор либо знает, что тип лежит в упакованной структуре и
должен генерировать правильный код. Либо компилятор не знает, где
лежит данный конкретный int и тогда должен исходить из худшего (раз
уж он поддерживает такие конструкции). А вот это "здесь читаем,
здесь не читаем, а здесь - рыбу заворачивали" есть косяк и бага. - LightElf(26.07.2020 16:22)
- SciFi же дал ссылку на кейловскую документацию: Taking the address of a field in a #pragma packed struct does
not yield a __packed pointer. Так что это не баг, а фичер: в структуре лежит __packed int, а
берёшь адрес, и брюки превращаются... превращаются брюки...
Идиотизм конечно, но bug report слать действительно бесполезно. - йцyкeн(26.07.2020 15:58, ссылка)
- Спасибо. Убедительно. - Nikolay_Po(26.07.2020 13:58)
- Вы заблудились в сферических абстрацкиях в ваккуме (возможно вместе
с компиляторописателями). В данном случае мы работаем на процессоре
M3 который УМЕЕТ делать unaligned access. Поэтому если компилятор
знает что генерит код для M3 то никакого undefined behavior при
невыровненном указателе на ЭТОЙ архитектуре нет - корректное
исполнение обеспечит hardware. - 3m(26.07.2020 11:42)
- К сожалению, я не пользуюсь Кейлом, поэтому про Кейл ничего не
скажу, но эксперименты с ИАРом показали следующее: во-первых, в
ИАРе воспроизвести эту ошибку не удалось. ИАР заменяет memcpy на
__aeabi_memcpy4, если адреса выронены, и на __aeabi_memcpy, если не
выровнены. Если для невыровненных адресов написать __aeabi_memcpy4
ручками, хардфолт происходит, и здесь нет никакой мистики:
__aeabi_memcpy4 использует инструкции LDM и STM, для которых CM3
как раз не умеет делать йцyкeн(109 знак., 26.07.2020 14:40)
- Умеет делать unaligned access??? Есло бы он умел, то изначально
исключения (в чём собственно баг) при попытке этого самого access
не возникал бы! Чтоб оно так работало надо сбросить битик
UNALIGN_TRP в CCR, а компилятор ни сном, ни духом про SFR регистры
и их значения. Это программист их правильно поставить должен
вначале. Ну там ещё есть такая мелочь, что невыравненный доступ
доступен не для всех инструкций... что тянет за собой отдельную
реализацию всех библиотек fk0(267 знак., 26.07.2020 13:14, картинка)
- undefined behavior -- это йуридическое понятие, а не техническое,
есличо - SciFi(26.07.2020 11:55)
- Отдыхать вам, батенька, надо... Компилятор должен делать то, что
ему явно указали. Все. Конец пустому пиздежу... - Гyдвин(25.07.2020 08:43)
- Я привожу в пример C++ потому, что зная как он работает начинает
приоткрываться принцип работы и C компилятора тоже (благо внутри
там у GCC и Clang для обоих языков один "движок"). В языке C нет
некоторых вещей (шаблонов, ADL), что не даёт понять, например,
почему тип важен и как тип может управлять компиляцией. Для C
программиста может быть не очевидно, а C++ программист запросто
может написать свой самодельный memcpy ровно с такими же "багами"
пользуясь только средствами fk0(196 знак., 25.07.2020 01:57, ссылка)
- Не подскажет ли кто по USB ? Устройство получило адрес 2. Но иногда
на шине видны пакеты OUT на адрес 3..!!! (точка 2) Всегда
одинаковые, 31 байт: U,S,B,C,0xb0,0x3b,0x99,0x87. Все остальные 0,
кроме 15-го (==6). Что это ? - Юpий_CB(24.07.2020 18:01, MCU, полностью)
- Добрый день господа. Я в теме stm32 пока не опытен, олаживаю, но не
программист. Есть плата с STM32F105RBT6, прошили - не работает.
Поменяли микросхему, прошили - не работает, тут уже меня попросили
разобраться, посмотрел, питание есть, КЗ не назвонилось нигде, но
генератор не работает. Кварц и кондеры на его ножках тоже поменяли.
Куда смотреть? - DRcp(16.07.2020 12:25, MCU, полностью)
- Там кварц тактовая не так просто заводится... Хотя, если кварц не
генерит, то попробуй генератором пошевелить ногу - Звepoящep(22.07.2020 10:21)
- Спасибо всем ответимшим. Большое! Пока вопрос не продвинулся,
программист на удаленке, но готовится к командировке, вообще не
сунуть.) Разберемся. - DRcp(17.07.2020 11:16)
- Если плата самодельная, возьмите какую-нибудь evaluation board с
таким же МК и пусть сначала там программу запустит. - mrfirst(17.07.2020 06:50,
)
- +100500 - MBedder(17.07.2020 12:18)
- Залить готовую рабочую программу мигалки светодиодами. Если
работает, а прошивка програмиста-на-удаленке -- нет, то, скорее
всего, программисту-на-удалёнке надо потренироваться ещё. - BlackPrapor(16.07.2020 18:21)
- Номиналы конденсаторов точно как надо? Кварц рабочий из другой
платы можешь выпаять? - Evgeny_CD(16.07.2020 14:27)
- 1. Сброс. Как запрограммировано, что в схеме. 2. Про генератор уже
сказали. Почитай эти две главы в описании контроллера, это не
сложно. - Evgeny_CD(16.07.2020 14:24)
- Что прошили и что не работает? Если сам не программист, зови
программиста. - VLLV(16.07.2020 12:36)
- Microchip тормозит с поставками General(15.07.2020 18:58, MCU, ссылка, полностью)
- Вопрос по часам реального времени. michas(111 знак., 07.06.2020 06:14, MCU, полностью)
- bcd всего лишь можно показывать без дополнительных телодвижений, а
вот операции с ним производить неудобно, имхо. Бинарное -
универсально. - Xитpый Kитaeц(11.06.2020 08:52)
- Они были в 70-80-х годах, когда не было процессоров с аппаратным
делением/умножением и программное было медленное (ибо 8 бит всего).
Тогда распечатать из BCD сильно быстрей, чем программно вычислять
секунды, минуты... Сейчас совершенно без разницы. - fk0(09.06.2020 10:43)
- Медведева на вас нету, если опять порулить дорвется, никакие
таймеры не спасут! - Visitor(07.06.2020 09:04)
- только то, что ты избавлен от постоянных вычислений. Когда надо
визуально предоставлять наружу время и дату. Вот как у меня в моем
пульте. - Лaгyнoв(07.06.2020 09:00)
- Если работа с часами простая (установил и тикают), то часы с
календарем проще - прочел и вывел. Если работа с часами
предполагает сравнение, восстановление и подстройку времени,
переход зима-лето, использование меток времени в логах/архивах, то
секундный счетчик удобнее - все равно все делаешь сам, и не нужно
постоянно конвертировать. - VLLV(07.06.2020 06:24)
- [Архивы]. Сегодня пролистывал сообщения Дениса Ягова (у него сегодня ДР, но
его последний пост был 10 лет назад), и наткнулся на обсуждение
перспектив USB в STM8. Посмотрел сайт STM - за 10 лет так и не
случилось. - Evgeny_CD(14.07.2020 17:34, MCU, ссылка)
- LTC3350 - поможете понять как на выходе будет5В при входном 20В? - POV_(13.07.2020 15:13, , MCU, полностью)
- Подумалось. А в FRAM-памяти ведь тоже разрушающее чтение? Или нет?
А если да, то она же регенерируется значит? А если питание отключат
в момент чтения? - fk0(10.07.2020 12:37, MCU, полностью)
- ща лень искать, но уже обсуждение было - давал инфу. в общем бывает
как минимум два типа топологии - с прибитыми рельсами питания и с
переключающимися. во втором случае опасен только износ. текущее
решение у TI заявляет о 150 пс времени регенерации. даже при
топологии первого типа нереально разрядить байпассную емкость за
это время. - Vit(10.07.2020 15:40)
- У TI есть серия MSP430FRx - там описано, что предпринято для
предотвращения подобной ситуации. Сам по памяти уже не опишу. - Dingo(10.07.2020 13:17)
- Ёмкости конденсатора по питанию должно хватить, чтобы записать
обратно, дальнейшие попытки записи/чтения должны прекратиться, так
как сработает супервизор процессора по питанию. У нас по факту с
FRAM были изредка проблемы, что терялась целостность,
восстанавливали данные из других источников, но редко с
микросхемами FRAM была проблема: после сбоя она ломалась, пишешь
одно - обратно читаешь другое. - FRAM(10.07.2020 13:08, )
- Как страшно жить! - Toчкa oпopы(10.07.2020 12:45)
- MSP430. Что такое _ZEBU_ ? VLLV(74 знак., 07.07.2020 22:48, MCU, полностью)
- Погулял по сайту [Zilog] и испытал странные чувства. Evgeny_CD(565 знак., 08.07.2020 02:45, MCU)
- Какие российские микроконтроллеры гражданского применения
изготавливают полностью (кремний и упаковка) в России? Столкнулся с
тем что отечественные мк пекут на тайване, то есть чуть что - они
ничем не лучше импортных. - General(07.07.2020 10:36, MCU, полностью)
- Белорусов считаем за отечественное? Если да, то собственный MCS-51
:)))) у "Интеграла" есть, AVR клонировали-клонировали, а вот
выклонировали ли, надо смотреть. UPD: залез на сайт, гражданский
MCS помер :(, из гражданских остались одни бескорпусные извращения
с драйвером ЖКИ. - Chum_A(07.07.2020 16:42)
- Стоит присмотреться к контрам, имеющим собственное производство
кристаллов. На вскидку, это Ангстрем, Микрон, ЗНТЦ. У Ангстрема
известные мне гражданские МК старье. Микрон точно делает у себя
гражданские МК, но для смарткарт с криптографией. У ЗНТЦ что-то
есть, крайне самобытное, 16-ти битное. AlexG(364 знак., 07.07.2020 15:54)
- А что раздел "Parts" сайта говорит? Или именно полнота цикла
изготовления под вопросом? - Dingo(07.07.2020 12:38)
- Внезапно трабла накатила - флешка слетает... POV_(536 знак., 03.07.2020 20:54, , MCU, полностью)
- если к питанию нареканий уверенно нет, то я бы копал в сторону
тактового генератора, либо просто чип свое отработал ( и флеш через
паразитные дела внутри затирается, но все равно причина должна быть
в рассинхроне внутренних процессов записи - чтения.) При условии
конечно, что к коду вопросов нет.. - klown1(07.07.2020 10:10)
- Потенциально, в условиях ударов и вибрации в микросхемах возможен
пьезоэффект. Но мне что-то подсказывает, что это совсем не твой
случай, а у тебя скорей банально баги в коде. Кроме того "монитор
питания включен" -- включен программно, или вывод MONEN подключен
куда надо, чтоб монитор был включен с самого начала, всегда? Без
последнего запросто возможен глюкодром с самостиранием прошивки
(при неадекватном питании, в момент включения/выключеня,
исполняются какие попало fk0(108 знак., 04.07.2020 13:19, ссылка)
- Статичное лепездричество? От вибраццый. - mse homjak(04.07.2020 10:33)
- Постоянно на это нарывались, еще круче: есть 2 типа плат с
идентичной схемой проца, обе по 485 работают с хостом. В одном типе
прошивка не слетает, в другом частенько при включении. За пол года
разобраться не смогли, перешли на STM с ними проблем нет. - Visitor(04.07.2020 09:02)
- AN201 Writing to flash from firmware тщательно покурил? Или таки
прошивка вообще не твоя? RxTx(03.07.2020 21:04, ссылка)
- Реализовывал ли кто-нибудь OneWire Slave на базе SPI/UART? Чистый
bitbang'инг - это благородно, но если нужно имитировать несколько
шин, таймеров не напасешься, да и геморно. lloyd(125 знак., 24.06.2020 21:19, MCU, полностью)
- Думаю можно сделать по аналогии с описанием по ссылке (). Нужен PIC
с HLT таймером, который будет запускаться от сигала шины 1-wire
(1->0), и перекидывать лог ячейку (триггер, CLC). Т.е. на
выходе CLC получим клок для SPI. SDI тоже подключаем к 1-wire,
таким образом логика будет формировать SCL и данные сдвигаются в
регистр SPI. На чтение аналогично. Должно работать полностью
автоматически. Илья(85 знак., 26.06.2020 18:17, ссылка)
- Не понял, что с UART, что с таймером, у тебя по одному (двум, не
важно) прерываниям на бит. Одинаково всё. А таймеров обычно больше
чем UART'ов. Тем более, что таймер-то на самом деле, аппаратный,
нужен ровно один. А поверх него можно построить очередь программных
таймеров. - fk0(26.06.2020 10:32)
- Дык вроде многие под это дело УАРТ и затачивают , эмулируя слоты
1wire. - Balda(24.06.2020 21:53)
- прошу прощения! а можно ссыль на спецификацию "OneWire" ?? чисто
для самообразования - Aleksey_75(24.06.2020 21:24)
- Есть мысль перейти на RTOS для снижения временных затрат на
реализацию программной части, отладку и профилировку. Важна
поддержка со стороны хоста (PC,IDE) чтобы видеть времянки, логи,
состояние. Какие используете RTOS? Есть ли опыт применения ThreadX?
Какие RTOS можно выделить в качестве ключевых? RxTx(118 знак., 18.06.2020 10:35 - 11:07, MCU, полностью)
- ChibiOS посмотрите. Мелкая и удобная. antm(202 знак., 18.06.2020 20:39, ссылка)
- я FreeRTOS использую, ключевое приемущество - чето не нравится -
взял и переписал или доделал. на заре пользовал ThreadX. когда
памяти больше чем нужно и процессор быстрее чем быстро - то
экономия в разработке есть - велосипед писать не нужно. - klen(18.06.2020 19:32)
- Используем ThreadX в составе платформы Renesas Synergy, для отладки
есть TraceX, dxWAk(240 знак., 18.06.2020 13:55, картинка)
- Да, интересно, а насколько легковесны такие вызовы (в тактах,
например): fk0(294 знак., 18.06.2020 15:47)
- Допустим, я хочу сделать в threadX логгер. Он будет писать в
кольцевой буфер в памяти, из которого медленно и печально будет
выпечатываться в компорт. Задача достаточно классическая.
Логгировать одновременно могут все потоки. Как сделать кольцевой
буфер -- понятно. В принципе он может быть реализован на
lockless-алгоритмах, но.... Но поскольку компорт медленный, то
буфер может быть в переполненном состоянии (регулярно), то потоки
пытающиеся писать в лог должны ожидать fk0(1061 знак., 18.06.2020 14:15)
- Я бы использовал очередь, в потоке, который логирует ошибку dxWAk(447 знак., 18.06.2020 15:05, картинка)
- Собственно и вопрос-то в том как сделать самодельную очередь.
Потому, например, что готовая очередь может по каким-то причинам не
подходить. Например, работает только с сообщениями фиксированного
размера. Да, можно пересылать указатели на сообщения, но тогда на
каждое нужно выделять память. Кроме того, если очередь реализована,
условно, через системный вызов -- то работа с такой очередью
становится очень тяжёлой, по сравнению с другими примитивами
синхронизации, которые по fk0(213 знак., 18.06.2020 15:13)
- я не знаю за threadX но на тнео, фриртос итд так. abivan(788 знак., 18.06.2020 15:02)
- Бинарный семафор. Самый приоритетный из ожидающих проснется,
заберет семафор, проверит место. Если места достаточно - отправит
данные. Если недостаточно - снова встанет на этом же самом
семафоре. - LightElf(18.06.2020 15:01)
- "времянки, логи, состояние" можно смотреть через J-Scope - BlackMorda(18.06.2020 12:58)
- Ага. А с чего будет снижение затрат-то? На борьбу с ОСью не будет
не потрачено ничего, особенно на синхронизацию? В одном большом
проекте половина багов -- синхронизация (дедлоки, data race и т.п.)
А у тебя Valgrind (DRD, Hellgrind) не будет. Ты ж про
"синтетический порт" на ПК и слышать небось не хочешь. Мол одной
левой и так отладим. Основной функцией ОС является распрделение
ресурсов вычислительной системы. И она нужна, если ты это руками
сделать не можешь. И в fk0(2533 знак., 18.06.2020 11:00)
- С многопоточностью и синхронизацией у меня ок из-за того что до
этого на PC я делал несколько многопоточных и многопроцессных втч
network проектов, как либ, так и серваков или там GUI приблуд. Так
что этого я не боюсь. Про RTOS я подумываю не потому что мне нужна
вытесняющая многозадачность. Как раз нет, RxTx(1898 знак., 19.06.2020 00:17, ссылка, ссылка)
- Можно использовать ADA с рантаймом Ranvenscar - там есть задачи - OlegPowerC(18.06.2020 14:28)
- Если ресурсов немеряно, задача распределения ресурсов решается
проще. Приходишь на склад - а там столько, что не унести. А
достоинства RTOS никуда не делись - пишешь потоки и ффсе. Нужно
просто подобрать удобные потоки под RTOS, а все, требующее сложной
синхронизации сделать ручками. - VLLV(18.06.2020 13:16)
- Полагаю, что готовые библиотеки работы с Ethernet и выше
(WEB-сервер, SSL, что там еще понадобиться может) они требуют ОС.
Их использование, вместо изобретения велосипеда, это снижение
затрат. В остальном согласен, скорее всего ОС там не поможет. - AlexBi(18.06.2020 12:39)
- +1 - evgeniy1294(18.06.2020 11:07)
Пулковская обсерватория, 1835 год
В Петербурге разработали литий-ионные батареи для троллейбусов - Наука - ТАСС
Компания Эксперт Групп объявила о запуске серийного производства автоматическ...
Власти предлагают производить российские микросхемы только в России - CNews https://share....
Минпромторг РФ предложил изменить правила признания интегральных микросхем отеч...
Минпромторг предложил рассмотреть распространение применяемого в автопроме ути...
Китай через пять лет станет крупнейшим поставщиком чипов в мире с долей рынка в 30 %...
Новинки - прямоугольные промышленные разъемы Beisit
