Подскажите уважаемые. Начал изучать микроконтроллеры, и ассемблер, чтоб их програмировать. Встала задача повязать микроконтрллер на PC. Первое же знакомство с внутренним миром NT повергло меня в ступор, т.к. вместо прямого обращения к железу, приходитсо использовать малодокументированные, черти знает как работающие драйверы уровня ядра win32. Вот сижу и думаю, может проще в Linux реализовать общение с контроллером? Я понимаю, конечно, что задача не из легких, но все-таки, за что лучше братсо: за изучение NT или Linux?
В том то и дело, что в NT тоже сходу не въедешь. Одно дело - компилировать IszTutes - другое залезть в ring0. А Linux, по моему, создавалсо как раз для того, штаб человек мог чёнить свое добавить прям в сердце. Или я не прав?
tretiy3 Во-первых, дежавю, а это на васме не поощряется. Во-вторых, проще всего с контроллером общаться в досе, крайний случай - Win9x. Или, если есть средства, купить хороший контроллер с портом USB Тогда уж никаких проблем с NT не будет. Если всё-таки встала задача использовать именно COM/LPT и именно в NT, то для COM есть простая API (см. msdn), которая обычно исправно работает и не требует лезть в кишки ядра. А про LPT пора забыть, IMHO.
Что такое дежавю? И про LPT если можно поподробнее. Почему пора забыть? Товарищ, мне кажетсо, верно заметил, что скорость-то выше. + ни одного компьютера без LPT не видел , а вот без com - бывает.
tretiy3 1. Может не быть установлен (видел много ноутов без LPT). 2. Если есть, то только один и часто занят (принтером/сканером). 3. Из 3го кольца к нему бывает невозможно достучаться (мешает драйвер принтера или ещё что-то). 4. А забыть пора, т.к. это анахронизм полный. IceStudent У USB ещё выше. Кстати, не думаю, что скорость до такой степени критична. Иначе надо смотреть в сторону PCI, PCI express, ... AGP По RS232 тоже помойка плачет. Хотя я ещё не видел ни одного компа без com, а без LPT - есть.
зато ноутов полно без com, приходится usb2com использовать - некоторые железяки исключительно по нему управляются. на вопрос почему имеющийся usb порт не задействовать менеджер сказал "usb support in vxworks sucks"
Я не видел ПК без этих портов Зато ноуты без обоих портов за редким исключением. По теме - контроллёр с usb это хорошо, но если нет - тогда COM или LPT на выбор. Информации по связке МК с компом валом.
и не ноутов тоже, когда искал себе материнку под сокет 939 попадал на такие, на вскидку ABIT Fatality без com порта
Есть мнение, что легче не писать драйвер (зачем изобретать велосипед?), а юзать API. Читай msdn про "WaitCommEvent"
Я тут запостил недавно: http://www.wasm.ru/forum/viewtopic.php?id=15758 не изобилует каментами. Не думаю, что никто не знает ответ, но тем не менее. Чё толку от API, если при использовании ее функций происходит ошибка, и как с ней воевать - бог один ведает. При попытке посмотреть, чтож там внутри творитсо - ступор: Debugger ныряет в kernell, а там: мама дорогая. Речь не идет о изобретении велосипеда. Хочетсо ясности какой-то. Знаете как женщины водят автомобиль, ничего не соображая, что ж там под капотом творитсо? Вот и вы мне примерно тоже предлагаете: "жми сюда - и поедешь". А если "не поеду"? - Ну извини. Ничем помочь не можем Код-то закрыт. Разбиратсо приходится не по описанию "твортса" сей софтины, а по путевым заметкам одиночек, которые не пожалели времени на разгребание этой кучи хлама. Отсюдо просто проситсо мысль засесть за *.nix, да и сделать все по человетчески. Хоть и за пол-года, но сделать. Просто хотелось услышать мнение человека, сумевшего и NT понюхать и в Linuxe чё-нить прибомбить. Вот товарисч один посоветовал контроллеры вешать на DOS или 9x, и при этом говорит: LPT - ни ни. Архаика Канешна хочетсо все по современному сделать. И чтоб интерфейс красивый, и контроллер железобетонно встал. Может правда на Linux? Я ведь не ошибся с тематикой в этом форуме?
tretiy3 Ну, я об этом уже говорил (см. выше): порты (особенно LPT) через API (3е кольцо) могут не работать без обьяснения причин. На ноутах такое происходит чаще чем на PC. Кто в этом виноват? - Производитель контроллера, разработчик OS, криворукие драйверописатели... ещё кто-то? В общем, не факт, что баг вообще в API. Не вижу логики. Железо в *никсах тоже что и в винде, ядро с не меньшим количеством багов, есть ещё куча зависимостей от дистриба, версии ядра и т.д. Лучше на Мак пересесть. Можно на NT использовать LPT и COM через API, но потом не надо жаловаться, что на другом компе приложение уже не работает. ПО для контроллеров имено так разрабатывают (программатор/дебуггер/IDE) - через COM, без самопальных дров. Только в лиц. соглашении нужно написать "AS IS" и полный disclaimer. В *никсах COM вообще часто используется для подключения терминала (консоль) вместо монитора. Следовательно, нет необходимости писать свои дрова для использования этого стандартного порта. Через системную функцию open можно открыть com1, через ioctl задать конфигурацию и дальше можно использовать read/write. Ладно, всё равно решать не мне.
про архаику - без обид Мне просто казалось раньше, что в компьютерном мире все давно устаканилось, и где-то есть вумные люди, которые уж точно все знают. А тут на тебе: шаг влево шаг вправо - вход только для избранных. Наткнулсо здесь http://www.linux.ru/articles/sco/ на такую фразу "Окунувшись в новый мир, я был очарован ясностью всего, что меня окружало. Нету больше таинственных dll в глубокой c:\windows\system" и решил - "ну мне навверное сюда..."
Если в документированных по полной программе NT возникают проблемы с API, то в никсах будет на порядок больше проблем с теми же системными вызовами. А про "таинственные" dll могу сказать: либы и шаредобджекты гораздо более таинственны и недружелюбны, чем dll. После NT погружение в недра линукса привело меня в состояние ужаса. И основная причина этого - отсутствие поддержки документацией со стороны разработчиков на таком уровне, как это осуществляет M$. Нету в *никсах MSDN, и ничего с этим не сделаешь. Противоречивые и обрывочные маны только усугубляют ситуацию. И спросить не у кого: на одного знающего линуксоида приходится сотня знающих виндусоидов при примерно одинаковой квалификации как тех, так и других.
