Здравейте! Някой има ли готова библиотека за софтуерен I2C? Трябва да добавя външеш ЕЕПРОМ, обаче контролерът няма I2C. Няма значение от езика, аз ще си я преведа ако трябва. PIC32 е чипчето и работи на 50МHz. Би трябвало да се получи...
ПП: То и да имаше I2C нямаше да са свободните пинови и така че пак щях да опра до софтуерен...

Майкрочип нема ли?

Има в Harmony, обаче ми се повръща от него...
Видях, че има някаква в wikipedia. Ще я пробвам!

а SPI няма ли - има и такива епроми

Закачай на spi всички имат, от цялата серия само два нямат i2c как баш тях нацели...

Оставете за сега тази работа! Harmony-то си работи, аз съм за ебане. Омотал съм настройките за портовете на UART интерфейсите и от там идват част от парчетата. Останалите са от един зулум, който направих при проектиране на платката. Нямаше RS485 транс на 3.3V с висока ESD защита и сложих на 5V, като използвам 5V толерантни пинове за входните данни. На управляващия пин съм сложил pull-down, за да е затворен при инициализация(да не може източника да блокира контролера ако праща данни при старт). Оказва се, че при това положение на интегралата и трябват поне 20ms, за да се преключи в режим на предаване. Явно защото подавам само 3.3V, а не 5... И съответно преди интегралата всичко е наред, а след нея "един гаща плява"... Добре, че превключих на по-ниска скорост и видях, че след известно време комуникацията тръгва правилно...
Бях решил, че Harmony-то разбърква пиновете на UART-a...
Ще оправим нещата...

Господа, имам питане! Искам да знам има ли някакъв стандарт или максимална честота на това колко често се случва грешка при UART комуникация?! Говоря за хардуерна грешка при приемане - флаг за парити, стоп и т.н. Платките по-горе са близначета - едната е малка с бавен контролер и ниски скорости, а другата е бързичка. Контролер на 120MHz и 3G модем UG95. Проблемът се наблюдава, когато си говоря с модема на 921600 baud rate. Понеже обработвам всички заявки на контролера(PPP) всички данни се предават към него. И когато започна да пускам пинг от няколко източника се случва такава грешка примерно на 20-30 пакета примерно. Числата варират, понякога се случва и на 2-3-5... Когато източникът на пинг е само един се случва рядко - примерно на 100-150 пакета... Нямам конкретни данни. При по-ниска скорост(460800) за сега не съм установил да се случва или е много рядко.
Може ли да споделите като сте работили на такива скорости и сериозен обмен на данни какви резултати сте постигнали?! Искам да знам дали ако си поиграя с терминаторите на линията ще мога да постигна някаква значителна промяна или това е положението?!
Благодаря!

Не няма, и да има все тая, в зависимост от опорната честота имаш някои скорости при които грешката е малка, и други при които е голяма, погледни за конкретните контролери които мъчиш каква е реалната скорост която се получава при твоите настройки. Ако можеш избери си такава при която контролера има малка грешка.
Обаче от друга страна няма как да имаш 20-30 пакета с такава грешка, или искаш да кажеш че на всеки 20-30 имаш грешка? Казваш терминатори на линията, на коя линия има терминатори, ти не говориш ли за RS232 или дори TTL комуникация ? Самите пакети нямат ли чексуми най-малкото, а и корекция на грешки те, поне единични грешки да можеш да коригираш ще е голямо подобрение.
Според мен имаш разминаване в скоростта на двата серийни порта, и от там идват чат пат грешки.

Да уточня - на 20-30 пакета по 70-80 байта 1 грешка.
Ами според чаршафите на контролера ми при този осцилатор и тази скорост грешката трябва да е 0%! Разминаване може да има.

Ами 0% е съвсем теоретично, въпроса е точен ли ти е осцилатора. Отделно синхронизацията ти е по всеки стартов байт, та ако си толкова близо до точната скорост 1/1400 байта започва да не изглежда толкова малка грешка, да не е смущение, при по-висока скорост си по-податлив на смущения.

Напълно възможно е. Прави го на рандом. Уж съм се постарал с опроводяване и т. н. Принципно заради една такава грешчица се хвърля цял пакет. Ще го тестваме как се държи при реално теглене/пращане на данни. Защото ако е само като го товариш с ping, всичко е ок.
И като съм на наполовина по-ниска скорост не съм го наблюдавал за сега. А и по линията има и level shifter, може и той да казва бау... От къде да го знам.
Ти не си ли правил някакви такива по-бързи комуникации? Просто някаква база за сравнение да имам... Защото то реално винаги е възможно такова нещо...

Ето какво се случва - контролерът много бавно установява пиновете си в ниво. Трябват от порядъка на 10-20мс. Имам в предвид, че стойността за 10-20мс е нестабилна и варира, докато най-накрая се качи до Vcc.
Контролерът е PIC32MK1024GPD064 и съм го пуснал на 120MHz. Това се случва на всички пинове, които се използват като управяляващи ('1'-'0'). Такива са пиновете, които управляват разрешението за предаване от модула и управлението на транссийвърите.
Да не е дефектен нещо?! Мога да го подменя... Софтуерът ми е ок мисля. Толкова мога да установя един пин. Спрял съм вътрешни pull-up/down и т.н. Говоря за пинове от различни портове!
Предполагам и това ми прави по-горния проблем - ако късно се задейства сигналът за спиране на данните от модула, вероятно се препълва буфера и губи пакета. Аз съм оставил 2000 байта толеранс, обаче при 921600 тамън си ги препълва за 20ms...
Такова чудо не ми се беше случвало...
Някакви идеи?!

Не става ясно - "мс" е us или ms?

милисекунди = 1s*10E-3!
Става някаква работа тука. Има едни настройки на клока за пиновете и когато го намалих до 12Mhz при установяване от 0 към 1 е по-добре. И понякога всичко става, както трябва!
Шашава работа!
Имам чувството, че тоя туц има някакъв вътрешен брояч или нещо от сорта...

Нееееееее какви 20 МС, нещо не е конфигурирано, преход тр1бва да е от порядъка на Нано секунди.