Микроконтроллеры!!!
Что бы там и про ассемблирование всё доступно было написано и про высокоуровневое программирование подобных устройств.
И что б вроде как для начинающих...Да ты шутник. Программирование по микроконтроллеров - оно само по себе не для начинающих.
Особенно интересны материалы по программированию USB-порта.Чьего USB-порта? Компьютерного под винду? Тогда тебе в MSDN.
Начинать надо не с USB-порта, а с моргания светодиодами и упралением знакосинтезирующего экранчика. До сих пор придерживаюсь мнения, что легче поставить мост U(S)ART <-> USB, чем в самом контроллере это кодить. Драйверы для таких вещей уже есть.
И что у тебя из "железа" есть? С чем работать собираешься? Или пока только под эмуляцией?
И что у тебя из "железа" есть? С чем работать собираешься? Или пока только под эмуляцией?
пока только под эмуляцией
У тебя есть, что-нить по теме?
До сих пор придерживаюсь мнения, что легче поставить мост U(S)ART <-> USB, чем в самом контроллере это кодить.Дорого и медленно.
ты бы хоть написал, о каком контроллере речь идет. Знаешь, сколько их разных?
http://phyton.ru
там есть прикольный эиулятор...
там есть прикольный эиулятор...
11Mbps есть. Нужен USB 2.0?
Да и не особо дорого - $4, по-моему.
Ну можно ещё кинуться на X-port и иже с ними. Но это уже совсем изврат.
Да и не особо дорого - $4, по-моему.
Ну можно ещё кинуться на X-port и иже с ними. Но это уже совсем изврат.
Пользуюсь Proteus VSM.
у тебя есть ключ к Фитоновскому эмулятору?
у тебя есть ключ к Фитоновскому эмулятору?
11Mbps есть. Нужен USB 2.0?11MBps через USART? ну ну.
Да и не особо дорого - $4, по-моему.Офигенно дорого. Это более 50% стоимости самого контроллера. Если делать одну штуку для себя - приемлимо. Если говорить о тираже - то это супермегадорого.
Если совсем туго, то есть контроллеры со встроенным USB, это получсется дешевле, чем USART<->USB, да и быстрее, но только все равно достаточно много низкоуровневого кода писать придется.
11MBps через USART? ну ну.Да легко! (только не надо косить, что 10Mbps - порядок тот же)
PIC18FXX2:
>Да и не особо дорого - $4, по-моему.Если говорить о тираже - то там цены будут другими.
Офигенно дорого. Это более 50% стоимости самого контроллера. Если делать одну штуку для себя - приемлимо. Если говорить о тираже - то это супермегадорого.
Если совсем туго, то есть контроллеры со встроенным USB, это получсется дешевле, чем USART<->USB, да и быстрее, но только все равно достаточно много низкоуровневого кода писать придется.До сих пор не слышал, что кто-то сделал подобное (достойного внимания) - кода там действительно много надо. К тому же (в общем случае) ещё и дрова под комп писать придётся.
Да легко! (только не надо косить, что 10Mbps - порядок тот же)Пожалуйста, такую же табличку, но только не для микроконтроллера, а для этого самого твоего USART<->USB. И еще, ты же говоришь о простоте системной интеграции? Так вот, сколько бы не умел твой USART<->USB, все та же самая винда не умеет выдавать в USART больше 2 Mbps (если ничего не путаю).
PIC18FXX2:
Если говорить о тираже - то там цены будут другими.Отношение цен друг к другу вряд ли сильно изменится. Я говорил о том, что розничная цена известных мне USART<->USB составляет как минимум 50% от стоимости микроконтроллера.
По поводу ручной реализации USB - примитивный USB на уровне HID, например, делается вообще всеми кому не лень. Где-то даже в качестве примеров попадался. А более сложные реализации как правило делают через микросхемы USB-контроллеров. Если ты хочешь получить быструю скорость обмена, то тебе все равно придется писать драйвер, и это не так уж и сложно (в масштабе всего проекта).
Табличку мне эту искать влом. Устройство я в живую видел.
Эта беседа ни к чему не приведёт до тех пор, пока не будет конкретно поставлено ТЗ.
Итак. У нас есть контроллер, который снимает некоторые данные и передаёт их на PC. Пусть их будет 8Mbitps.
Вариантов постоения два
1) Использовать внешний драйвер USB-порта (как хочешь можно его назвать - мост, контроллер. т.п.)
2) Использовать в разработке МК со встоенным USB-интерфейсом.
1.
+ использование простого USART (RS232, как правило)
+ наличие готовых драйверов (API)
+ простота разработки и масштабируемость - можно вместо USB использовать RS485, etc
+ возможность использовать простой (а, значит, и более дешёвый) контроллер, если это возможно
+ высокая пропускная способность при минимальных затратах ресурсов МК
- дополнительные затраты на элементную базу + место на печатной плате
2.
+ полный контроль над USB шиной
+ не нужны дополнительные затраты на компоненты.
- необходим более "навороченный" контроллер => больше затраты на него, место на печатной плате
- необходимо написание драйверов на низком уровне с обоих сторон. (я до сих пор не видел контроллеров с возможностью относительно лёгкой реализации USB-интерфейса)
Эта беседа ни к чему не приведёт до тех пор, пока не будет конкретно поставлено ТЗ.
Итак. У нас есть контроллер, который снимает некоторые данные и передаёт их на PC. Пусть их будет 8Mbitps.
Вариантов постоения два
1) Использовать внешний драйвер USB-порта (как хочешь можно его назвать - мост, контроллер. т.п.)
2) Использовать в разработке МК со встоенным USB-интерфейсом.
1.
+ использование простого USART (RS232, как правило)
+ наличие готовых драйверов (API)
+ простота разработки и масштабируемость - можно вместо USB использовать RS485, etc
+ возможность использовать простой (а, значит, и более дешёвый) контроллер, если это возможно
+ высокая пропускная способность при минимальных затратах ресурсов МК
- дополнительные затраты на элементную базу + место на печатной плате
2.
+ полный контроль над USB шиной
+ не нужны дополнительные затраты на компоненты.
- необходим более "навороченный" контроллер => больше затраты на него, место на печатной плате
- необходимо написание драйверов на низком уровне с обоих сторон. (я до сих пор не видел контроллеров с возможностью относительно лёгкой реализации USB-интерфейса)
Тут вот вспомнилось. Посмотри это.
Может быть понравится.
Может быть понравится.
Табличку мне эту искать влом. Устройство я в живую видел.Вот очень зря тебе эту табличку искать влом. Устройство-то и я в живую видел. Только из тех микросхем, USB<->USART, которые мне пока попадались, максимум что я видел умело 921.6 kbps на USART (При том, что на USB оно сидит как полноценный 12MBps USB2.0). Поэтому никаких "Пусть их будет 8Mbitps." через такую микросхему ты не прокачаешь, и твой вариант 1 отпадает.
а по поводу твоего пункта 2, особенно "необходим более "навороченный" контроллер => больше затраты на него, место на печатной плате" - уже у многих производителей есть контроллеры со встроенным USB, могу кинуть ссылки если интересно. Дополнительного места на плате - никакого. Дополнительных затрат - копейки.
>>Табличку мне эту искать влом. Устройство я в живую видел.Хммм. почитал я тут... по USARTу действительно скоростей более 1Mbit нет. Есть 8Mbit, но там 8ми битрая шина.
Вот очень зря тебе эту табличку искать влом. Устройство-то и я в живую видел. Только из тех микросхем, USB<->USART, которые мне пока попадались, максимум что я видел умело 921.6 kbps на USART (При том, что на USB оно сидит как полноценный 12MBps USB2.0). Поэтому никаких "Пусть их будет 8Mbitps." через такую микросхему ты не прокачаешь, и твой вариант 1 отпадает.
а по поводу твоего пункта 2, особенно "необходим более "навороченный" контроллер => больше затраты на него, место на печатной плате" - уже у многих производителей есть контроллеры со встроенным USB, могу кинуть ссылки если интересно. Дополнительного места на плате - никакого. Дополнительных затрат - копейки.Кидай, конечно.
Микроконтроллеры со встроенным USB:
Atmel, архитектуры 8051, AVR и ARM (последние - на этой страничке).
Microship, PIC
Texas Instruments, 8051.
Это то, что сразу вспомнилось... если поискать, то думаю, что сейчас у всех уже есть такие контроллеры.
Atmel, архитектуры 8051, AVR и ARM (последние - на этой страничке).
Microship, PIC
Texas Instruments, 8051.
Это то, что сразу вспомнилось... если поискать, то думаю, что сейчас у всех уже есть такие контроллеры.
Только корпуса их меня не радуют.
44/TQFP - это минимум из того, что я видел.
Про USB о TI и Atmel не знаю, а вот про реализацию USB-порта на Microchip - в своё время сильно плевались в конференции.
В любом случае, все это контроллеры из навороченных серий.
44/TQFP - это минимум из того, что я видел.
Про USB о TI и Atmel не знаю, а вот про реализацию USB-порта на Microchip - в своё время сильно плевались в конференции.
В любом случае, все это контроллеры из навороченных серий.
Только корпуса их меня не радуют.Что, паять страшно?
44/TQFP - это минимум из того, что я видел.
На самом деле, никаких проблем с такими корпусами нет. Замечательно все распаивается руками. Для бедных студентов, которые не хотят/не могут сами делать платы, есть даже макетки под tqfp корпуса.
Про USB о TI и Atmel не знаю, а вот про реализацию USB-порта на Microchip - в своё время сильно плевались в конференции.Про microchip ничего не могу сказать. Из перечисленного доводилось работать немного с Atmel. Там никаких проблем не возникает точно. Правда, корпус страшный и ужасный TQFP64.
Что, паять страшно?=) Не в этом дело. Такое количество выводов в большинстве (моих) проектов не нужно - 18ти хватает, как правило. Ну или 28.
На самом деле, никаких проблем с такими корпусами нет. Замечательно все распаивается руками. Для бедных студентов, которые не хотят/не могут сами делать платы, есть даже макетки под tqfp корпуса.
Из перечисленного доводилось работать немного с Atmel. Там никаких проблем не возникает точно. Правда, корпус страшный и ужасный TQFP64.Крупная рыба, однако! =)
=) Не в этом дело. Такое количество выводов в большинстве (моих) проектов не нужно - 18ти хватает, как правило. Ну или 28.Даже TQFP64 по площади меньше, чем DIP28, так что говноаргумент. Тебя же никто не заставляет использовать все ноги. Дополнительных денег с тебя за это тоже не берут.
По площади - ты прав.
Однако если нужно шить контроллер в программаторе, то QFTP никак не назвать более удобным, чем PDIP. (при условии, что пользуется DIP-ZIF колодка) А в процессе разработки перешивать контроллер приходится ни раз. Есть ещё правда и внутрисхемное проаммирование, конечно...
Однако если нужно шить контроллер в программаторе, то QFTP никак не назвать более удобным, чем PDIP. (при условии, что пользуется DIP-ZIF колодка) А в процессе разработки перешивать контроллер приходится ни раз. Есть ещё правда и внутрисхемное проаммирование, конечно...
Если у контроллера есть внутрисхемное программирование (у всех названых мной - есть то использовать внешний программатор это чистой воды изврат.
Весьма спорное утверждение. Кому как удобнее.
Весьма спорное утверждение. Кому как удобнее.Хорошо. Приведи пример, когда в процессе разработки внутрисхемное программирование будет менее удобно, чем при помощи внешнего программатора. Сразу предупреждаю: аргумент "а у меня уже есть программатор" не принимается.
Например, когда устройство, которое я отлаживаю, находится далеко от компа.
А для внутрисхемного программирования программатор (схема сопряжения - называй как хочешь) не нужен?
А для внутрисхемного программирования программатор (схема сопряжения - называй как хочешь) не нужен?
Например, когда устройство, которое я отлаживаю, находится далеко от компа.Говноаргумент. RS232 кабель без проблем выдерживает 30-40 метров. Заниматься сложной отладкой (когда нужно много раз перешивать) на большем расстоянии немного странно. Перешить несколько раз можно в крайнем случае с ноутбука или даже КПК (программаотры под PalmOS для Atmel'ов мне попадались
)А для внутрисхемного программирования программатор (схема сопряжения - называй как хочешь) не нужен?Она собирается на коленке из двух транзисторов и мелочевки.
Более того, даже специальный софт особо не нужен - практически для всех девайсов есть COM и USB загрузчики, прошив которые один раз сложным софтом или программатором дальше все льется тривиальным стандартным софтом через COM или USB
Странно это или нет, а иногда приходится практиковать.
Кстати, почему наличие программатора с кучей возможностей является говноаргументом?
Кстати, почему наличие программатора с кучей возможностей является говноаргументом?
Странно это или нет, а иногда приходится практиковать.Поясни. Приходится это практиковать как штатный способ разработки? Во время отладки иногда приходится контроллер перешивать раз по 20-30 в день. Т.е. во время отладки по твоему сценарию нужно 20-30 раз в день бегать на расстояние больше 40 метров с целью воткнуть контроллер? Без конкретной (не абстрактной) иллюстрации такой ситуации, когда во время разработки нельзя подобраться к контроллеру хотя бы на расстояние 40 метров, не поверю.
Кстати, почему наличие программатора с кучей возможностей является говноаргументом?Потому что из всей кучи возможностей программатора в сценарии отладки кода на контроллере, используются только те возможности программтора, которые уже доступны через ISP.
Кстати говоря, еще один плюс ISP - можно использовать JTAG. Конечно, JTAG можно использовать и с внешним программатором, но только вот использование JTAG для отладки, и не использование его же для прошивания кажется мне опять же странным.
Приходится это практиковать как штатный способ разработки? Во время отладки иногда приходится контроллер перешивать раз по 20-30 в день. Т.е. во время отладки по твоему сценарию нужно 20-30 раз в день бегать на расстояние больше 40 метров с целью воткнуть контроллер? Без конкретной (не абстрактной) иллюстрации такой ситуации, когда во время разработки нельзя подобраться к контроллеру хотя бы на расстояние 40 метров, не поверю.Ну не 40 метров. В моём случае - метров 10. Не суть. Как штатный способ разработки я использую Proteus VSM. Вся необходимая схема строится моментально, паять и прошивать ничего не надо. Кода дело доходит до отладки - приходится немного побегать. =)
Потому что из всей кучи возможностей программатора в сценарии отладки кода на контроллере, используются только те возможности программтора, которые уже доступны через ISP.Гм. Причём тут отладка кода, когда говорим о программаторе?
Ну не 40 метров. В моём случае - метров 10. [...] Кода дело доходит до отладки - приходится немного побегать. =)Вот что бывает, когда либо нет ISP, либо лень его использовать. Впрочем, бег наверняка полезен для здоровья программистов
Гм. Причём тут отладка кода, когда говорим о программаторе?Ты задал вопрос: почему наличие программатора - говноаргумент.
Я тебе отвечаю: о вопросах заливки микросхем в процессе производства у нас речи не было, мы разговаривали о написание и отладке кода, так?
Если речь идет о написании и отладке кода, то наличие программатора не является явным достоинством при выборе DIP+программатор против TQFP+ISP по тем причинам, которые я указал.
Вообще, выбирать микросхему из соображений корпуса, если не стоит задачи вписаться в заданные размеры - это весьма примитивный подход.
Ты задал вопрос: почему наличие программатора - говноаргумент.Nope. =) Ты ошибаешься. Перечитай свои посты. Я ни слова не говорил о ICD. Только программирование (прошивка).
Я тебе отвечаю: о вопросах заливки микросхем в процессе производства у нас речи не было, мы разговаривали о написание и отладке кода, так?
Вообще, выбирать микросхему из соображений корпуса, если не стоит задачи вписаться в заданные размеры - это весьма примитивный подход.Что ты этим хотел сказать? Я тебя не понял. Корпус не панацея, но он напрямую зависит от возможностей контроллера.
Nope. =) Ты ошибаешься. Перечитай свои посты. Я ни слова не говорил о ICD. Только программирование (прошивка).Ты говорил об использовании DIP-ZIF колодки. Хочешь сказать, что ты ее используешь не на отладочных схемах? Она ж сама по себе дороже контроллера
Что ты этим хотел сказать? Я тебя не понял. Корпус не панацея, но он напрямую зависит от возможностей контроллера.Ты говорил о том, что контроллеры в корпусах TQFP44 для тебя не подходят, т.к. для тебя у такого корпуса слишком много выводов.
Ты говорил об использовании DIP-ZIF колодки. Хочешь сказать, что ты ее используешь не на отладочных схемах? Она ж сама по себе дороже контроллераЭта колодка стоит на программаторе. На плате устройства - обычная коллодка.
Ты говорил о том, что контроллеры в корпусах TQFP44 для тебя не подходят, т.к. для тебя у такого корпуса слишком много выводов.40 выводов для большинства моих проектов - это много. Чего удивительного? Если есть возможность использовать контроллер с меньшим кол-вом выводов (и если он, к тому же, ещё и дешевле) - почему бы его не использовать.
RS232 кабель без проблем выдерживает 30-40 метров.Вот так растут слухи. Еще на прошлой неделе я поведал Леве, что у меня заработал RS232 при длине кабеля "около 30 метров".
Вообще-то, RS 232 работает и до 300 метров на скоростях 4800-9600.
RS-232-C является стандаpтом интеpфейса, pазpаботанного EIA (Electronics Industries Association) (RS - Recommended Standart, C - веpсия) введен в 1962г. EIA RS-232-C описывает несимметpичный интеpфейс междy аппаpатypой пpиема и пеpедачи данных, pаботающий в pежиме последовательного обмена данными со скоpостями до 20000 бит/сек, однако длина кабеля огpаничена 50 фyтами (15 м).
Спецификации RS-232-C не огpаничивают максимальнyю длинy кабеля, но огpаничивают максимальное значение его емкости 2500 пф. Емкость интеpфейсных кабелей pазлична, однако общепpинятой длиной yдовлетвоpяющей данной спецификации считается длина 50 фyт (15 м) (до 20000 бод) Чем выше скоpость пеpедачи, тем больше искажения сигнала, вызванные емкостными хаpактеpистиками кабеля.
Выпyскаются специальные интеpфейсные кабели пpямой связи RS-232-C низкой емкости, котоpые yдовлетвоpительно pаботают со скоpостью 9600 бод на pассоянии до 500 фyтов (150 м).
Число подключаемых пpиемников и пеpедатчиков подключаемых к одной линии - 1/1, (в отличие от стандаpтов RS422 1 передатчик/ 10 пpиемников или RS485 32/32)
Таким обpазом полyчившие сейчас pаспостpанение линки пpямой связи на скоpости 115 Кбод выходят за стандаpт RS-232-C, это означает что изготовители интеpфейсных плат не гаpантиpyют pаботy на этих скоpостях и дело здесь не столько в том, что это позволяют совpеменные кpисталлы пpиемо- пеpедатчиков а в интеpфейсных чипах. Однако я pазыскал диагpаммy скоpость/pасстояние для RS-232-C, и взял на себя смелость экстpаполиpовать ее на эти скоpости, полyчилась величина поpядка 2-5 м на скорости 115 Кбод.
Из этой же диагpаммы: 10 Кбод - 200 фyтов (60 м 500 бод - 3000 фyтов (800 м).
Hизкая скоpость и дальность этого интеpфейса огpаничена в пеpвyю очеpедь его несимметpичностью. Hапpимеp более поздний RS485 до 1 Мбод на 1200 м.
Вот так растут слухи. Еще на прошлой неделе я поведал Леве, что у меня заработал RS232 при длине кабеля "около 30 метров".Слухи тут не при чем. Я потом спецификацию протокола поднял и проверил
Оставить комментарий
dasha69
Доброго время суток, вам. Мне вот что интересно: кто-нить знает какую-нибудь хорошуюкнигу по программированию портов,микроконтроллеров и т.д. Что бы там и про ассемблирование всё доступно было написано и про высокоуровневое программирование подобных устройств. И что б вроде как для начинающих... Особенно интересны материалы по программированию USB-порта. Если у кого есть чем поделиться по этому поводу, то пишите. Заранее всем спасибо.