Легкий старт для STM32 проекта, Графический конструктор проектов Опции

[Tarbal]

Вот программы для семинара ST.

Апликация STM32Cube и лабораторные работы с инструкциями как пользоваться.
https://www.dropbox.com/sh/eqim95c9s2sspqn/...8vSdRW4P3a?dl=0

За час можно склепать простой проект, а потом использовать сгенерированный код для развития проекта. Лицензию на IAR IDE дадут на короткое время, но если выбрат' при генерации проекта toolchain SW4STM32, то можно обойтись бесплатными инструментами.

Из платных поддерживаются:
EWARM
MDK-ARM V4
MDK-ARM V5
TrueStudio

[Tarbal]

Видео инструкции:

https://www.youtube.com/watch?v=PqsgSVbgfBs

[Огурцов]

под кокос видео сделайте, pls

[Tarbal]

под кокос видео сделайте, pls

Это не мое видео Сам только начал. Изучаю и делюсь.

[Velund]

За час можно склепать простой проект, а потом использовать сгенерированный код для развития проекта.

За полдня удалось поднять "фундамент" для простенького проекта на STM32F103C8T6, но потом все наглухо уперлось в нестабильную работу I2C1... То работает, то глухо HAL (polling mode) подвисает на 10 секунд при любой операции с шиной и вываливает потом ошибку HAL_TIMEOUT. На шине пока всего один EEPROM.. Вот и в раздумьях я, а оно вообще у Cube работоспособно?

[Огурцов]

Этого ни кто не знает, так глубоко там все упрятано - лучше spl
Кстати i2c у 103, говорят, не работает

Сообщение отредактировал Огурцов - Dec 28 2015, 13:15

[Velund]

Этого ни кто не знает, так глубоко там все упрятано - лучше spl
Кстати i2c у 103, говорят, не работает

Почитал Errata... Похоже нашел "мой" случай. "Порадовался"...

2.13.7 I2C analog filter may provide wrong value, locking BUSY flag and preventing master mode entry

Description
The I2C analog filters embedded in the I2C I/Os may be tied to low level, whereas SCL and SDA lines are kept at high level. This can occur after an MCU power-on reset, or during ESD stress. Consequently, the I2C BUSY flag is set, and the I2C cannot enter master mode (START condition cannot be sent). The I2C BUSY flag cannot be cleared by the SWRST control bit, nor by a peripheral or a system reset. BUSY bit is cleared under reset, but it is set high again as soon as the reset is released, because the analog filter output is still at low level. This issue occurs randomly.

Воркараунд предложен но какой то сильно заморочанный.

А насчет отказа от I2c - сложновато это. В планах были на шине EEPROM для калибровок, плюс 16-битный ADC и пара экстендеров вынесенных на другую плату с ВЧ делами. Тянуть туда SPI нереально.

[Огурцов]

Так как раз это обсуждаем - поставьте там ещё камень и общайтесь по uart

[ANT]

За полдня удалось поднять "фундамент" для простенького проекта на STM32F103C8T6, но потом все наглухо уперлось в нестабильную работу I2C1... То работает, то глухо HAL (polling mode) подвисает на 10 секунд при любой операции с шиной и вываливает потом ошибку HAL_TIMEOUT. На шине пока всего один EEPROM.. Вот и в раздумьях я, а оно вообще у Cube работоспособно?

Я довольно долго бился с их примером HAL I2C. В итоге всё стало работать стабильно после понижения частоты до 80 кГц. Кроме того, читаю и пишу кусками не менее 4 байт. Не разобрался, почему при меньших кусках возникают упомянутые Вами подвисания .

[Velund]

Я довольно долго бился с их примером HAL I2C. В итоге всё стало работать стабильно после понижения частоты до 80 кГц. Кроме того, читаю и пишу кусками не менее 4 байт. Не разобрался, почему при меньших кусках возникают упомянутые Вами подвисания .

Это видимо не тот случай (еще один баг, другой). У меня при некоторых включениях I2C вообще не запускается. Вываливается в постоянное ожидание флага готовности I2C при первом же обращении к функциям HAL. Но если запустился - работает.

[Ruslan1]

А я опять повторю, что не видел еще ни одного МК со стабильным аппаратным I2C.
Для редкой и медленной работы (при включении чего прочитать-записать или еще когда), пригоден софтовый вариант- работает годами и не зависает и еррат не имеет. Еще софтовый вариант хорош тем, что к ногам не привязан, на любых двух удобных(свободных) пинах может быть сделан.

[Aleksandr Barano...]

Тянуть туда SPI нереально.

Я думаю, речь шла не об SPI, а об SPL

[Огурцов]

софтовый

А они ещё и дма обещают - вообще не понимаю как

[mantech]

пригоден софтовый вариант- работает годами и не зависает и еррат не имеет. Еще софтовый вариант хорош тем, что к ногам не привязан, на любых двух удобных(свободных) пинах может быть сделан.

Полностью согласен, софтовый имеет больше приимуществ, заметил это еще с аврок, где код инициализации и приема-передачи аппаратного был больше, чем мой, софтовый

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

А они ещё и дма обещают - вообще не понимаю как

Только в случае линейной передачи с автоинкрементом.

[Velund]

Так как раз это обсуждаем - поставьте там ещё камень и общайтесь по uart

Там уже ничего не поставить. Этот ВЧ модуль уже существует и кроме I2C вариантов нет. Сейчас думаю что правильнее - забить на STM32 и поставить "обкатанный" LPC1758 или все же сделать bit banging... Первое очень избыточно. Второе как то расточительно в смысле времени процессора.

[Огурцов]

поставьте здесь, хоть мегу в ногодрыге

[murmur]

Это видимо не тот случай (еще один баг, другой). У меня при некоторых включениях I2C вообще не запускается. Вываливается в постоянное ожидание флага готовности I2C при первом же обращении к функциям HAL. Но если запустился - работает.

Стесняюсь спросить - резисторы подтягивающие на линиях есть?

[Velund]

Стесняюсь спросить - резисторы подтягивающие на линиях есть?

Не первый день замужем.
Логический анализатор (Zeroplus LAP-C) подцеплен к шине - нет никаких глитчей при рестарте, стабильно в единице и SCL и SDA. Посмотрел осциллографом уровень (думал просаживает что то) - нет, 3.3 вольта есть, как положено.

[scifi]

Не первый день замужем.

Было бы так - не стали бы с кубами водиться

[ViKo]

Обращаюсь ко всем, у кого не работает аппаратный I2C. Вы прочитали руководство, документацию по ошибкам, настроили все регистры, и - не работает?? Шайтан помешал?

[Эдди]

Вы прочитали руководство, документацию по ошибкам, настроили все регистры, и - не работает?

Ардуринщики мануалы не читают. Они "скетчи" в интернете ищут.
О каком руководстве можно спрашивать в теме о всякой гадости вроде HAL/SPL/Qube?

[Velund]

Было бы так - не стали бы с кубами водиться

Ну так подвернулся хороший случай на практике попробовать, так ли уж губительны эти диавольские искушения. Получить проект с мигающим светодиодом и (на первый взгляд) рабочим USB CDC за время меньшее, чем обычно уходило на то, чтобы только разобраться по мануалам какие GPIO куда расписать.

Надо признать, что пока если что и приведет к фиаско, то не куб, а банальная глючность конкретного камня. К чести ST расписанная в errata (до чтения которой дошло только после того как грабли сделали свое черное дело).

[Ruslan1]

К чести ST расписанная в errata (до чтения которой дошло только после того как грабли сделали свое черное дело).

Ну, это у Вас еще везуха сплошная, если уже что-то спроектировано-смонтировано и как-то работает, а в еррату еще и не заглядывали.
Я обычно еррату читаю раньше чем основную документацию, на этапе выбора МК под задачу. Бывает, ее чтение переворачивает все с ног на голову.

[Alechek]

Куб хорош для понимания, в чем накосячил при написании собственной работы с периферией.

Я, к примеру, долго не понимал, почему у меня не работает SPI - не принимает данные и все тут. В кубе работает, а в моем проекте - нет.
Оказалось, SCK обязательно должен быть выведен на ногу. Хоть мне он и не нужен (эмуляция 1-wire).

Без куба я бы от пары дней до недели потратил на понимание, почему не работает (и, возможно, не один камень). Ведь в документации этого обязательного условия я нигде не нашел.
С кубом хватило пол дня.

[Velund]

Ну, это у Вас еще везуха сплошная, если уже что-то спроектировано-смонтировано и как-то работает, а в еррату еще и не заглядывали.
Я обычно еррату читаю раньше чем основную документацию, на этапе выбора МК под задачу. Бывает, ее чтение переворачивает все с ног на голову.

Так тут особый случай. Поделка штучная, под рукой был модуль китайский, хорошо встающий в макетку - и решил посмотреть, как оно пойдет, если к вопросу подойти "с другой стороны".

Если честно - то это вообще первый в жизни STM32 с которым я связался. До этого были игрища с NXP/Freescale/TI а до серии из 32-битников доходили только NXP.

[Огурцов]

Куб хорош

куб убивает spl , а кубовские исходники никто не выкладывает, ибо и так никому не нужны

[jcxz]

А я опять повторю, что не видел еще ни одного МК со стабильным аппаратным I2C.

LPC1758/LPC1778/LPC1788/OMAP-L137/....

[Огурцов]

я вот тут подумал - для сабжа нужен какой-то метакуб, hal, но независимый от платформ, производителей и языков программирования

[Velund]

LPC1758

Присоединюсь... На 1758 и 1768 тысячи изделий "в поле", I2C используется интенсивно (расширители и I2C слейвы на базе пиков 16-х) - проблем нет. Правда там и не кубоподобное на низком уровне, а честно выстраданное бессонными ночами.

PS: Упоминавшийся на прошлой странице воркараунд из STшной Errata помог. Ровно на 2 минуты помог. Крутилось в цикле тупо вычитывая здоровый кусок EEPROM в буфер, и встало опять, в то же состояние с 10-сек таймаутом и возвратом с кодом HAL_BUSY.

[Alechek]

я вот тут подумал - для сабжа нужен какой-то метакуб, hal, но независимый от платформ, производителей и языков программирования

Изучая сякие SPL и HAL к сабжу, и собственно, сабжи, пришел к выводу, что использовать из них можно только заголовочники (.h). И то с наятгом.
Так как никакой универсальности в плане работы с периферией они не несут. Так, к примеру, у 32F1 и 32F0 разная по возможностям периферия.
Тот же USART, SPI. И, написав код под F0, на F1 его запустить уже не получится. И HALы с КУБами никак не помогут.

[Ruslan1]

LPC1758/LPC1778/LPC1788/OMAP-L137/....

удивил OMAP: вообще в еррате нет упоминания I2C. Или это чудо или пациента просто еще недообследовали (ревизия документа-2011 год)
для LPC - упомянута только одна ошибка в реализации I2C, вроде бы обходится без особых танцев с бубном, так что тоже годится.
спасибо, буду знать.

[scifi]

я вот тут подумал - для сабжа нужен какой-то метакуб, hal, но независимый от платформ, производителей и языков программирования

И там будут свои метаглюки. Независимые ни от чего

[ViKo]

Гиперкуб

Я этот куб даже обновить нормально не могу. Лучше новую версию скачать и переустановить.

[Огурцов]

метакуб круче, чем гипер, ибо абстрагирует все от всего

[jcxz]

удивил OMAP: вообще в еррате нет упоминания I2C. Или это чудо или пациента просто еще недообследовали (ревизия документа-2011 год)
для LPC - упомянута только одна ошибка в реализации I2C, вроде бы обходится без особых танцев с бубном, так что тоже годится.
спасибо, буду знать.

Может и недообследовали, но у меня на OMAP на I2C висит FRAM, в которую непрерывно пишутся логи работы, так что обмен довольно интенсивный и никаких проблем в его работе я не заметил.
Для LPC еррату не смотрел, так как на баги вроде не наступал (хотя может и наступил, но не понял что это баг). В любом случае на LPC1758 и LPC1788 у нас тоже наверное уже тысячи устройств у заказчиков работают в режиме 24часа и если-б там были проблемы, мне бы уже плешь насквозь проели . :-)

[Velund]

Изучая сякие SPL и HAL к сабжу, и собственно, сабжи, пришел к выводу, что использовать из них можно только заголовочники (.h). И то с наятгом.
Так как никакой универсальности в плане работы с периферией они не несут. Так, к примеру, у 32F1 и 32F0 разная по возможностям периферия.
Тот же USART, SPI. И, написав код под F0, на F1 его запустить уже не получится. И HALы с КУБами никак не помогут.

После игрищ с кубом все прошлые выходные я для себя сделал заключение, что несомненно полезная вещь в нем - "графический редактор GPIO", который сам подсказывает где могут быть какие сигналы и что блокируешь каждым конкретным выбором из доступной периферии. Сильно ускоряет процесс, и автоматом делает удобоваримую документацию по назначению сигналов на пины. Последний раз полностью "распихать" ноги у LPC1768 и сделать в экселе табличку с сигналами и режимами для инициализации у меня заняло почти сутки (но там реально загружалось почти все что возможно по максимуму, два пина из сотни остались не у дел). Опять же код инициализации GPIO упрощает жизнь.

I2C у STM32F103C8 я для себя списал в утиль по результатам. Условно считаем что его нет, потому как бубна в комплекте с чипом не дают, а свой приносить для камлания вокруг их I2C модуля - много чести. SPI работает вроде устойчиво с кубовским драйвером. Поделка ради которой я решил попробовать STM32 и куб уже задышала на LPC1758. Но я слегка "подточил" свои библиотечки для LPC чтобы приблизить форматы передачи параметров к кубовским и без больших правок использовать код который накропал за время игрищ с кубом, вреда от этого никакого а польза когда то может быть.

[Quasar]

Обращаюсь ко всем, у кого не работает аппаратный I2C. Вы прочитали руководство, документацию по ошибкам, настроили все регистры, и - не работает?? Шайтан помешал?

Как тут уже писалось, аппаратные I2C модули во многих популярных МК настолько убоги, что проще использовать свою софтовую реализацию этого простого протокола. Ну правда, чтение документации, изучние erratы, написание кода - займет больше времени, чем написание кода софтового I2C (у бывалых людей он уже давно написан и кочует из поекта в проект, плюс он не привязан к ножкам) :-)

[Tarbal]

(у бывалых людей он уже давно написан и кочует из поекта в проект, плюс он не привязан к ножкам) :-)

Точно!!!!!

[jcxz]

Как тут уже писалось, аппаратные I2C модули во многих популярных МК настолько убоги, что проще использовать свою софтовую реализацию этого простого протокола. Ну правда, чтение документации, изучние erratы, написание кода - займет больше времени, чем написание кода софтового I2C (у бывалых людей он уже давно написан и кочует из поекта в проект, плюс он не привязан к ножкам) :-)

Это программная эмуляция имеющейся в МК периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и иже с ними.
400кГц (обычная частота для I2C) даст 800кГц прерываний! Это угробит производительность даже самого жирного МК на бессмысленное дёрганье ножками.
А ведь бывает нужно на несколько разных интерфейсов I2C повесить устройства. Вот тут и появляются чудо-проекты, когда МК с несколько сот МГц тактовой едва хватает для опроса пары датчиков.
Видно все Ваши задачи заключаются в моргании несколькими лампочками, тогда да - чем ещё загружать CPU?

[Огурцов]

именно для этого и нужен десяток ядер в каждом камне

[jcxz]

именно для этого и нужен десяток ядер в каждом камне

Точно! Даёшь каждому I2C-девайсу по ядру!

[scifi]

Это программная эмуляция имеющейся периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и подобных.
400кГц (обычная частота для I2C) даст 800кГц прерываний! Это угробит производительность даже самого жирного МК на бессмысленное дёрганье ножками.

Очень часто нужно изредка что-то там поделать с I2C. Подождать 20 мкс - не проблема.
А если интенсивный обмен, то прерывание на каждый байт - тоже не сахар.

[mantech]

Это программная эмуляция имеющейся в МК периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и иже с ними.
400кГц (обычная частота для I2C) даст 800кГц прерываний! Это угробит производительность даже самого жирного МК на бессмысленное дёрганье ножками.

Никогда не использовал прерывания для i2c. По-моему это бред полный, ибо интерфейс синхронизируемый самим контроллером, можно делать обычные delay().

ЗЫ. Это я про мастер режим, разумеется, слейв - тут только аппаратный блок, придется изучать все ераты и пр.. К счастью, пока нужды в нем не было

[Огурцов]

Точно! Даёшь каждому I2C-девайсу по ядру!

и автоматом решается вопрос с маппингом и ерратами
10 уартов или 10 езернетов - пожалуйста

[jcxz]

Никогда не использовал прерывания для i2c. По-моему это бред полный, ибо интерфейс синхронизируемый самим контроллером, можно делать обычные delay().

Обычные delay() допустимы только для однозадачной среды, в многозадачной среде они убъют все задачи приоритетом ниже той, в которой работает такой драйвер.
В нормально реализованном драйвере, работающем с аппаратной периферией, как раз наоборот - обмен по интерфейсам (с использованием прерываний и DMA) освобождает процессор для менее приоритетных задач
(в которых кстати тоже может идти обмен по другому интерфейсу, времянки которого не будут сбиваться более приоритетными задачами).
Опять приходим к тому, что в более-менее сложном ПО будет скорей всего многозадачная среда, а однозадачная среда - что-то простое типа моргания лампочками.

[SpyBot]

Обычные delay() допустимы только для однозадачной среды

В многозадачной среде есть необычные delay(), которые в момент отдыха данной задачи отдают управление менее приоритетной задаче.

[Quasar]

Это программная эмуляция имеющейся в МК периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и иже с ними.
400кГц (обычная частота для I2C) даст 800кГц прерываний! Это угробит производительность даже самого жирного МК на бессмысленное дёрганье ножками.
А ведь бывает нужно на несколько разных интерфейсов I2C повесить устройства. Вот тут и появляются чудо-проекты, когда МК с несколько сот МГц тактовой едва хватает для опроса пары датчиков.
Видно все Ваши задачи заключаются в моргании несколькими лампочками, тогда да - чем ещё загружать CPU?

I2C не сильно-то нагруженный интерфейс, чаще всего, пару байт переслать раз в минуту/час. Это не SPI/I2S/Ethernet/CAN, которые чаще всего загружены "по полной".

[jcxz]

В многозадачной среде есть необычные delay(), которые в момент отдыха данной задачи отдают управление менее приоритетной задаче.

Такие delay задают задержку в количестве тактов таймера планировщика задач, который имеет частоты обычно не более единиц кГц. I2C на такой задержке будет ну очень медленный.

[mantech]

Такие delay задают задержку в количестве тактов таймера планировщика задач, который имеет частоты обычно не более единиц кГц. I2C на такой задержке будет ну очень медленный.

У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется

[jcxz]

У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется

А Вы откуда знаете?
Мы в некоторых изделиях используем матричные ЖКИ висящие на I2C. А также FRAM-память на I2C размером в 32кБ.
В других изделиях есть ADE78xx работающая по I2C непрерывным потоком на макс. скорости.
Если Вы думаете, что I2C используется только для передачи пары байт и никаких других применений нет, то зачем в новых МК ввели I2C с SCL до 1МГц?

PS: Имхо - тактировать шедулер 10кГц можно конечно, но по-моему многовато - много накладных расходов на переключение задач. У меня обычно максимум 1кГц или меньше.

[Alechek]

У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется

Кхе.... Весьма жирновато.
Еще для FreeRTOS с ARM LPC2148 48Мгц прикниул, что сохранение-переключение-востановление контекста в прерывании занимает 2.2 мкс
А тут период планировщика 100 мкс, то есть в этом случае 2.2% времени процессора будет тратиться на переключение контекста.

10 уартов или 10 езернетов - пожалуйста

Тогда по паре таймеров на ядро еще бы.

[Quasar]

А Вы откуда знаете?
Мы в некоторых изделиях используем матричные ЖКИ висящие на I2C. А также FRAM-память на I2C размером в 32кБ.
В других изделиях есть ADE78xx работающая по I2C непрерывным потоком на макс. скорости.
Если Вы думаете, что I2C используется только для передачи пары байт и никаких других применений нет, то зачем в новых МК ввели I2C с SCL до 1МГц?

Ну это ВЫ так используете, но в массе своей, практика показывает, что высоконагруженное I2C это экзотика, так же как и I2C в слейве со стороны МК. Никто же не спорит, что это не нужно или нереально, просто речь идет о том, что I2C в 99% случаев, для эмбеддера это мастер с небольшим объемом данных, и все эти мегагерцы на SCL и аппаратный I2C - просто не нужны.

[scifi]

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

Вы не представляете, как много всякого разного и вполне многозадачного можно сделать в рамках схемы Super Loop.

[mantech]

Ну это ВЫ так используете, но в массе своей, практика показывает, что высоконагруженное I2C это экзотика, так же как и I2C в слейве со стороны МК. Никто же не спорит, что это не нужно или нереально, просто речь идет о том, что I2C в 99% случаев, для эмбеддера это мастер с небольшим объемом данных, и все эти мегагерцы на SCL и аппаратный I2C - просто не нужны.

Все верно, даже добавить нечего, ибо эта шина создавалась именно для конфигурирования и управления блоками телерадиоаппаратуры фирмы филипс. А использовать жк экраны или другие высокоскоростные стриминговые устройства считаю нерациональным, ибо почти все они есть на более скоростном SPI, с которым работать куда приятнее.
ЗЫ. А так, если принципиально "упираться", можно и на 1wire дисплей повесить, но нужно-ли?

[Огурцов]

Тогда по паре таймеров на ядро еще бы.

хоть по десять
я ведь не против, если ядер будет 16
или 256
только учтите, что одно ядро тянет одну нить
а значит один цикл, и один таймер, но общий
а если в цикле инкрементировать две переменных, тогда разрешение будет поменьше

Сообщение отредактировал Огурцов - Jan 12 2016, 08:51

[mantech]

я ведь не против, если ядер будет 16

Да уже и есть наверно, только программирование линукс-онли, поэтому - обламингос

[Огурцов]

какой линукс, речь про что-то типа 2313, только лишь штук 256 в одном соике и на гигагерц тактовой

[mantech]

какой линукс, речь про что-то типа 2313, только лишь штук 256 в одном соике и на гигагерц тактовой

Ооо да!! Даже не представляю, как бы все это называлось

Хотя да, берете плисину на стопятьсот лог. вентилей и втюхиваете туда свои кучи ядер... Тут главное критическую массу не набрать, а то мало-ли что...

[Огурцов]

за доллар ? давайте

вообще, зря смеетесь, алу на кристалле занимает очень мало места в сравнении с флешем или рамой
так что ядер может очень много за счет уполовинивания памяти

кстати интересная фича про перывания - как в с# - несколько ядер могут подписаться на одно прерывание

Сообщение отредактировал Огурцов - Jan 12 2016, 22:00

[SasaVitebsk]

Как тут уже писалось, аппаратные I2C модули во многих популярных МК настолько убоги, что проще использовать свою софтовую реализацию этого простого протокола. Ну правда, чтение документации, изучние erratы, написание кода - займет больше времени, чем написание кода софтового I2C (у бывалых людей он уже давно написан и кочует из поекта в проект, плюс он не привязан к ножкам) :-)

Ну, скажем, программный там и писать нечего. 5 строчек... )) И действительно лениво ... ))
Честно сказать в последнем проекте (stm32f407) так и есть. У меня там клава по I2C подключена. Она реализована на stm8 (slave). Казалось бы написать мастера - 2 пальца об асфальт. Ну у меня там специфика - хотел без прерываний сделать... На начальном этапе включил софтовый драйвер. Когда уже проект закончил - решил подключить аппаратный. Написал первоначальный вариант - виснет иногда. Перечитал всё - написал все возможные обработчики ошибок - виснет гораздо реже. Настолько редко, что выловить причину не смог. Плюнул - оставил софтовый.

А в LPC1764/65 действительно прекрасно работает. Да и на старом LPC2106 тоже не припомню проблем. На stm32f103 slave удалось нормально сделать. Через прерывания. Оно и на 407 наверное можно... просто жалко времени... ))

[mantech]

На stm32f103 slave удалось нормально сделать. Через прерывания. Оно и на 407 наверное можно... просто жалко времени... ))

Дак ясно дело жалко, причем клаву можно на низкой скорости запустить, куда там спешить-то?

[jcxz]

Все верно, даже добавить нечего, ибо эта шина создавалась именно для конфигурирования и управления блоками телерадиоаппаратуры фирмы филипс. А использовать жк экраны или другие высокоскоростные стриминговые устройства считаю нерациональным, ибо почти все они есть на более скоростном SPI, с которым работать куда приятнее.

Вобще-то "использует" её производитель, применив именно такую, а не иную шину в своей микросхеме. Не знаю для кого она создавалась, но факт - это наличие микросхем именно с этой шиной.
И если в устройстве нужна например FRAM и внешние часы RTC, то выгоднее поставить одну микросхему содержащую в себе FRAM+RTC, чем ставить две отдельные на разные шины.
Тогда и получается, что нужны массированные транзакции обмена с памятью по I2C.
Да и EEPROM-ов разных на I2C тоже тьма - тоже их зачем-то именно на I2C делают.

[HHIMERA]

Да и EEPROM-ов разных на I2C тоже тьма - тоже их зачем-то именно на I2C делают.

Ну и что... ну делают по старой привычке... и что дальше??? Применять то их... никто не обязывает...

[mantech]

Да и EEPROM-ов разных на I2C тоже тьма - тоже их зачем-то именно на I2C делают.

Да конечно делают, только объемы памяти, как правило не соизмеримы с SPIшными или нандами... И сам делал голосовой информатор на 128кБ i2c епроме, и ничего, звук, 12кГц, не прерывался и не глючил - чисто программный интерфейс, да еще и на АВРке... Во время проигрывания еще обслуживался модем, клавиатура, датчики и еще по мелочи. Все зависит от рук и головы программиста

Сообщение отредактировал mantech - Jan 13 2016, 13:18

[scifi]

Да конечно делают, только объемы памяти, как правило не соизмеримы с SPIшными или нандами... И сам делал голосовой информатор на 128кБ i2c епроме, и ничего

Да ладно... SPI NOR flash - наше всё. Хотите 16 мегабайт? Их есть у нас. И стоит всего полтора дублона в розницу.

[mantech]

Хотите 16 мегабайт?

Я знаю, вроде и больше видал, я писал про I2C, что у них объемы небольшие по сравнению с SPI и т.д.

[SasaVitebsk]

У меня в предыдущем изделии (пока выпускается) стоит FRAM + EEPROM на I2C. Процессор LPC1765. Написал и забыл. Даже начальную инициализацию сделал так, что автоматически определяется размер установленных микрух и автоматически настраивается всё. И больше вопросов не возникало. Выпускается лет 5 уже.
На stm единственно обнаружил нюанс, что некоторые таймауты обрабатываются аппаратно. Например при ожидании ASK, по-моему. Уже не помню. Короче напрямую в ОС нельзя. Некоторые операции в транзакции надо завершать. Поэтому лучше на прерываниях писать и следить за временем их исполнения.
Но в целом мне не понравилось. Ни в AVR, ни в STM. В MSP не работал с этой шиной.

[jcxz]

У меня в предыдущем изделии (пока выпускается) стоит FRAM + EEPROM на I2C. Процессор LPC1765. Написал и забыл. Даже начальную инициализацию сделал так, что автоматически определяется размер установленных микрух и автоматически настраивается всё. И больше вопросов не возникало. Выпускается лет 5 уже.
На stm единственно обнаружил нюанс, что некоторые таймауты обрабатываются аппаратно. Например при ожидании ASK, по-моему. Уже не помню. Короче напрямую в ОС нельзя. Некоторые операции в транзакции надо завершать. Поэтому лучше на прерываниях писать и следить за временем их исполнения.
Но в целом мне не понравилось. Ни в AVR, ни в STM. В MSP не работал с этой шиной.

На LPC17xx и на LPC23xx я сделал уже множество изделий с микрухами висящими на I2C (МК везде мастер). Это и FRAM и RTC-часы и ЖКИ и датчики и ADE78xx.
Эти изделия выпускаются серийно и давно уже множество их работает у заказчиков. Проблем нет. В том числе и испытания на ЭМС нормально проходят.
И в других проектах на Tiva, OMAP, MSP430, DSP C5502 - много где использовал I2C - везде только аппаратный, нигде не страдал фигнёй типа программной эмуляции существующего в МК I2C.
И проблем тоже не было с ним. И сложного там ничего нет.
На STM32 правда с I2C я не работал.