[Alechin 0]

А как-нибудь сделать обработчик членом класса можно? Имя то будет уже другим. "В лоб" не получилось.

Например самый простой вариант - SysTick таймер.

[akimych 0]

А как-нибудь сделать обработчик членом класса можно?

Подозреваю, что это не очень хорошая мысль. Вызываться-то он будет, как обычная процедура.

Такое прокатит разве что со статическим методом. Но видимо придется в стартапе прописать реальное имя этого метода.

Тогда уж проще из обычного обработчика вызывать метод класса.

 

Кто использует RTC у STM32, нормально часы работают?

Просто я в ветке про "LPC1768 и RTC" наткнулся на фразу

Означает, что RTC в первых ревизиях уходят более чем на 1с. за сутки на краях рабочих температур.

Т.е. 1с в сутки это много. А у меня на стм32 при комнатной температуре уход часов на неск. секунд в сутки обычное дело.

[IgorKossak 0]

Кто использует RTC у STM32, нормально часы работают?

Замечательно работают. Естественно, какой-то уход всегда будет, но не 1 с в сутки, это точно.

[akimych 0]

Замечательно работают. Естественно, какой-то уход всегда будет, но не 1 с в сутки, это точно.

А какие кварцы используете?

[IgorKossak 0]

А какие кварцы используете?

Да самые, что ни есть, обычные.

NC38 Кварцевый резонатор часовой (32.768 кГц, +/-20 ppm, C=12.5pF, -20 to +60C), корпус цилиндрический d=3mm, h=8.3mm

Теоретически, при +/-20 ppm они могут уходить и больше, чем на секунду в сутки, но на практике получается секунда за трое суток - неделю. Может я везучий?

Ах да, может это важно, я не беру комплектующие на радиорынке, только у проверенных поставщиков.

[akimych 0]

NC38 Кварцевый резонатор часовой (32.768 кГц, +/-20 ppm, C=12.5pF, -20 to +60C), корпус цилиндрический d=3mm, h=8.3mm

Вот интересно, в даташите на стм32 есть фраза

To avoid exceeding the maximum value of C_L1 and C_L2 (15 pF) it is strongly recommended to use a resonator

with a load capacitance C_L< 7 pF. Never use a resonator with a load capacitance of 12.5 pF.

Получается, зря пугают?

 

А кварцы у меня в таком же корпусе, правда вроде бы не NC38, а DT38. Куплены не на рынке, серийное изделие все-таки.

 

 

 

[uu5jkb 0]

Добрый вечер всем.

Поставил себе Keil uVision 4.20, открыл первый попавшийся пример, подключил плату STM32VLDiscovery, прошил, дебаггером погулял, порадовался. Далее пытаюсь написать что-то самостоятельно, и, чтобы не гонять контроллер, пытаюсь дебажить программу симулятором. Для тренировки опять открыл проект из примеров, ничего не поганил в нем. Запускаю дебаггер, в окне дизассемблера указатель на адресе 0х00000000 с командой mov r0, r0. Жму F10, указатель остается на месте, в SP появляется какое-то немыслимое число 0xFFFFFFF8 или около того. Ни на main, ни на Reset Handler указатель не перескакивает, до брейк-пойнтов после нажатия на Run не идет. В окне Command пишут "Error 65. access violation at 0x00000000: no 'read' permission". В MAP Memory разрешаю отладчику делать с этим участком памяти все, ситуацию не спасает. Зашел на сайт Keil, там предложили как один из вариантов писать в Debug Command Window $=0x0800000. После этой команды указатель переходит в начало функции main, но дальше все равно по шагам не идет. Настройки памяти в Options не трогал, начальные адреса нормальные. Расскажите, пожалуйста, где и почему я дурак. Пробовал открывать проекты других контроллеров (LPC, Atmel etc) - дебаггер прекрасно работает

Изменено 28 марта, 2011 пользователем uu5jkb

[akimych 0]

пытаюсь дебажить программу симулятором

Не поддерживает симулятор кейла полноценно серию STM32F100, только ядро.

Выбирайте F101 и симулируйте. Это самый простой способ.

Или можно прописать DLL-ки от F101 в опциях симулятора/отладчика.

 

Сколько уже народу на эти грабли наступило...

 

 

[uu5jkb 0]

Не поддерживает симулятор кейла полноценно серию STM32F100, только ядро.

Выбирайте F101 и симулируйте. Это самый простой способ.

Или можно прописать DLL-ки от F101 в опциях симулятора/отладчика.

 

Сколько уже народу на эти грабли наступило...

 

Большое спасибо, помогло. А как, интересно, сам Keil комментирует такую ситуацию...

Про грабли - это верно, зато не пропустил опыт. Еще раз спасибо

[djafer 0]

Всем привет

 

Хотел сказать что есть такая интересная статья по всем преимуществам STM32 против AVR, Stellaris, LPC :krapula: .

 

http://www.compeljournal.ru/enews/2011/2/3

 

Особенно интересный график под конец! STM32 рулит :disco: !

[KSN 0]

Помогите выйти из 3-х сосен: проц STM32F103RBT6. Программирую порты PA0-PA3 как Floating input. К этим выводам подключены джамперы, которыми устанавливаю "0", либо "1". При включении платы PA0 постоянно "0", после сброса по NRST состояние PA0 определяется джампером.

Уже замучился искать, где ошибся. Какие настройки можно глянуть?

[Danis 0]

Помогите выйти из 3-х сосен: проц STM32F103RBT6. Программирую порты PA0-PA3 как Floating input. К этим выводам подключены джамперы, которыми устанавливаю "0", либо "1". При включении платы PA0 постоянно "0", после сброса по NRST состояние PA0 определяется джампером.

Уже замучился искать, где ошибся. Какие настройки можно глянуть?

 

Выложите свой исходник инициализации порта, гляну.

[JJK 0]

Парочка хинтов.

Некоторое время назад пришлось поработать с STM32 с многими используемым замечательным скриптом stm32loader.py. Если в компьютере есть последовательный порт, скрипт замечательно с ним работает. Но компьютеры с таким портом уже давно редкость, приходится использовать USB-переходники (FTDI, Prolific). При использовании их заливка прошивки идёт раза в два медленнее. Дело в том, что скрипт высылает данные побайтно, а драйвер для каждого байта отправляет по USB целый блок и получает подтверждение. Оверхед налицо!

Проблема лечится в методе cmdWriteMemory: собираем весь блок (до 256 байт) данных в стринг, затем вываливаем его драйверу одним махом. Вот так:

    def cmdWriteMemory(self, addr, data):
       assert(len(data) <= 256)
       strwr = '' #Data will be collected to this bytestring
       if self.cmdGeneric(0x31):
           mdebug(10, "*** Write memory command")
           self.sp.write(self._encode_addr(addr))
           self._wait_for_ask("0x31 address failed")
           #map(lambda c: hex(ord( c )), data)
           lng = (len(data)-1) & 0xFF
           mdebug(10, "    %s bytes to write" % [lng+1]);
           strwr += chr(lng)
           crc = 0xFF
           for c in data:
               crc = crc ^ c
               strwr += chr( c )
           strwr += chr(crc)
self.sp.write(strwr) #Write the whole collected bytestring
           self._wait_for_ask("0x31 programming failed")
           mdebug(10, "    Write memory done")
       else:
           raise CmdException("Write memory (0x31) failed")

И ещё одна проблема наблюдалась. Скрипт открывает файл не используя бинарный режим явно, что под Windows иногда приводит к заливке прошивки неполностью.

Лечится в мэйне:

        if (conf['write'] or conf['verify']):
           data = map(lambda c: ord( c ), file(args[0], 'rb').read())
           print 'File', args[0], ':', len(data), 'bytes'

Также порекомендую в конце скрипта включить команду на запуск программы, чтобы она сразу начинала работать без необходимости вручную выключать режим бутлодера и делать сброс:

        cmd.cmdGo(0x08000000)
   finally:
       cmd.releaseChip()

[KSN 0]

Выложите свой исходник инициализации порта, гляну.

Решил проблему. После инициализации портов перед операцией чтения вставил небольшую задержку. Спасибо за предложение помощи.

[Mos 0]

Интересная проблемка с реализацией USB CDC на STM32F103 и usbser.sys (WinXP).

Был взят пример Usb Virtual Serial Port и переделан по-людски, версия Usb - библиотеки: STM32 USB-FS-Device Driver 3.2.1;

Режим работы таков: после подключения и инициализации, хост передаёт девайсу некоторый объём данных (~1 Кб) для инициализации; в процессе работы хост практически всегда молчит.

Девайс непрерывно передаёт хосту данные (накопленные в FIFO) со скоростью 100 Кб/с. Если на момент опроса у девайса нет данных для передачи, то он отвечает ZLP.

 

Всё работает просто чудно!

 

Но почему-то через примерно 300, либо примерно 980, либо примерно 1800 секунд на девайсе перестаёт вызываться Callback на TX :(

 

Вероятность ошибки в "пользовательском" коде невелика (ибо он очень прост). Подозрение падает на usbser.sys

 

Вот.