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

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

Спасибо!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Может быть.

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

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

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

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

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

BCluster писал(а):мож контакты?)

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