Няма как модула да е мастър защото в документацията му дават на какви два адреса отговаря, а мастъра няма адрес.

Сега пак четох и явно може модула да е мастър или слейв, като режима се превключва с команди.

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

За първи път виждам човек да се натиска зорлем да ползва I2C, като има под ръка UART. Това I2C е пълен ужас откъм мултитаскинг. Ни DMA можеш да му пуснеш, ни FIFO. Трябва да седиш и да му баеш, все едно е основна част от архитектурата.

Хубаво си помисли.

Цецо, какво имаш предвид да не може с ДМА? Стига да има какво да четеш или пишеш (достатъчно големи данни) си става с ДМА без проблеми.
Примерно разните акселерометро-компаси данните от трите оси на двата сензора са последователни регистри и се четат идеално с едно подаване на адрес на регистър, паметите също.
Това чудо също има достатъчно данни така че какъв да му е проблема да го пусне наведнъж.
Ако има да свързва и други датчици и иска да ползва един бъс ще е по-лесно с едно i2c.
Но като цяло за гпс може би и2ц не е подходящо поради това че модула не може да инициира трансфера. Ако е в някакъв периодичен low power режим и примерно е нагласен да прати чак когато види преместване няма да е удобно. За тия режими обикновено сензорите имат допълнителен изход за прекъсване.
А за баенето - не мисля че е повече отколкото при уарт, особено ако насреща имаш някакъв архаичен АТ протокол. Как е многозадачността там? Пак ти трябва стейт машина и да следиш заявките и отговорите, за да ги подреждаш. Разните допълнения на и2ц-то като старт, стоп, slave address при уарт пак ги има, само дето са на протоколно ниво (ако имаш мултипоинт). А дори и да нямаш обикновено има "виртуални" такива като модули в слейва.

Да работи прекрасно с DMA, ако транзакцията е читава. Обаче ако нещо не е наред, така се обозва, че после не можеш да хванеш кой байт се насрал, къде и защо. Коя част от транзакцията е минала, коя не... Отделно, че съм виждал не един слйв чип, които при сбъркана транзакция така се локва и после трябва да ги рисетваш... Което си е бъг в силикона, ама не е изключение, а реално срещан кейс.

I2C има купчина евенти. Ако човек иска да го управлява съвсем по спецификация, трябва да напише купища евент драйвън код, който в голяма част от случаите няма и как да изтества (щото той никога не се активира). Айде ако си само един мастер и слейвовете са горе долу бавни и прогнозируеми... Някак си става. Ама ако си слейв е цяло чудо. А ако трябва да се подържа и мултимастер архитектура става тотална свинщина. Не случайно в повечето RTOS въобще няма драйвери за I2C, а където има са покрити само частни случаи (памет, RTC и като цяло само сингъл мастер)

Въобще при наличие на UART да ползвам I2C... никога!

Пак казвам - на мен идеята ми е да ползвам GPS-а стриктно в режим слейв (GPS-a да е слейв а микроконтролера ми да е мастъра), данни да се взимат само когато аз го инициирам, на стандартната честота (400 kHz при което би трябвало да си взема данните 4 пъти по-бързо от колкото ако ползвам UART). Не мисля че ще ми трябва DMA, но навсякъде чета че работи с I2C без проблеми, така че ако ми потрябва - ще го ползвам.

Въобще идеологията на шината I2C много повече ме кефи, когато става въпрос за датчици:
- можеш да вържеш много датчици. Това няма как да стане с UART - на всеки UART интерфейс на контролера - вързваш едно устройство и той е "похарчен"!
- синхронна е - позволява много по-големи скорости на трансфер - така процесора ми ще си свършва работата по-бързо и ще спи повече.
- полу-дуплекс - това за мен е предимство защото нищо не се случва без аз да го предизвикам - предаването в едната или другата посока е напълно предвидимо.
- и накрая нещото което е важно за моя конкретен случай: ще ми трябва да си тествам устройството може би стотици часове и като всичките датчици са ми на една шина ще ми е много по-лесно от колкото ако са ми разхвърляни на няколко и от различни типове!

Всичко това е само намерение засега - ако нещо не се получава - ще мина на UART.

би трябвало... но в случая сравняваш ябълки с портокали.
Скоростта при стандартното I2C е ограничена от open-drain драйверите и 400kHz е разумния лимит. Докато при UART проблемът е в синхронизацията на клоковете или по-точно има проблем ако не се използват техники за синхронизиране. Но и без синхронизация UART е на порядък по-бърз, а със синхронизация просто няма база за сравнение...

Отделно, за чии ти е да гониш скорост на трансфер на GPS ???

++ ++

Абе има ситуации в които все пак се налага. Като го конфигурираш да ти праща 6-7 дълги NMEA пакета всяка секунда току виж времето за предаването им да доближи, че и да мине периода
T.e. 1000 байта на 9600

С подходящият хардуер, поддържащ подобни скорости, бачка и на мегахерц.

Не са ми наложителни високи скорости защото от GPS-а ще взимам данни сравнително рядко (няколко пъти в минута).

Писах за скоростта като принципно предимство на I2C-то пред UART-а - до колкото знам първото е до 3.4 MHz, а второто до 1.5 Mbit/s. Ако приемем че има някакви празни цикли при I2C-то - може би през него могат да се прекарат около 3 мегабита, което не само че не е на порядъци по-бавно, а е 2 пъти по-бързо!

Точно обратното е! При I2C се жертва скорост за сметка на множесвен достъп до шината. Демек за да може да има много устройства се използва опън-дрейн вместо пуш-пул. Но това сваля поне един порядък възможните скорости.
Подвеждането ти идва от стандартните баудрейтове, които обаче са "стандартизирани" от времената когато процесорите бачкаха на 1MHz, даже още преди един гений да се изхвърли че 640К са напълно достатъчни за всичко. Действително и днес много от UART перифериите са така проектиране, че не издържат на по-високи скорости. Само че стандартът е за сигналите по жицата, а не за дизайна на периферията. Периферията всеки може да се проектира както иска, съответно зле проектирана няма да постига високи скорости. А от гледна точка на жицата, да се драйва само в едната посока е като да се тича само на един крак. Колкото и да си добър на един крак, все си мисля че тичането на два крака е значително по-бързо

Нека първо да уточним - ние за стандартите ли спорим или за конкретни схемни реализации?