К STM32F100C6T6 подключен DS18B20. Со времен AVR есть отлаженные исходники для 1-wire bus. Думалось, что все будет просто при наладке портированных исходников, но затык случился конкретный: отладить и проверить работу подключенного DS18B20 практически не удалось. Разбор полетов указал на... странную работу портов и решения или ошибки что-то никак не увидел. Пришлось упростить до одного файла main.c, в котором приведены два упражнения (примера). Как вывести из IAR (Win7 64) с русскими комментами вместо крякозябр - не знаю, потому см. аттач.
 main.pdf ( 26.04 килобайт ) Кол-во скачиваний: 603

Разочарований в STM32F100 два:
1. При частоте HCLK 24MHz максимальная частота ногодрыгания ~1.78Mhz. При макс оптимизации! Это катастрофа! Возможно, что-то сделано не так в системе тактирования? Неужели STM32 такие медленные?
2. Отладить простую процедуру сброса 1-wire не смог! Осциллом смотрю - все очень безоблачно: сначала вижу отриц импульс на 500us, потом проц освобождает шину, датчик ждет 35us и удерживает ее в нуле еще на 60-120us, т. е. с момента окончания отриц импульса до момента получения значения состояния шины я заложил 80us - вполне достаточно. Каково же было мое удивление, когда выяснилось, что проц читает это состояние как 1, хотя судя по осциллу явно должен быть 0. Проверил отладкой в EWARM через J-Link Ultra, что если вручную перед чтением установить на шине 0, то это состояние софтом читается правильно. Все дело в скорости чтения... Проц почему-то не может получить значение пина за несколько us. Стало ясно, почему и прочие процедуры чтения ключа и т. п. не работали... Попытки отключить USE_FULL_ASSERT, манипуляции оптимизацией ни к чему не привели, библиотечные функции проверены. Система тактирования проверена частично через вывод на пин MCO - Fhclk=24MHz. Нужна помощь...

1-wire bus довольно жесткий к времянке, не каждый ARM проц его потянет. Вспомнив преждний опыт, отказался его реализовывать в лоб.
Реализация сделана на F107, через RS порт.

Для новичка в ARM звучит как приговор... Какой-то AVR тянет запросто, а сверхмощный (относительно AVR) STM32F100 вообще не может... Хотелось бы разобраться в границах применимости STM32, а то я тут сгоряча 4 девайса спаял для 1-wire на STM32F100C6 и теперь в полной растерянности.
Возникает пара вопросов:
1. Как рассчитать частоту ногодрыганья при HCLK = 24MHz? Порылся в доках, но времен выполнения команд проца не нашел, только описание. Эксперимент показал, что Fgpio ~ Fhclk/14.
2. Что же со временем ввода через пин? В доках написано, что частота сэмплов ввода с портов равна Fapb2=24MHz. Все указывает как бы на то, что ядро медленное, или Fhclk низкая. Последнее вроде проверил - там 24MHz...

В сети мало инфы по 1-wire на STM32, но вроде есть. Только для какого проца - не упоминается...
Щас гляну на F107...

Без опыта преждних разработок и внимательного понимания структуры процессорв можно запросто нарваться. Думая, что ARMы такие сверхмощные, не стоит поддаваться рекламе и эмоциям. ARMы немного другие против PIC, Atmel-ов. Они имеют ряд преимуществ, поскольку внутри много готовых инжин.
Все из себя 32 битные. Но вот как только делаешь свою инжину, особенно привязанню к регистрам, потрам, времянке, то тут ARMы слабоваты. И в ряде проектов пришлось вернуться к PIC, Atmel-ам и их клонам. Например к параллаксовским процам, SX -ам, или к "8-ядерному" пропеллеру.

не знаю, что у Вас там не получается... но у меня на платке STM32Discovery данный датчик шуршит без проблем... и как раз Atmel-овский примерчик был взят за основу... так что скорее всего где-то ошибочка закралась... выкладывайте код - будем смотреть

Это вы программно делаете 1-wire?

Теперь понятно... Но раз уж платы сделаны, хотелось бы лучше осознать. С ногодрыганием (выводом в порт) я разобрался: при Fhclk = 24MHz частота вывода на пин составляет 6MHz. Но это только при макс оптимизации и в случае НЕИСПОЛЬЗОВАНИЯ библиотек. Пришлось выкинуть все, чтобы добиться Fgpio=Fhclk/4. И тут признаем, что такого быстродействия вроде достаточно для вывода на 1-wire. Но что со вводом??? Тут мне не помогли никакие оптимизации и др ухищрения - не может проц правильно прочитать пин за 10us, хотя нет видимых причин... Под конец, я решил переписать функцию генерирования задержки:

И это сработало!!! Функция BusReset() возвратила ноль! Но остался важный вопрос - почему нельзя в данном контексте использовать SysTick таймер? Функцию задержки на его основе я проверял - отдельно все работает нормально...
Естественно, компиляция замененной Delay1wire в режиме Debug нарушила тайминги, но это и понятно... Хотелось бы решить вопрос с ТОЧНОЙ генерацией таймингов для 1-wire на STM32F100 да еще чтобы и в Debug можно было спокойно работать... Может попробовать реализацию задержек на TIM2?...

Я тоже так и не смог подключить DS18B20 к дисковери. Делал все как надо, таймер на 1 мкс, без уарта, дрыгал ножкой. А он даже на резет не отзывался. Для отслеживания резета пользовался парой циклов:



Но всегда была 1. Перенес код без изменений на lpc1768 и все заработало. В чем разница ? В частоте камня\дергания ножек или настройках пинов ?

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

Ну да. А что в этом такого? Это этакий старт в рамках изучения STM32 )))
Вот вот... Пока я считаю, что виновата неадекватная реализация задержек... Почему не получилось использовать SysTick надеюсь кто-нить подскажет. И еще в вашем примере довольно странное управление пином... Конфигурацию его нужно делать один раз в режим output open drain и далее принимать инфу через IDR регистр а выставлять на шину через BSRR. И как у вас реализована функция delay_us(1)? И что там за переменная DS?
Далее... Читал доки. Вроде заранее узнать длительность выполнения последовательности команд в Cortex-M3 не так то просто как например в AVR. Возможно ли реально это увидеть в IAR EWAVR при подключении через J-link? У меня складывается ощущение, что формировать тайминги на 1-wire в случае STM32 нужно максимально задействовав периферию (EXTI и таймеры). Так может получиться проще и круче ))))

Конечно, библиотеки выкинуть. Для такого совсем не годятся.

Задержка на SysTick вроде нормально сделана... Можно, дёргая какую-нибудь ногу до и после, проверить осциллографом на сколько она задерживает в работе с 1-wire?
То есть например вставить в вашу программу, для ноги 2 порта B:


Сообщение отредактировал maksimp - Jan 23 2012, 06:16

Нет, пин нужно настраивать и на ввод и на вывод (вроде во всех основоположниках от макса и атмель так делается). В зависимости от ситуации. Я свой код с stm32 абсолютно без изменений (кроме заголовочного файла и настроек пина и таймера) перенес на lpc1768 и у меня все заработало строго по временным диаграммам из даташита.
У меня 0 при резете ловился стабильно, только если задержку между опусканием шины и освобождением делать не более 50 мкс. И было это уже не резет, а 1. А вот стоит задержку увеличить до штатных не менее 480 мкс, все, тишина. А без резета все остальное не работает.

Сообщение отредактировал lexanet - Jan 23 2012, 06:14

Именно так я ее и проверял - работает нормально и в пределах допусков! Но после такой задержки прочитать заранее известное состояние шины 1-wire почему-то не получается (см. main.c из первого поста) и это тревожит... Т. е. как бы выходит, что SysTick таймер, являющийся периферией ядра - это не то же самое, что стандартные периферийние таймеры на APB2 (при Fhclk = Fapb2 естественно). И это при том, что если вручную установить (замкнуть шину) 1-wire на землю, то в рантайме после этой задержки посредством SysTick состояние 1-wire прекрасно читается как 0. Чудеса какие-то...
все же рекомендую обратиться к ref manual на STM32F100 rev4 стр. 103:
Output configuration
When the I/O Port is programmed as Output:
● The Output Buffer is enabled:
– Open Drain Mode: A ”0” in the Output register activates the N-MOS while a ”1” in
the Output register leaves the port in Hi-Z. (the P-MOS is never activated)
– Push-Pull Mode: A ”0” in the Output register activates the N-MOS while a ”1” in the
Output register activates the P-MOS.
● The Schmitt Trigger Input is activated.
● The weak pull-up and pull-down resistors are disabled.
● The data present on the I/O pin is sampled into the Input Data Register every APB2
clock cycle
● A read access to the Input Data Register gets the I/O state in open drain mode
● A read access to the Output Data register gets the last written value in Push-Pull mode

Поэтому лучше все же конфиг на лету не делать, но по-вашему вроде все равно должно работать...
секунду... что-то тут не так... задержка между отпусканием шины и ЧТЕНИЕМ ее уже известна на момент отпускания и равна примерно (35+50)us. Причем 35 формирует датчик и 50 добавляем мы... или я что-то не понял?..... После "вторых" 480us - ясный хрен будет прочитана 1...
Посмотрел, у вас задержки сделаны на TIM2. Неужели и так не прочитаю 0??? Сення после работы попробую обязательно...

И еще... Стабильность HSI для поддержки 1-wire вполне достаточна (~2.5% в широком темп диапазоне) и не может стать причиной сбоев на шине при переходе от mcu к mcu... Все это ИМХО, конечно....

Для проверки живости датчика и работоспособности программы ни кварц ни таймер не нужен. Для функции резета и приема от датчика ответа временные зависимости не нужны. Достаточно на глаз настроить цикл типа:



и дальше как по DS. Выставляем ногу на вывод, выводим 0, и ждем хоть бесконечность, но можно на глаз около секунды. А потом либо выводим 1 и ногу на ввод или сразу ногу МК на ввод. И в бесконечном цикле ждем пока на ноге появиться 0. Должна появиться, запускаем новый цикл и ждем опять 1. Если это все происходит, то датчик есть, он живой и МК готов с ним работать.

Сообщение отредактировал lexanet - Jan 23 2012, 08:20

а если частота тактирования Fhclk изменится (в другом проекте)??? Опять настраивать?
Конечно, так делать не стоит. Любая помеха на шине будет воспринята как присутствие девайса. Хотя потом его ROM код все равно не прочитается )))) ....