controller_m30

Идеи (сам не проверял, но "по мотивам"). Под 100 клетками 100 катушек, подключенных к контроллеру через мультиплексоры. В фишках какой-то металл: медь, алюминий, железо - но в разной "дозировке". Получается типа многоканального металлоискателя. Или в фишках комбинация из проволочной катушки и конденсатора (LC-генератор на разную частоту резонанса). Катушки можно намотать на феррит - так вероятно ещё лучше. Контроллер меряет величину индуктивности в катушках игрового поля (например через LC генератор импульсов). Над клетками где есть фишки с катушками, индуктивность будет другая. Статья про устройство стилуса для телефона с емкостным сенсором: http://microsin.net/adminstuff/hardware/s-...ote-inside.html Такие LC-генераторы в каждую фишку, только с разными параметрами деталей. Вторая идея (с иллюстрацией). Емкостной сенсор. 100 емкостных полей подключенных к контроллеру (100-канальных я не встречал, но 16 канальные продаются широко). Игровое поле изолировано от прямых касаний диэлектриком (плёнкой, пластиком). В фишке - край корпуса из металла, чтоб был контакт с телом человека (кольцо по окружности). Внутри фишки резистор, передающий контакт на плоскую круглую площадку снизу фишки. Площадка изолирована от касаний. В зависимости от величины сопротивления - будут разные показания ёмкости, измеряемой сенсором. Правда идентифицироваться фишки будут только пока есть контакт с телом человека. В приведённой выше статье LC-стилус работает с емкостным экраном. Может фишки с LC-генераторами из первой идеи, можно использовать с емкостными сенсорами в игровом поле?

Может мелочь, но всё таки. На фигуре 30-1 (для S70) нарисована схема Clock Generator крупным планом. А на фигуре 31-1 этот же Clock Generator немного отличается по внутренним связям. Какой из рисунков правильный не понятно. Если правильная фигура 30-1, тогда всё нормально. А если правильно то что на 31-1 изображено, то этот Clock Generator отличается от того что у V70. Проверьте ещё прерывания по сбросам шины USB. Сбросы-то ведь происходят. Значит хотя бы эти прерывания должны приходить. Точку останова в обработчик прерывания поставьте, с зажиганием светодиода в этот момент. А сам обработчик зациклить на себя. Может что-то не так с разрешением прерываний (вообще, и для модуля USB в частности), или их тактированием? (если такое есть) В статьях в инете написано, что стартует обмен сначала в FullSpeed, потом происходит какая-то условная перекличка состояниями JKJK с хостом, что означает устройство HighSpeed, и дальше обмен идёт на HighSpeed скорости. Из того что происходит запуск обмена в FullSpeed, потом происходят сбросы в HighSpeed режиме - можно предположить что контакты D+/D- не перепутаны, т.к. для определения FullSpeed нужно было найти резистор на определённой ножке. И JKJK перекличка происходит успешно, раз начинаются сбросы для HighSpeed состояния. Если прерывания работают, тактовая 480 и 48мГц есть, внешняя обвязка в норме, всё проинициализировано внутри, а событий нет - может пример от V70 всё-таки не подходит? Хотя даташиты вроде как похожи... Я бы теперь пробовал запускать только в FullSpeed режиме, и использовал бы для снятия аппаратного лога анализатор SaleaeLogic - он могёт декодировать состояния шины для FullSpeed. И стоит копейки (китайского производства конечно). Аппаратно подключиться к обмену на шине, можно с помощью развязки буфером типа 74hc06 и т.п. Нужно два разъёма USB: папа и мама (чтоб включать в разрыв шины USB), и одна микросхема логики, чтоб не нарушать ёмкость шины (у 74hc серии ёмкость входа несколько pF). Один буфер подключается входом на D+, другой входом на D-, а выхода буферов подключаются к анализатору. Может там что-нить обнаружилось бы...

Я нашёл такое. Пин VBG через резистор 5к62 1% подключенный на GNDUTMI, и параллельно резистору кондёр 10pF. В общем как на схеме в конце даташита. Надо бы посмотреть. Может и остальную обвязку порта USB, из резисторов 15к и 22к попробовать? Ещё такое. Регистр USBHS_CTRL (самый первый в списке регистров USB) - для ATSAM V71 там есть дополнительный бит UID, которого нет у ATSAM S70. Может это отличие что-нить значит?

Мне кажется, нужно посмотреть в описании примеров MSD и CDC на какой кварц они рассчитаны. Если примеры не для 12мГц, то заменить кварц на тот что в примерах. Или просто заменить кварц, на всякий случай. Если с кварцем всё в порядке, то нужно как-то проверить частоту UPLLCK, действительно-ли она 480мГц. В даташите есть диаграмма "General Clock Block Diagram" где видно, что UPLLCK можно вывести как источник для MasterClock, ProcessorClock, PeripheralClock и т.д. Вывести эту частоту (через имеющиеся там делители) на какую-то периферию, типа таймера, и пусть он выдаёт на внешнюю ножку меандр. С помощью осциллографа, частотомера, или другого контроллера - посмотреть частоту этого меандра. Или используя эту частоту для тактирования процессора, сделать мигалку светодиодом, с частотой 1Гц, и сравнить скорость мигания при тактировании: от кварца 12мГц напрямую (минуя UPLLCK), от внутреннего RC осциллятора 4,8,12мГц, от кварца 32768 и т.п. Этот способ не сильно точный, но хотя бы грубо прикинуть соотношение частот позволяет.

У меня есть отладочная плата с контроллером, работающем в режиме USB CDC (USB-UART переходник), скорость Full Speed. Программа на ассемблере, могу менять там что угодно. Я добавил к обработчикам разных событий на шине (SOF, Reset, Get_Descriptor) мигание светодиодами на плате. Что получилось. В режимах "Выключение" и "Ждущий режим" (это когда выкл. всё: монитор, ЖД, даже вентилятор блока питания - но программы остаются в RAM) - на шине присутствует только SOF. Ни одного запроса дескриптора, или хотя бы состояния "Reset" на шине не было. Переподключение устройства к шине, ничего нового не показывает: есть только SOF, а USB-сброса, или запросов дескрипторов нет. Частота SOF стандартная для FullSpeed - 1ms. В BIOS моего компа нет функции пробуждения от USB устройств (есть только от PS/2 мыши и клавиатуры). Может быть поэтому дескрипторы не читаются :laughing: PS. Комп не сильно старый, 2-х летней давности, стационарный.

Сниффер сделал, ошибку нашёл. Спасибо всем за участие и идеи :) Движок энумерации делался для MSD, а поскольку MSD не использует всех возможностей шины, то для экономии места в нём были сделаны некоторые упрощения, за ненадобностью. Когда я подставил в движок дескрипторы CDC, то он в тех местах где "упрощено" - стал слать пустые пакеты, типа просто подтверждать приём. За что от Хоста получил Suspend В общем буду переписывать движок, чтоб был совсем уж универсальный. Что нового узнал при снятии логов. 1. Suspend в процессе энумерации и работы сам по себе не возникает. Т.е. всё-таки, это ситуация неправильная. Проверил на PL2303, CP2102, FT232R и AVR-CDC (на ATMega48). Даже к бездействующему устройству непрерывно шлются Sync-пакеты. Только и разницы, что для Low Speed это каждые 8ms, а для Full Speed каждую 1ms. 2. Программа Saleae Logic научилась расшифровывать USB Low Speed и Full Speed, что радует :rolleyes: 3. PL2303, CP2102 и FT232R, хоть и USB-COM переходники, но дескрипторы у них не стандартные для CDC (нет функциональных дескрипторов, о которых пишет Агуров, и которые в спецификации CDC), и потому без специально написанного под них драйвера работать напрямую с Windows они не могут. Зато на Android-смартфоне, все вышеназванные переходники (включая AVR-CDC на Mega48) работают без дополнительных драйверов. Такой вот парадокс :laughing:

Спасибо. Внутренний лог обмена я снимаю - и вроде бы всё нормально (есть опыт с классом устройств MSD). Правда нормально до тех пор, пока suspend не возникает Начал делать простенький сниффер под Saleae Logic - в последней версии появилось декодирование USB Low Speed и Full Speed. Попробую снять лог инициализации PL2303, или COM-переходника на AVR-контроллере (он вроде в Low Speed работает).

Здравствуйте. Делаю переходник USB-UART CDC. После энумерации он тут же уходит в suspend. Если на ПК ещё нет драйвера, то уйдёт в suspend сразу после его установки. А до этого будет ждать, и высылать дополнительные дескрипторы по запросам ПК. Если же подключать устройство при уже установленном драйвере, то уходит в suspend немедленно после энумерации. При этом пишет в диспетчере устройств что есть Virtual COM Port, но запуск невозможен [код 10]. Вопрос такой. Этот самый suspend - это в моей программе какая-то ошибка энумерации, или для CDC устройств так и должно быть? Как вывести устройство из suspend я тоже не понимаю (если это вообще обратимое состояние, конечно). В программе, при появлении события suspend всё перевожу в состояние микропотребления (но модуль USB остаётся включен), "усыпляю" процессор, разрешаю прерывания, и жду события resume, которого всё нет. Я правда точно не знаю, сколько при этом потребляет устройство от шины USB - но в других приложениях, при тех-же действиях, устройство "кушало" примерно 50-70uA. Т.е. требованию, о потреблении менее 0.5мА вроде как должно соответствовать... Агурова читал, программные семплы разных производителей для CDC смотрел (для STM32, AVR, MSP430), но так и не понял главного - suspend это норма, или какая-то исключительная ситуация???

По поводу защиты от удаления, но не перезаписи. Удаление начинается с записи числа 0хЕ5 в первый символ названия файла. По этому признаку можно отличить, что пользователь замыслил именно удаление а не перезапись. И такую транзакцию можно просто заблокировать до её завершения. ПО контроллера исправно примет все данные от компа, отрапортует о больших успехах - но физической записи не сделает. Если же запись файла идёт с нормальными символами в заголовке - значит это именно перезапись файла, и её можно проводить. Ещё про защиту от случайной перезаписи :rolleyes: Чтоб пользователь случайно не перезаписал файл, в котором он из любопытства покопался "блокнотом", и при закрытии согласился сохранить изменения - можно сделать то что писалось в первом посте темы. Файл поступивший для перезаписи должен иметь установленный атрибут "System" (или любую комбинацию из нескольких атрибутов). Но при вычитывании Виндой в кэш содержимого "флешки" - у этого файла таких атрибутов быть не должно (у него должен быть обычный вид). Тогда при случайной перезаписи ПО контроллера не обнаружит установленного атрибута, и проигнорирует такую запись. А перезаписывать сможет только тот, кто руками устанавливает перед этим комбинацию атрибутов.

Я недавно делал USB MSD с программной генерацией: MBR, BS, FAT, Root, и тремя файлами в корневом каталоге. Два файла фиксированной длины, и один переменной, который иногда должен переписываться. Вся "флешка" объёмом около 1мб. Файловая система FAT16. Вроде бы здесь о похожем говорят :rolleyes: В общем приведу по памяти, вдруг то что надо. При перезаписи переменного файла (например он назывался File.exe) Винда делает так. 1. В корневой каталог записывается новый блок данных, в котором у File.exe поля: длина и начальный кластер - равны 0. 2. В FAT1 записываются новые данные, где вся цепочка кластеров этого файла равна 0. 3. Аналогично дублируется FAT2. 4. В корневом каталоге у файла File.exe прописываются стартовый адрес кластера и новая длина в байтах (т.е. Root снова переписывается). У меня стартовый кластер равен тому-же, что был и у предыдущей версии файла. 5. FAT1 записывается новая таблица, где очищенные до этого кластеры заполнены новой цепочкой. 6. FAT2 дублируется. 7. В корневом каталоге у файла File.exe меняются поля "Дата последн. записи" и "Время последн. записи" на новые (т.е. Root ещё раз переписывается). 8. Записывается тело файла в те-же сектора где была прежняя версия. 9. В корневом каталоге снова делается запись с изменённым полем времени (снова запись Root). 10. Делается ещё одна запись с изменённым полем времени (и ещё раз пишется Root). По пунктам 7,9,10 я сейчас точно не помню, какие временные поля, и в какой очерёдности переписываются. Помню только что их три: дата создания, дата модификации, и дата открытия. И вроде бы, оно три раза те поля и переписывает. Почему это делается в три приёма (а не за один раз) я не помню. Вроде бы поле "дата модификации" несколько раз переписывается... зачем-то... Не помню :laughing: Чтения секторов при этом процессе вообще нет. Как считала Винда всё в кэш при подключении, так из кэша все сведения и черпает: и FAT1,2 и Root.

Попробуйте добавить в регистр UCA1MCTL, в биты UCBRSx число 3 - как это приведено в таблице 15-4 мануала для USCI. Может этого достаточно будет. Ещё проверьте - не перепутаны ли TX RX сигналы на плате. Кроме того, есть ли физический контакт в линии (бывают обрывы). Прямо тестером прозвоните цепь от ножки МК до ножки на схеме ПК, откуда идут данные. И ещё посмотрите замыкание линии RX контроллера: на землю, питание, или какую-то соседнюю ножку. Вообще гляньте вольтметром, какое напряжение на этой ножке в отсутствие данных, и во время приёма. Вот ещё. Скорость передачи на стороне ПК именно 19200? Параметр настроек "Управление потоком" в состоянии Off? И остальное (бит четности, стоп бит) - как положено?

В F5438A нету PortMapping :laughing: А вообще в 5-й серии встречается, я пользовался в F5510 и F5342. Для разводки платы штука удобная. Программируется несложно. Есть регистр пароля доступа, регистр режима доступа (всего 1 бит - однократный или постоянный доступ к перепрограммированию), и 8 регистров настройки самих пинов. Сначала подаётся пароль (код 2D52h), а затем в течении 32 ассемблерных команд CPU, должна быть хотя бы 1 запись в регистры пинов - иначе доступ на запись к ним блокируется. После каждой записи в регистр пинов снова есть 32 команды CPU для записи. Если нарочно записать неправильный пароль, то доступ блокируется немедленно. По умолчанию включен режим однократного доступа к регистрам пинов. Т.е. после сброса можно только 1 раз записать пароль и изменить настройки пинов. А потом запись даже через пароль блокируется. Это дополнительная защита от случайной перезаписи. Чтоб снова получить возможность записи - нужно дополнительно изменить ещё и бит режима доступа (пароль - бит доступа - изменение пинов). В slau208 написано исчерпывающе (как на мой взгляд). Ничего дополнительно "открывать" не придётся.

Схема из первого поста, в даташите соответствует примеру для двух\трёх батареек 1.5В. А не для одной. Для питания от одной батарейки 1.5В в том-же даташите есть другая схема (прикрепил внизу). Отличие в общем только в кондёре С3 равном 100uF (а не 47 uF). Обратите внимание на примечание внизу схемы: кондёры С1, С2 должны быть керамическими, а С3 - так вообще Low ESR Tantalum. На второй картинке заводская плата EvalBoard с этим преобразователем. Сравните детали в своём монтаже с теми что ставят на заводе: C1,C2 керамика, С3 - тантал Low ESR (это его типичный вид). И индуктивность посмотрите какая массивная - так выглядят рассчитанные на токи 1.5А. У вас такие детали, хотя бы примерно? Если нет, то ищите как на картинке. Обычный ширпотреб в этой схеме будет работать из рук вон плохо :laughing:

Я как-то "жестко" усыпил контроллер F5510 прямо со старта программы (выключил регулятор питания ядра), в результате чего он не отзывался на доступ по SBW. Получилось затереть такую прошивку новой по USB (BSL) с помощью проги MSP430_USB_Firmware_Upgrade_Example взятой на сайте TI. http://software-dl.ti.com/msp430/msp430_pu.../index_FDS.html

В этом документе http://www.ti.com/lit/ug/slau176d/slau176d.pdf на 8 странице написано, что EZ430-F2013 поддерживает: MSP430F200x, 'F201x, 'G2x01, 'G2x11, 'G2x21, and 'G2x31 :laughing: Я программировал MSP430F5510 с помощью MSP-EXP430G2 LaunchPad. Шьёт всё, в чём есть SBW-интерфейс.

Предположение на основе картинки с отладочной информацией. Если частота процессора действительно 20мГц, а скорость обмена 9600 (или 57600), то такая частота проца не кратна ни 9600 ни 57600. В таблице 14-3 даташита есть примеры (стр.478-481) http://www.alldatasheet.com/datasheet-pdf/...S/H8S2398F.html Может попробовать кварц с частотой кратной 9600 (57600)? Ближайшие к 20мГц: 19.6608 MHz; 17.2032 MHz; 14.7456 MHz; 12.288 MHz.

Перезагрузки чаще происходят при USB-подключении, или при включенном сетевом адаптере (без USB)? Подключение по USB делается к стационарному компу, или к ноуту? Моё предположение "наугад", что это наводка с незаземлённого корпуса стационарного компа (110 вольт), по оплётке USB-кабеля на плату. А палец на корпусе процессора выступает в роли заземления. Но могут быть другие варианты, смотря что ответите.

Ну можно использовать 16 одинаковых подстроечных резисторов. Накрутить отвёрткой номинал - уникальный на каждой плате, зафиксировать краской (или "запломбировать") - и пусть себе стоят :laughing: Детали купили одинаковые, а номиналы получили разные. :rolleyes:

В смысле не технологичное? Такое нельзя сделать доступными технологиями? Экономия деталей, пинов ПЛИС, и разъёмов здесь максимальная: на одну плату - 1 пин и один резистор. Меньше уже не придумать :laughing: Или вы вообще хотите определять количество подключенных плат, и их условные номера, по общей для всех шине из 1-3 пинов? Типа как Plug and Play в компе?

То что предложил ViKo, как я понял. Присоединяюсь, самое простое. ПЛИС разряжает кондёр до 0, а потом переводит пин в режим входа и ждёт когда кондёр зарядится до пол-питания. В зависимости от номинала резистора время заряда будет разное.

В DS18B20 (1-wire) есть уникальный 64 битный код в каждом датчике. Стоит не дорого, продаётся всюду, корпус TO-92 место не занимает. Бонусом можно ещё и температуру каждой платы мерить :rolleyes:

Отечественный аналог ULN2003 - 1109кт22. В интернет-магазинах тоже есть. http://www.sitsemi.ru/kat/1109kt22.pdf

Поскольку в первом посте автор разворачивает вопрос так, что ему нужно приспособить микросхему стандартной логики для управления: транзисторными ключами, реле и светодиодами - то попробую ответить на этот вопрос комплексно. Под данную задачу наиболее подходит микросхема ULN2003. Она широко доступна и стОит в тех-же пределах что и стандартная логика. Корпуса DIP-16 и SOIC-16. Функционально она аналогична микросхеме SN7406 (6 инверторов с открытым коллектором). Только в её составе 7 инверторов с ОК, мощные транзисторные ключи на выходе, и имеется защита выходов от обратного тока, которая обязательна для управления катушками реле (а также шаговыми двигателями, и прочими индуктивными нагрузками). В отличие от SN7406 с нагрузочной способностью 40mA, у ULN2003 нагрузочная способность выхода 500mA. На картинке пример подключения к ULN2003 одного реле и одного светодиода запитанных от источника 12В. Резистор 2.4К нужен для ограничения тока через светодиод не более 5мА (12В \ 2400 Ом = 5мА). Если источник питания светодиодов 5В, то резистор надо на 1К (5В \ 1000 Ом = 5мА).

Попробуйте такую последовательность (исходный уровень всех сигналов =1): 1. Reset = 0, пауза 0.1 сек 2. Reset = 1, пауза 0.5 сек 3. Команда 0х11 (exit_sleep_mode) 4. Пауза 1 сек 5. команда 0х29 (set_display_on) После этого (обычно) на экране появляется разноцветный "снег". Т.е. дисплей включился. Последовательность подачи сигналов (RS, CS, WR, выставления данных на шину) - показана на странице 13 даташита MI0177FT. Если непонятно, можно и их словами расписать.

А что за устройство подключаете к STM32? Google на запрос "MI 0177FT" ничего не выдаёт :laughing: