Микроконтролери и електроника
http://mcu-bg.com/mcu_site/

PIC24 SPI SLAVE problem
http://mcu-bg.com/mcu_site/viewtopic.php?f=2&t=13697
Страница 1 от 2

Автор:  speedblue [ Вто Апр 07, 2015 6:16 pm ]
Заглавие:  PIC24 SPI SLAVE problem

Използвам на 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 модула се опомня.

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

Автор:  TheWizard [ Вто Апр 07, 2015 6:21 pm ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

Автор:  Zdrav [ Вто Апр 07, 2015 7:51 pm ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

Автор:  speedblue [ Вто Апр 07, 2015 9:49 pm ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

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

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

Автор:  stefan63 [ Вто Апр 07, 2015 10:00 pm ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

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

Автор:  Zdrav [ Вто Апр 07, 2015 11:15 pm ]
Заглавие:  Re: PIC24 SPI SLAVE problem

speedblue написа:
... така че дължината е разумна.

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

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

Автор:  speedblue [ Сря Апр 08, 2015 12:11 am ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

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

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

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

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

Автор:  stefan63 [ Сря Апр 08, 2015 12:24 am ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

Автор:  sparkybg [ Сря Апр 08, 2015 11:08 am ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

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

Автор:  stoyanoff [ Сря Апр 08, 2015 11:40 am ]
Заглавие:  Re: PIC24 SPI SLAVE problem

speedblue написа:

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


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

Автор:  speedblue [ Сря Апр 08, 2015 11:34 pm ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

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

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

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

Автор:  speedblue [ Чет Апр 09, 2015 6:12 pm ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

Автор:  stefan63 [ Чет Апр 09, 2015 8:20 pm ]
Заглавие:  Re: PIC24 SPI SLAVE problem

Цитат:
но май USB-то ще е генералното решение

Дали?

Автор:  sparkybg [ Пет Апр 10, 2015 12:43 am ]
Заглавие:  Re: PIC24 SPI SLAVE problem

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

Автор:  speedblue [ Пет Апр 10, 2015 4:28 am ]
Заглавие:  Re: PIC24 SPI SLAVE problem

sparkybg написа:
Според мен именно UART-а е най-читавото решение.........
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-а е къде къде по-удобен... но като има и други съображения... а хардуера като е бъгав... :ANAL:

Страница 1 от 2 Часовете са според зоната UTC + 2 часа [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/