[Ruslan1 16]

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

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

для LPC - упомянута только одна ошибка в реализации I2C, вроде бы обходится без особых танцев с бубном, так что тоже годится.

спасибо, буду знать.

[scifi 1]

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

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

[ViKo 1]

Гиперкуб :rolleyes:

 

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

[VCucumber 0]

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

[jcxz 187]

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

для LPC - упомянута только одна ошибка в реализации I2C, вроде бы обходится без особых танцев с бубном, так что тоже годится.

спасибо, буду знать.

Может и недообследовали, но у меня на OMAP на I2C висит FRAM, в которую непрерывно пишутся логи работы, так что обмен довольно интенсивный и никаких проблем в его работе я не заметил.

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

[Velund 0]

Изучая сякие SPL и HAL к сабжу, и собственно, сабжи, пришел к выводу, что использовать из них можно только заголовочники (.h). И то с наятгом.

Так как никакой универсальности в плане работы с периферией они не несут. Так, к примеру, у 32F1 и 32F0 разная по возможностям периферия.

Тот же USART, SPI. И, написав код под F0, на F1 его запустить уже не получится. И HALы с КУБами никак не помогут.

 

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

 

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

 

 

[Quasar 18]

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

 

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

 

 

[Tarbal 4]

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

 

Точно!!!!!

:)

[jcxz 187]

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

Это программная эмуляция имеющейся в МК периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и иже с ними.

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

А ведь бывает нужно на несколько разных интерфейсов I2C повесить устройства. Вот тут и появляются чудо-проекты, когда МК с несколько сот МГц тактовой едва хватает для опроса пары датчиков.

Видно все Ваши задачи заключаются в моргании несколькими лампочками, тогда да - чем ещё загружать CPU?

[VCucumber 0]

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

[jcxz 187]

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

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

[scifi 1]

Это программная эмуляция имеющейся периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и подобных.

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

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

А если интенсивный обмен, то прерывание на каждый байт - тоже не сахар.

[mantech 35]

Это программная эмуляция имеющейся в МК периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и иже с ними.

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

 

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

 

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

[VCucumber 0]

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

и автоматом решается вопрос с маппингом и ерратами

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

[jcxz 187]

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

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

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

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

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