Ами и аз да се изходя по въпроса. Без да има даден конкретен GPS модул само се разтягат локуми. Има реализации, при които I2C е по-бърз от UART и обратно! Примерно има вариант I2C да използва допълнителен пин, чрез който да се определя посоката потока от данни и да се спестят много байтове! Сега разцъквам един модул, който поддържа UART до към 900к... Така че ако се даде конкретен модул мисля, че нещата ще станат много по-конкретни!

ПП: дано не съм пропуснал(опущил) някъде модела на GPS-a...

Явно опущаш за какво говориш

Това животно I2C на мегехерци е малко като Лох Нес...

Някой се кълнат, че са го виждали...

Но то самата идея да се ползва GPS на I2C си е досатъчно щура де. На мен лично ми бие на мазохизъм.

Поръчах ето това: http://www.tme.eu/en/details/org1410-pm01/gsmgpsgprshspaedgelte-modules/origingps/ - явно съм се объркал за чипсета - не е тайвански, а е SirfIV

Ще видим дали е чак толкова щура идея колкото на теб ти звучи... Ако стане така както съм го замислил ще е много добре! Понеже за момента не намирам I2C емулатор, който да ми върши работа - нещата отиват към написване на собствен. Мисля да го направя за Raspberry Pi че са достатъчно достъпни и евтини, а са си пълноценни компютри. Ако го направя - разбира се ще го публикувам тук или някъде другаде където да е от полза и на други.

Цецо,
Слйв девайси на 1.2 има много чипета, на 3.4 не толкоз много ама пак е впечатляващо количесто. Силикони с мастер като цяло се намират много по-малко.
Големия проблем не e технологичен има го от години сертифицирано - просто НХР държи лицензи и не всички силикон вендори им се плаща, затова го няма много-много.

Е сега и емулатор ще пишеш... Споко и бая софтуер ще ти се наложи да изпишеш за контролера. И като добавка един елементарен дебъг не можеш да направиш, а ще ти се наложи и I2C снифър да си направиш...

И всичко това за да вземеш данните от един GPS, дето е операция за половин ден максимум, на човек дето преди това не е барал такъв модул. Всяка ОС ще ти даде всичко необходимо, даже и само с библиотеките на производителя на контролера в 99% от ситуациите са достатъчни. Отделно, че жицата се снифи с лекота, ако въобще ти се наложи да снифиш де...

Ето за това казвам, че е мазохизъм.

Апропо модула дето си го харесал, струва точно двойно по - скъпо от масовките със сходни параметри.

https://store.comet.bg/Catalogue/MOD/Co ... AifQ%3D%3D

Естествено този няма I2C .

Апропо то I2C щуротията дето си я харесал, мисля е стандартен фичър на Сирф чипсета, та ако толкова си се навил виж и това, пак е много по - евтино:

https://store.comet.bg/Catalogue/Product/9788/

Да де. Лох Нес. И аз съм виждал много чипове дето го подържат, ама досега не съм видял някой да го ползва реално в такава конфигурация. Точно щото е мазохизъм и наказание за хардуериста. И дваж по-голямо наказание за софтуериста.

Обяснявам защо ми трябва емулатор:

Устройството което правя има 4 датчика - GPS, акселерометър, барометър и компас. Това у-во трябва да го тествам дали работи правилно, при всевъзможни комбинации от условия, при всевъзможни "показания" на датчиците и в пълния температурен обхват, който искам да покрия. Понеже не знам дали когато тествам ще е лято или зима, каква ще е температурата, влажността и т.н. и (по-важното) нямам намерение да се разхождам като идиот с някакви платки и батерии в ръка - смятам да тествам в стаята с климатичната камера, като вместо датчиците съм свързал емулатора. Имам предварителни записи с данни от всичките 4 датчика и просто ще ги пусна да се проиграят през емулатора. При това моето у-во няма да може да разбере дали е свързано с истинските датчици или насреща му има емулатор който го лъже.

Сега стигаме до проблема с интерфейсите:

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

Ако GPS-а ми е на I2C, както са и другите датчици - ще имам прекъсване само на една шина, по-малко пинов конектор, софтуера на емулатора ще е по-прост и всичко ще работи по един и същи начин без особености. Вярно че разликата не е голяма, но все пак си я има.

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

Не мога да го разбера това - аргументираш избора на интерфейс с това да ти е лесно да направиш емулатор?
Колкото и добре да звучи това с тестването без хардуера, ще видиш зор - има твърде много дреболии като тайминги, които за да "емулираш" правилно ще трябва първо да ги измериш, а после да ги емулираш. Звучи ми като излишна работа, при положение че реалното тестване пак ще е когато дойдат реалните модули, сензори, вържеш ги на реалната платка, сложиш ги в реалната кутия с реалното захранване.
Да, до този момент ще си намерил известно количество грешки в твоя код и ще имаш един добър емулатор. Ако страничните ползи от този проект са ти ценни за в бъдеще (шефовете искат да имат емулатор за и2ц и плащат за неговия развой) - добре.
Аз лично бих инвестирал (пари и време) в инструментариум от типа на логически анализатор за sniff-ване на и2ц-то (10-тина долара примерно). Повече от това няма да ти трябва. А реално то ще ти трябва дори да тръгнеш да си правиш емулатор
Този gps модул има ли прекъсване да те "събуди" когато има нови данни, отделно от и2ц пиновете?

има и трета опция - свирка с две топки

даниеле,
имам чувството, че не искаш съвет, а просто си си наумил нещо и ще го правиш. добре - времето си е твое.
не знам за какви прекъсвания по платката говориш, освен ако няма да го правиш с 8080?

аз бих го направил така : GPS-а на UART (2 жици) и всеки датчик на отделен I2C по възможност. повярвай ми, по-лесно е като софтуер от намисленото от теб. колкото до броя жици ще е куплунга - на кой му пука? куплунг 10 жици е 10ст, а 20 -12ст.

Целта на темата беше да разбера как се получава информацията от GPS-а през I2C, но вече сме на трета страница и още не е ясно. Утре ще пиша на производителя да праща документация...

За прекъсванията на шината се сещам за два варианта:

1. истинско прекъсване - когато няма закачен емулатор - пиновете от NXP-то минават през два джъмпера и продължават към датчиците. Когато ще закачам емулатора - махам джъмперите и включвам кабела.

2. без истинско прекъсване - кабела от емулатора се закача към двата сигнала на шината, а един от останалите пинове на кабела (свързан към маса) подава сигнал на някакъв ключов елемент който прекъсва захранването на датчиците. като кабела на емулатора се изключи - ключовия елемент подава отново захранване към датчиците и те започват да си мерят и да отговарят по шината.

Ами то си го пише в pdf-a - На стр. 23 пише как да избереш I2C за комуникация. На следващата страница пък са ти дадени адресите за четене и писане. Тръгва в мулти-мастър режим на скорост 400kbps. На страница 29 пък пише какво се случва след като "запали".. или накратко идентифицира се "$PSRF150,1*3E" и почва да бълва NMEA съобщения. На страница 5 пък са ти дали списък с други документи които ще ти трябват.

Всичко това го четох няколко пъти много внимателно и въпреки това остават неясни моменти:

1. С регистри ли се работи или не? Можем да предположим че не, но това не е написано изрично.

2. Когато пращам NMEA стринг - как указвам колко е дълъг стринга? (различните стрингове са с различна дължина)

3. Когато чета - от къде да знам колко байта трябва да прочета?

4. Как указвам кое съобщение искам да прочета? Всичките със сигурност не се събират в 64 байта буфер.