Повисает компьютер при взаимодействии с МК

[RVL]

Всем доброго времени суток.
Возникла у меня проблема:
Есть ATmega16L. Подключена через MAX232CPE к COM-порту компьютера.
Компьютер управляет портами МК (через ключи подключена нагрузка) отправляя ком-порт соответствующие команды.
Собственно, все работает хорошо, но иногда, после очередной команды, повисает компьютер (наглухо - только вкл/выкл). Что может быть???
Кстати, МК подключен к компу через USB2COM переходник.

Спасибо!

[Alexey1969]

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

[asteroid7]

Программа на РС своя или терминал какой?

[ploop]

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

А если программа вешает всю систему, то... выкинь эту программу, и систему за одно.

[BCluster]

Не должно быть такого. Если писали сами - все операции работы с портом запускайте в отдельном треде, ploop истину глаголит)

[Пухич]

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

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

[ploop]

Ага. Меня вообще всегда это поражало - запускаешь какую-нибудь хрень в потоке и нормально. Хотя по факту оно хоть в основном, хоть в неосновном потоке висеть должно одинаково.

Это как так?
Что такое зависание? Программа работает, но не реагирует на команды пользователя. А не реагирует потому, что окно (или что там еще, не важно) прорисовывается и обрабатывает события (команды) пользователя в том же потоке, что и основная логика. Вот и весь секрет

Вот если разделить интерфейс и логику (подозреваю, что так и сделано в *nix системах), то это окно хоть убрать с глаз долой можно, пока программа не соизволит "отвиснуть"

[Пухич]

Что такое зависание? Программа работает, но не реагирует на команды пользователя. А не реагирует потому, что окно (или что там еще, не важно) прорисовывается и обрабатывает события (команды) пользователя в том же потоке, что и основная логика. Вот и весь секрет

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

[ploop]

Понятно, что эти гадкие процессы себе могли приоритету запросить немеряно, так ведь не повод......

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

А я вот одного не понимаю, для чего нужен потокам приоритет реального времени? Баловался с ним, такое ощущение, что даже прерывания у процессора отключаются, всё время отдаётся этому потоку, короче система становится парализована...

[Пухич]

Баловался с ним, такое ощущение, что даже прерывания у процессора отключаются, всё время отдаётся этому потоку, короче система становится парализована...

Ага! Вот у нас кто хулюганит!

[BCluster]

Эт драйверный режим. Винда в обычном режиме не дает точности выше 10 мс, если нужно больше - вперед в драйверный режим. Но там надо оч аккуратно)

[BCluster]

А насчет *nix. Там треды применяются намного реже чем в винде, считается что там проще запустить еще десяток-другой процессов, ибо хорошо развита система межпроцессного взаимодействия

[Пухич]

А насчет *nix. Там треды применяются намного реже чем в винде, считается что там проще запустить еще десяток-другой процессов, ибо хорошо развита система межпроцессного взаимодействия

Ну это еще как посмотреть. Учитывая, что потоки там очень просто устроены, проблем нет.

Насчет IPC - это да.
Получше виндовых кое в чем.

[BCluster]

да в виндах треды тож несложно устроены ) там просто есть свои проблемы)

[Пухич]

да в виндах треды тож несложно устроены ) там просто есть свои проблемы)

Меня лично напрягает число параметров и их жуткие названия. Даже дурацкий линукс и то проще в этом плане.

[ploop]

Это всё хорошо, но у автора, мне кажется, комп конкретно завис, раз не появляется

[Пухич]

Это всё хорошо, но у автора, мне кажется, комп конкретно завис, раз не появляется

Может быть.

Зато он с Атмегой общается, а мы - нет.

[RVL]

Нет. Автор не завис. Автор чинил свой комп (не связано с мегами).

Насчет зависаний вроде разобрался: действительно где-то ждало считывание из порта, когда там ничего не было.

Встала другая проблема:
заливаю периодически прошивку (процесс отладки).
После очередного "залива" мк стал плохо принимать с ком-порта.
Передаешь ему одну команду, а он делает по другой.
Долго пытался понять "почему?". Вставил другой мк с той же прошивкой - все работает. Хотя оба мк периодически меняю туда-сюда (до этого проблем не было).
Такое бывает с мегами?

[BCluster]

мож контакты?)

[RVL]

мож контакты?)

ПРимерно 50% команд воспринимается нормально.