Форум РадиоКот

Муркиз писал(а): Ср сен 23, 2026 07:55:34А зачем все это ?

Это всё от отсутствия технического образования и присутствия избытка свободного времени.

В одном мед.аппарате (современном) стоит такая карта microSD 32ггб
Подобная такой как по ссылке?
https://macrogroup.ru/materials/news/sd-i-microsd-s-kastomizatsiey-proshivki-fixed-bom-i-postavkami-na-protyazhenii-zhiznennogo-tsikla-ot/
Ещё вроде как бывают SD-карты с Java внутри:
https ...

Zapolyarny писал(а): Чт сен 24, 2026 14:56:23Для чётного числа выводов два значения ошибки, притом одно отрицательное.

Ошибка - величина беззнаковая.

Shuspano писал(а): Вт сен 22, 2026 00:42:17у DIP40 - 0,8 мм ошибки набирается.

Какой-о у вас калькулятор... не той системы. Выкиньте его.
0.4 мм всего.

Если начать с 1-й лапки и двигаться плавно и поступательно, то к 40-й уже можно дорасти до гуру паяния.
Общеизвестно: "Электротехника - наука о контактах". И чем их меньше - тем надёжнее работа.

Даник писал(а): Сб сен 19, 2026 19:45:54микросхема не может удержаться в цанговой панельки и выпрыгивает из нее и единственный метод

"Единственный метод" == паяльник. Это если реально хочется запустить, а не бороться с проблемами (вами же созданными), вызванными плохими контактами.

Враньё. По IDLE принимает без ошибок. IDLE взводится не через 1, и даже не через 2 бита, поэтому STM32 прекрасно принимает фреймы даже от старых восьмибиток, которые выдают байты в линию через не одинаковые интервалы. Ну вобщем - как всегда... Сначала самоуверенно обвиняете всех, что они не знают ...

linux_rulezz писал(а): Пн сен 14, 2026 22:27:33Кстати, я очень редко на мастере CRC проверяю, т.к. это вообще никакого смысла не имеет

Да уж... Этой фразой всё сказано о стиле кодопейсания адептов линуха и CAN-а. Ни добавить ни прибавить нечего.

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

На AVR можно просто в какой то точке обработчика прерывания, разрешить реагировать на другие прерываний.
Дальнейший (долгий) код будет выполнен до возврата в основной поток, при этом другие прерывания будут обрабатываться, все довольны. Это не то. Во-первых: этот долгий код тогда будет выполняться ...

Что угодно. Если вы прочитаете их по отдельности, двумя запросами, то между запросами данные там могли поменяться, получите чепуху, половинки двух разных значений. При считывании одним запросом, целостность данных гарантируется. Что за "запросы"? Вы имеете в виду запросы через протокол обмена ...

Но это имеет смысл, только при точном таймере Почему? При чём тут таймер?

Это имеет смысл при наличии широковещательных кадров. Когда новый кадр может начаться пока ещё не успел обработаться старый. Если у вас нет потока широковещательных кадров, то не нужно.


Есть 32-битное значение, два ...

А зачем для этого "вытесняющая многозадачность"?
За тем, что основной поток может быть занят другой задачей, и обработка принятого кадра будет ждать её завершения. Это может быть долго, до 3,5T можно не успеть. Тогда читаем моё сообщение немного дальше:

Для отделения уровня приёма от уровня ...

Это слишком много, что бы считать внутри прерывания, а вытесняющей многозадачности у меня там нет. А зачем для этого "вытесняющая многозадачность"? Для отделения уровня приёма от уровня обработки, достаточно иметь прерывание + фоновый процесс. Или прерывания двух разных уровней приоритета ...

После обнаружения тишины в линии в 3.5Т, начинается обработка кадра. По Стандарту, кадр с ошибкой приёма нужно отбросить.
Я ведь не зря говорил про таймаут на ожидание ответа от ведомого. Ведомому нужно время на обработку принятого кадра. Тоже смешение мух с котлетами. Всё в одной куче: и ...

Если соблюдать стандарт точно, то кадры с 1,5T < пауза < 3,5T должны быть признаны битыми и отброшены. Пауза "не менее 3,5T" означает конец кадра.
Но не сказано, сколько у меня в запасе, после 3,5T, если я не могу отследить точно 3,5. Нисколько. Не смогли отследить == не смогли полноценно ...

Судя по сентенциям, вы только сейчас узнали о Модбас от ТС на этом форуме. И практики его применения у вас точно нет.
Широковещательные команды встречаются весьма редко. Судя по сентенциям, вы не сумели реализовать широковещательную передачу по Modbus-RTU. Потому и доказываете, что оно не нужно ...

При том, что после отправки ведущим фрейма он ждёт ответ или отрабатывает паузу, а не шлёт тупо следующий фрейм через 3.5 символа. Именно, что тупо шлёт. Широковещательные кадры. Опциональная задержка может быть добавлена на время обработки кадров ведомыми. Но она именно - опциональная . Если ...

В Modbus/RTU строго сначала идёт запрос от ведущего, а потом ответ от ведомого. Ведущий ждёт ответ в течении времени, указываемого для ведомого. Максимальное время ответа ведомого указывается многими производителями. Если за указанное время ответ от ведомого не пришёл, то только тогда ведущий ...

Atmel AVR еще и 9N1 могут гонять. Использование всяких экзотических режимов UART неизбежно ведёт к проблемам у конечного пользователя. Что, в свою очередь, неизбежно ведёт к отправке такого проблемного девайса в мусорку. :dont_know:
Надо везде стараться пользоваться 8N1.
Я где-то слышал, что даже ...