STM32F100C6T6 и 1-wire, не отладить в IAR EWARM v6.30.4 Опции

[ivainc1789]

К 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. Нужна помощь...

[ivainc1789]

Код

Почитал дискусиию и решил проверить действительно ли такие траблы...

Если вы внимательно читали, то понимаете, что суть темы не в том, чтобы подключить датчик DS18B20 к STM32F100 как таковой - он у меня уже давно работает именно на софтовых задержках, реализации которых в принципе достаточно для большинства проектов. Я бы даже сказал, что нет необходимости эту реализацию задержек как-то переделывать, т. к. на время работы с шиной 1-wire все равно придется приостанавливать большинство других софтверных задач, т. к. времянка слишком жесткая...
Мое неудачное портирование исходников 1-wire на STM32F100 было связано с попыткой использования для счета задержек systick таймера ядра. Опять же, я осознаю, что это излишне и не нужно - по сути ничего не дает, но поведение этого таймера на счете "мелких" задержек вызвало мое непонимание его работы. Вот это и напрягает... Я был бы признателен тому, кто смог бы выделить время и проверить, в чем тут может быть проблема...
Повторюсь, в чем проблема... После счета задержки на основе этого таймера состояние шины 1-wire не может быть достоверно прочитано в рамках, например, сброса/проверки этой шины:

Код

//  генератор  прецизионных  таймингов  для  1wire (Tmax[sec]=2^24/Fhclk)
__INLINE void Delay1wire(unsigned int Ticks){
  SysTick->LOAD  =  Ticks - 1;// возможна подстройка для точности
  SysTick->CTRL  =  0x00000005;//  запуск  таймера
  while(!BITCHK(SysTick->CTRL,SysTick_CTRL_COUNTFLAG));// пока не установится COUNTFLAG
  SysTick->CTRL  =  0x00000004;// останов таймера
}

//  пин  C15  настроен  как  GPIO_Mode_Out_OD ( эмуляция  1-wire)
//  к  пину  C15  припаян  внешний  pull-up 5k с датчиком DS18B20
//  пин  A11  тестовый ,  настроен  как  GPIO_Mode_Out_PP
Work:
  GPIOC->BRR=GPIO_BRR_BR15;//  сбросить  С15 (шина в состояние "0")
  Delay1wire(500*us);
  __istate_t s = __get_interrupt_state();
  __disable_interrupt();
  GPIOC->BSRR=GPIO_BSRR_BS15;//  установить  C15  (шина в состояние "1")
  Delay1wire(80*us);
  tmp=(GPIOC->IDR >> 15)&1;// получить текущее состояние шины(должен быть "0" при испр датчике
  __set_interrupt_state(s);
  GPIOA->BSRR=tmp?GPIO_BSRR_BS11:GPIO_BSRR_BR11;//  тестовый  пин(при подкл исправном датчике) всегда  = 1 = ошибка !!!!!!
  Delay1wire(420*us);
  goto Work;

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

Код

//  пин  C15  настроен  как  GPIO_Mode_Out_OD ( эмуляция  1-wire)
//  к  пину  C15  припаян  внешний  pull-up 5k с датчиком DS18B20
Work:
  GPIOC->BRR=GPIO_BRR_BR15;//  сбросить  С15
  Delay1wire(500*us);
  GPIOC->BSRR=GPIO_BSRR_BS15;//  установить  C15  
  Delay1wire(80*us);
  Delay1wire(420*us);
  goto Work;

По идее, этот код должен давать на С15 сигнал импульс/пауза 500us/500us. У меня он почему-то дает 600us/400us. Естественно все прерывания запрещены.
Хотелось бы понять причину такого несоответствия... Возможно, это поможет понять почему исходно не читается правильно состояние шины...