[ivainc1789 0]

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

main.pdf

Разочарований в 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. Нужна помощь...

[Aner 4]

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

Реализация сделана на F107, через RS порт.

[ivainc1789 0]

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...

[Aner 4]

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

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

[zoddy 0]

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

 

[skripach 5]

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

:crying:

К STM32F100C6T6 подключен DS18B20. Со времен AVR есть отлаженные...

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

[ivainc1789 0]

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

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

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

__INLINE void Delay1wire(unsigned int Ticks){
  unsigned int tmp = Ticks/3;
  while(tmp--);
}

И это сработало!!! Функция BusReset() возвратила ноль! Но остался важный вопрос - почему нельзя в данном контексте использовать SysTick таймер? Функцию задержки на его основе я проверял - отдельно все работает нормально...

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

[lexanet 0]

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

 

#define Set_PortC_Pin_6_input ((GPIOC->CRL &= ~0x3000000)|(GPIOC->CRL |= 0x4000000))
#define Set_PortC_Pin_6_output ((GPIOC->CRL |= 0x3000000)|(GPIOC->CRL &= ~0xC000000))

int start = 0;
int stop = 0;
int count = 0;

Set_PortC_Pin_6_output;
GPIOC->BSRR = GPIO_BSRR_BR6;
delay_us(500);
GPIOC->BSRR = GPIO_BSRR_BS6;            
Set_PortC_Pin_6_input;
delay_us(1);

while (DS && count < 10000)
{
      start++;
      count++;
      delay_us (1);
}
count = 0;      
while ((!(DS)) && count < 10000)
{
      stop++;
      count++;
      delay_us (1);
}

sprintf(out,"%d-%d",start,stop);
ClrLCD ();
LCDgotoxy(1,1);
LCDputs (out);

 

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

[sparcmaster 0]

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

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

[ivainc1789 0]

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

Ну да. А что в этом такого? Это этакий старт в рамках изучения STM32 )))

Но всегда была 1

Вот вот... Пока я считаю, что виновата неадекватная реализация задержек... Почему не получилось использовать SysTick надеюсь кто-нить подскажет. И еще в вашем примере довольно странное управление пином... Конфигурацию его нужно делать один раз в режим output open drain и далее принимать инфу через IDR регистр а выставлять на шину через BSRR. И как у вас реализована функция delay_us(1)? И что там за переменная DS?

Далее... Читал доки. Вроде заранее узнать длительность выполнения последовательности команд в Cortex-M3 не так то просто как например в AVR. Возможно ли реально это увидеть в IAR EWAVR при подключении через J-link? У меня складывается ощущение, что формировать тайминги на 1-wire в случае STM32 нужно максимально задействовав периферию (EXTI и таймеры). Так может получиться проще и круче ))))

[maksimp 0]

при Fhclk = 24MHz частота вывода на пин составляет 6MHz. Но это только при макс оптимизации и в случае НЕИСПОЛЬЗОВАНИЯ библиотек.

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

Но остался важный вопрос - почему нельзя в данном контексте использовать SysTick таймер? Функцию задержки на его основе я проверял - отдельно все работает нормально...

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

То есть например вставить в вашу программу, для ноги 2 порта B:

GPIOB->BSRR=GPIO_BSRR_BS2;
Delay1wire(80*us);
GPIOB->BSRR=GPIO_BSRR_BR2;

Изменено 23 января, 2012 пользователем maksimp

[lexanet 0]

И еще в вашем примере довольно странное управление пином... Конфигурацию его нужно делать один раз в режим output open drain и далее принимать инфу через IDR регистр а выставлять на шину через BSRR. И как у вас реализована функция delay_us(1)? И что там за переменная DS?

 

#define DS (GPIOC->IDR & GPIO_IDR_IDR6)

void DevTIM2 (void)
{
    RCC->APB1ENR |= RCC_APB1ENR_TIM2EN;
    TIM2->CR1 = 0;                                     
    TIM2->CR2 = 0;
    TIM2->CR1 |= TIM_CR1_OPM | TIM_CR1_ARPE;
}

void delay_us (uint32_t us)
{
    TIM2->PSC = 23;
    TIM2->ARR = us;
    TIM2->CR1 |= TIM_CR1_CEN;
    while (TIM2->CR1 & TIM_CR1_CEN);
    return;
}

void delay_ms( uint16_t ms )
{
    int i;
    for (i=0; i < ms; i++){
        delay_us (1000);
    }
}

 

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

У меня 0 при резете ловился стабильно, только если задержку между опусканием шины и освобождением делать не более 50 мкс. И было это уже не резет, а 1. А вот стоит задержку увеличить до штатных не менее 480 мкс, все, тишина. А без резета все остальное не работает.

Изменено 23 января, 2012 пользователем lexanet

[ivainc1789 0]

Можно, дёргая какую-нибудь ногу до и после, проверить осциллографом на сколько она задерживает

Именно так я ее и проверял - работает нормально и в пределах допусков! Но после такой задержки прочитать заранее известное состояние шины 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

 

Поэтому лучше все же конфиг на лету не делать, но по-вашему вроде все равно должно работать...

У меня 0 при резете ловился стабильно, только если задержку между опусканием шины и освобождением делать не более 50 мкс. И было это уже не резет, а 1. А вот стоит задержку увеличить до штатных не менее 480 мкс, все, тишина.

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

Посмотрел, у вас задержки сделаны на TIM2. Неужели и так не прочитаю 0??? Сення после работы попробую обязательно...

 

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

[lexanet 0]

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

 

void Delay (long cnt)
{ 
   while (cnt--);
}

 

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

Изменено 23 января, 2012 пользователем lexanet

[ivainc1789 0]

Достаточно на глаз настроить...

а если частота тактирования Fhclk изменится (в другом проекте)??? Опять настраивать?

...И в бесконечном цикле ждем пока на ноге появиться 0

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