Изучаем STM32 Cortex M3

[TAutomatic]

TAutomatic, SasaVitebsk, Может все намного проще ????

А как проще? У меня нет прямой связи с ST, может Вы располагаете некой служебной информацией от ST, чего нет в открытом доступе.
Я согласен с SasaVitebsk, но только в общем плане. Идет усложнение контроллеров, усложняется периферия.
Но в моем представлении, по умолчанию, вариант самой примитивной работы должен быть реализован "на шелчек пальца".
У меня проста память EEPROM подключена к контроллеру. Никакой "шины", тем более мультимастерности нет. И что? Процедура, портированная с ПИКа не работает. Предлагается использовать DMA или прерывания. Вопрос - нахрена? Зачем так усложнять? У меня SPI, UART и АЦП заботают через ПДП. Там сам Бог велел. Нахрена к I2C прикрутили ПДП? Ну может комуто- и нужен. В моем случае - нет, ну разве что для записи блока, настроил, запустил процесс и пошел дальше работать. Для чтения точно не нужно, мне нужны данные именно в тот момент, когда я начинаю процесс, ждать все равно приходится.
И что бы все работало, в еррате мне предлагается делать все через ПДП, как собственно и в библиотеках. Которые размер имеют больше, чем вся остальная программа. Кому это нужно?

[DanilinSA]

Сдался Вам этот ПДП ... Всё прекрасно работает и без него. До момента, пока отладите обмен с переферией о нем да-же не вспоминайте. И только потом, если возникнет нужна разгрузить работу проца можно и ПДП прикрутить.
На самом деле ничего сложного в работе I2C контроллера нет. Он конечно интересный, с кучей режимов и аппаратным обнаружением коллизий - но ничего сверхестественного там нет.
Берите кофе поболее, отключайте телефон, и аккуратно, по строчке, неторопливо вникаем в мануал. Сначало будет тяжело. Потом - всё станет очевидно ...

Первым делом - смотри "детские" ошибки. Какие блоки включены, тактирование. GPIO на работту правильно настроено?

Если всё совсем плохо - займись простейшим "дрыгоножеством". Программой перебрасывать состояние ноги и простейшая задержка в пустом цикле.

В конче концов можно Discavery прицепить как SW отсладчик и посмотреть, где стоим и чего ждем ... Или пошагово пройтись.

По личному опыту - система I2C ловит клина при неверно описанном протоколе. Т.е. МП ждет ответа от устройства, а устройство считает что ничего не должно передавать ...
Аппаратный I2C конечно подымет флаг ошибки, но кто его смотрит ...

Пару раз было: описание обмена чипа с I2C невнятное. Вроде должен на запрос ответить. Посылаешь запрос, ждем ответ ... ждем ... ждем ... МК естественно висит, ожидая данных.
А далее чесание головы (уже плешь намечается) и документации. Пытаешся понять, как запрос сформировать и данные получить.

[dosikus]

На самом деле ничего сложного в работе I2C контроллера нет.

О чем и толкую...
Может пора уже забыть периферию PicMicro и тем более AVR?
Изучить даташит, а если не поможет и в SPL заглянуть на предмет реализации и что они там (какие события) ловят ...

[Boba_spb]

Еще не помешает сам интерфейс I²C посмотерть, что б пониамть кто, когда и для чего устанавливает ACK и держит в low SCL.

[TAutomatic]

Мужики, ну ей Богу. Я не понимаю, Вам интересно истроить что-то типа пресс-конференции по поводу устройства протокола I2C?
Или в свете новых абстоятельств подчеркнуть "новый уровень значимости" протокола I2C?
Да не стоит он того, да и не должен он задавать таких хлопот. Забывать или нет ПИКи или АВры - разве тут дело?
Первый мой реализованный программый протокол был еще в далеком 1996 на 1816ВЕ31. Затем программный на Pic16F84. Птом аппаратные на всех сериях от 18 до 24серии.
После этого уважаемый DanilinSA предлагает мне тщательно вкуривать доку и "дрыгать" ногами.
Не, ну совет конечно уместный, когда понимаешь, что то, что знаешь как облупленное уже почти 15 лет, перестает работать.
Вопрос в другом, почему? Ну чего так разработчики перемудрили? Ну какие там события -то ловить при работе с одной внешней епромкой, ну не смешите? Оно должно работать и без всякой ловли.
Остается, видимо, очередной раз реализовать программный протокол, домучать проект и забыть о нем.
Смысл мне было переводить готовый проект на ПИКе на АРМ? Думал в стоимости контроллера выйграю. Программа, занимающая 14 кБ памяти ПИка, да и к тому же работающая на 80 МГц портировалась в программу 27 кБ, тоесть уже не влез в минимальную стоимость. С учетом отсутствия возможности одновременной выборки данных по 4 каналам АЦП как ПИКа без необходимости компенсации фазового сдвига программа еще подрастет. Сюда еще проблемы с I2C, еще кое-какие вещи. Короче, оно того не стоит видимо. Не стоило и браться. ПИК не на много оказался дороже. Еще не понятно во что выльются при эксплуатации эти косяки в работе STM32.

[Wiza_]

Программа, занимающая 14 кБ памяти ПИка, да и к тому же работающая на 80 МГц портировалась в программу 27 кБ, тоесть уже не влез в минимальную стоимость.

Так вы хоть архитектуры сравните:
8/16 бит против 32: ясен пень что программа вырастет
80 мгц пика - это по прежнему 20 mips max + его урезанный ассемблер, cortex побыстрее соображает на тех же 80 мгц.

Без сомнения, что на пики примеров на данный момент больше, но со временем всё изменится до полностью наоборот. У STM документация правда весьма паршивая - так что приходится пока ходить на костылях по граблям.

[TAutomatic]

Так вы хоть архитектуры сравните:
8/16 бит против 32: ясен пень что программа вырастет
80 мгц пика - это по прежнему 20 mips max + его урезанный ассемблер, cortex побыстрее соображает на тех же 80 мгц.

Ну что же Вы так неподумав....
Вы у меня не спросили, какую систему команд я использую для АРМ, с какого ПИка портирую код... И вот так запросто в двух словах сравнили и сделали определенный вывод.... К тому же решили, что я не разбираюсь в разрядности контроллеров, которые использую.
Тогда уточню, что бы уже Вы сравнили.
Портирую код с PIC24HJ32GP - это не 20 MIPS, как Вы считаете запросто, а 40. Уже раз...
Второе, я использую 16 набор команд. А Вы используете для STM32F100 набор АРМ?
Что тогда Вы сравниваете? Процесс распаковки 16 битовых команд в 32 битовые не занимает времени? И это на 24МГцах? Что Вы сравниваете? 32 разрядный аккумулятор и все?
Пока есть две вещи, которые я смог сравнить. Фильтр БИХ 5 порядка на STM32F100 выполняется гораздо медленнее чем на ПИК24, не говоря уже об дсПИК. Второй момент, у меня очень много вычислений с плавающей точкой и очень маленькими числами. У ПИКа doble 4-х байтовый меня вполне устраивает по точности на несколько миллионов операций. У АРМа float - это вообще полное гов.. о, в 8 байтовый double кое-как обеспечивает заданную точность... Можете посмотреть как оперирует АРМ и с тем и с тем типом данных и сравнить.
Да и еще в добавок I2C кривой...
Вот это мое сравнение...

[TAutomatic]

Без сомнения, что на пики примеров на данный момент больше, но со временем всё изменится до полностью наоборот. У STM документация правда весьма паршивая - так что приходится пока ходить на костылях по граблям.

Впрочем, в этой ветке сравнения STM32 с другими камнями - оффтоп. Не будем продолжать в эту сторону.
Вопрос в другом:
почему стандартная последовательность:
СТАРТ
Адрес устройства с битом направления передачи на запись
Адрес ячейки
Рестарт
Адрес устройства с битом направления передачи на чтение
Чтение в цикле байт с выдачей подтверждения кроме последнего байта
Чтение последнего байта без подтверждения
СТОП
в которой практически исключены какие-то ошибки - не работает просто и надежно.
Это баг контроллера?

[Boba_spb]

У stm32f4 FPU на борту и 168 МГц вот с этим сравнить бы.

[SasaVitebsk]

Второе, я использую 16 набор команд. А Вы используете для STM32F100 набор АРМ?

Расшифруйте. Может я не в теме. stm32f1xx это cortex-m3. И система команд у него одна. Выбрать там ничего нельзя.

Что тогда Вы сравниваете? Процесс распаковки 16 битовых команд в 32 битовые не занимает времени?

Нет.

И это на 24МГцах? Что Вы сравниваете? 32 разрядный аккумулятор и все?

Там все регистры 32 разряда. И часть комманд. Например 32*32 = 32, будет выполненоза 1 такт. Оценочная производительность 1.2 DMips/ 1МГц.

Пока есть две вещи, которые я смог сравнить. Фильтр БИХ 5 порядка на STM32F100 выполняется гораздо медленнее чем на ПИК24, не говоря уже об дсПИК.

К сожалению не работал с ПИК24. Верится с большим трудом. А как фильтр реализован? В целочисленных операциях или на плавучке? Если только соптимизирован непосредственно под ПИК, а вы перенесли. Соптимизируйте под ARM.

Второй момент, у меня очень много вычислений с плавающей точкой и очень маленькими числами. У ПИКа doble 4-х байтовый меня вполне устраивает по точности на несколько миллионов операций. У АРМа float - это вообще полное гов.. о, в 8 байтовый double кое-как обеспечивает заданную точность... Можете посмотреть как оперирует АРМ и с тем и с тем типом данных и сравнить.
Да и еще в добавок I2C кривой...
Вот это мое сравнение...

Ну не передёргивайте. Урезанный нестандартный double 4 байтный вас устраивает, а стандартный 8-ми байтный double "кое как обеспечивает". Кроме того, с вашим 4double ПИК работает не аппаратно. И что мешает использовать библиотеку плавучки для него? Работайте с этим типом также на ARMе? Ну и напоследок, не в плане устраивания войн. Просто для себя почитайте errata на свой ПИК. Давно с ними не работал, но когда работал там были даже ошибки ядра!!!! Причём неединичные. То есть ошибки, возникающие при исполнении комманд. Ошибок интерфейсов просто вагон от ревизии к ревизии. Контроллер CAN самый ущербный из всех мной опробованных. Были, по-моему претензии и к I2C. В частности проблемы сна и паразитное питание, но утверждать не стану. Идеальный I2C только у NXP.
Понятно, что вам комфортно было работать на ПИК. Вы к нему привыкли. Но страшного ничего нет. Поработайте на STM подольше. Вам понравится я думаю. Первые прикидки ошибочны. Поверьте.