Използвам на PIC24FJ64GA002 хардуерния SPI1 в SLAVE, MODE2, CLOCK_IDLE=1, SAMPLE_RISE, 8bits.
MASTER частта е линукс платка.

Проблема се изразява, че се набиват смущаващи импулси между клока и приемника губи синхронизация. Смущенията идват от захранващата мрежа 220 VAC. Примерно се включва/изключва някакъв 220 V товар на същия кабел и след 1...5...10...20 такива превключвания приемника се шашка.
Използва се прекъсване. Правя тест при два режима на работа - приемната част да използва SS сигнала и без изобщо да се интересува от SS сигнала.

В режим SS disable - приемния модул чува и отчита всички клокове съответно пълни входния регистър с това което си мисли, че има на входа. Тоест влизат доста смущения. На протоколно ниво може да се елиминират с някоя чексума примерно и връщане на отговор за ACK/NACK. Но ще е твърде често влизането в прекъсване. Просто чува дори LED лампа да вкл/изкл.

В режим SS enable - смущенията влизат много много по-трудно, но влезе ли така забива приемника, че по никой флаг не мога да разбера, че е загинал. Не вдига флагове за препълване или нещо друго. Иначе главния процес си върви, но повече не влиза в прекъсването. Само след спиране и пускане на SPI модула се опомня.

Някой да е борил такова чудо? Втория режим е за предпочитане разбира се.

не е ли най-добре да "елиминираш" смущенията

И на какво разстояние са един от друг мастъра и слейва? Има ли някакви драйвери, които да осигуряват необходимото съотношение сигнал/шум или просто CMOS нива по N метра кабел?!?

Линукс платка тип RaspberryPi, но в случая е ODROID и чрез 5 проводника (GND, SCK, MOSI, MISO, SS) с дължина 10 см до другата платка където е PIC24. Връзката е директна между пиновете на процесорите. Двата са на по 3.3V. Одроида има един лентов кабел 10 см за връзка с тестова платка с изведени всички портове или към други модулчета, така че дължината е разумна. Друг е въпроса, че се захранват от отделни захранвания. Но дори да е така факт че влизат понякога смущения. Ако това е нормален SLAVE чип той няма да забие. Ще даде някой смахнат бит но ще живее. Процесора е друго, не ги разбира комбинациите на сигналите по същия начин.

Някой да знае как се вади SPI модула от забиване в SLAVE режим заради фалшив SCK импулс?

Тези две платки са захранени от дв отделни АЦ/Дц адаптера ?
Махни единия и пак тествай.

Какво е забиване в случая? Да не е латч-ъп?

При твоята постановка и 10 см. са неразумна дължина. Сама по себе си дължината не е единствения ти проблем.

Насочил си се да отсяваш софтуерно смущенията, което е кофти идея - неразумна.
Вероятно превключванията на товари по мрежата ти повдигат масата и това е с което трябва да се бориш.

За съжаление нямам особени възможности да подобря тези условия. Линукса ще изпълнява своята роля като отделен елемент. Ще пробвам платката с PIC24 и линукса да ги захранвам от една точка, но това утре.
Иначе съм го оставил в безкраен цикъл и минаха часове без да влезе смущение при обичайните уловия на работа на бюро. Но ако реша да го тормозя се успива.


Отново ще го обясня. Когато изключа SS сигнала на SPI модула - тоест вече не се взима под внимание от преместващия регистър - всичко що е импулси, игли, мъгли на SCK входа (понеже е SLAVE) се приема за тактуване и се пълни с "нещо" от входа DI/SDI/... В един момент се отброява до 8 и се появява цял байт, но понеже SS не играе роля входа чува и неща които ги няма реално, но шума ги набива.
Това показва, че шумовете набиват данни така или иначе. Това е важното в случая. Полезните данни също ще минат, но след тях ще има боклуци. Но SPI модула не забива, той е като тръба без кранче.

Ако се активира следенето на SS сигнала картинка е същата, но тръбата вече има кранче. Но идва момент в който влиза буболечка в тръбата, а кранчето се затваря и тя седи там и прецаква нещата. Тоест случва се да дойде игла или кой знае какво, но не е само една игла, а пакет импулси/шум и някак това там се заблуждава какво точно се е случило. Нито ми дава, че има 8 готови бита, нито че има препълване, нито вече влиза в прекъсването!
Иди разбери, че е забило - аз все още не виждам по какъв явен признак да позная. След което просто на ръка, тоест при някакво условие гасиш-палиш модула и той отново е жив.
При успешно детектиране на проблемното състоянието има решение, но как... още не знам.

Щом може да се оправи с щракане на битове- остава да откриеш загубата на трафик.
Изглежда ползваш чужд софтуер , който не можеш да пипаш - иначе какъв е проблемът да го ресетваш, ако 2 секунди няма валиден трафик?

Или махни отделното захранване, или сложи оптични изолатори. Всичко друго е ташак. Един незначителен граунд лууп може да скапе нещата генерално. Хардуерните проблеми, дето могат да се решат софтуерно не са твърде много.

Същото ми се случва като програмирам с PicKit3 платка с нейно си замасено захранване. Понеже не ползвам изолатор за USB кабела на програматора, граунд лууп-а през USB кабела е достатъчен за да скапе работата в 30% от опитите за програмиране, нищо че често прекалаявам с филтрови кондензатори и прочие подробности по захранванията. Тоест, самото захранване върху платката, която програмирам е доказано читаво изпълнено и смущения там няма.

Опитай да елиминираш смущенията! Примерно постави входен филтър! Общо взето е гадна работа. Най-добре провери в кой диапазон са точно смущенията и тогава ги бори.

Направих няколко записа във файлове на целия RAM преди забиване, след забиване, отново преди забиване и още няколко подобни за да е сигурно, че има повтаряемост.
Резултата е, че нищо свързано със SPI не мръдва и няма начин да се разбере, че е забил. Може да има някакъв заобиколен метод, но спирам с опитите в тази посока.

После добавих в програмата на пика таймер на 4 сек. да ресетва SPI модула ако не чуе валидно начало на пакет данни. Времето от 4 сек. го избрах тестово.
Резултата е, че живота продължава и така.

После свързах ODROID -а да се храни от 5-те волта на платката с пика. Там има едно импулсно което дава 1.0А и му стигат като за мойте проби.
Резултата е драстично подобрение към шумове от към 220V. Утре планирам тест с флекс и други подобни уреди

Алтернативата за трайно решение ще е преминаване на USB вместо SPI. Мислех си за още един UART от страна на пика, но май USB-то ще е генералното решение.

Теста с флекса се отлага за след празниците.
Благодаря на всички за включването, хубави празници!

Дали?

Според мен именно UART-а е най-читавото решение. Поне до към 2-3 мегабита няма никакви грижи (повече не съм пробвал), а и си имаш отделни RX и TX, та и кой-кога предава и приема не те интересува, стига да можеш да дъвчеш данните с нужната скорост. Поне нагласата ми към SPI-то е че е за връзка с разни близки периферийки около чипа, който ги командва. USB-то пък е ненужно сложно (и като хардуер, и като фирмвер) за да го ползваш за друго освен връзка с друг компютър или флашка да речем. Ако устройството с PIC24 е нещо, отговарящо на критериите за външна компютърна периферия, а на ODORID-а търкаляш Linux - бива. Аз общо взето така си правя дивайсите, които искам да могат да имат връзка с компютър (я за ъпдейти, я за нещо друго).

И аз така го мислех, но в случая се тръгна първоначално от много в страни по съвсем други съображения. Тръгна се от I2C порта на ODROID-а понеже така беше "наследен" външния хардуер. Написах и от към наследения PIC18 и от към ODROID-а каквото трябваше за да се съживи комуникация. Тръгна. Заначи ОК, става по I2C. Дизайн на нов хардуер с PIC24 и вече по-сериозно писане на код за двете части. Пускам стрес тестове на комуникацията и изненада - Linux-а, тоест I2C порта на ODROID-а така умира, че само след ребуут на платката се съживява Айде следващата бърза алтернатива... SPI. От към PIC24 е лесно, ремапване на портовете. Отново пиши код за PIC, пиши за Линукс. Стрес тестове - трагедия този път от към PIC-а. Борба да се преодолее - компромисно успешна, но с въпросителни. Идва реда на UART-а, ама този PIC има само 2 хардуерни и те са заети с друга периферия. И сега за бърз тест си мисля трети софтуерен UART+FTDI USB chip и после стрес тест, а в зависимост от резултата или така ще го оставя или в същия корпус PIC с 4 UART+USB и тогава ще си избирам като изводите на USB-то ще ги мапвам с третия UART така, че ще има "резервен" план ако остане време или ако се наложи, че вече сума ти време отече с тия изненади.
А на I2C & SPI още един крак, че да кажеш на MASTER-а ако е нещо спешно... UART-а е къде къде по-удобен... но като има и други съображения... а хардуера като е бъгав...