Здравейте ,
понеже ми трябва комуникация м/у два ПИК-а ( 18F458 ) , от рода на аз "питам - ти отговаряш" , мисля че I2C ще ми свърши работа НО , първо ми стана интересно как работи и реших да го правя с SPI .
На Slave имам и CCP1 вход който чете входящи импулси и се измерва периода/ честотата.
Също и TIMER1 , за времето .
Master-a през примерно 100 милисек. праща един или 2 байта и чака Slave-а да върне определен отговор . Slave -а използва прекъсване (SSP) за да чете какво праща Мастер-а.

Само комуникацията в този вид съм я направил и си работи чудесно .
Но ако включа и CCP1 -то , от време на време данните които си разменят двата ПИК-а се омазват . Примерно на 5 изпратени и приети , един е грешен .

Обяснявам си го с това че по време на комуникацията , идва прекъсване от CCP1 и се губи част от информацията , но дали съм прав ???

Когато Slave -а влезе в прекъсване при постъпили данни по SPI , забранявам всички други прекъсвания и след това го разрешавам , но пак не помага ?!

Slave - е със 16 Мhz , a Master-a със 20 Mhz кварц
Импулсите които меря със CCP1 са от порядъка на 0 - 200 Hz.
Забелявам че данните се омасват при повисоките честоти на CCP1, над 50 Hz.

Могат ли да не си пречат двата модула , т.е да има вярна комуникация по SPI , и какъв е трика да стане това ?

Aко е нужно сте пусна код ( CCS ) .
Бладодаря предварително за помоща , тъй като съм начинаещ и срещам доста трудности

Ми нали има USART тоя пик - що се мъчиш? Там можеш да си минеш на чисто хардуерно ниво без никаква външна намеса и си бачка.

Забравих за да спомена че хардуерния USART на МАСТЕР-а го ползвам за връзка към компютър
Но не съм много сигурен но мисля можеше да пусна втори - на други пинове ( софтуерен ) .
Дали не греша, и ще стане ли с 2 едновременно ?

Може би ще питате защо не пусна директно CPP модула на МАСТЕР-а

Мастера взима данни от РС -то и от Слейв-а . Освен това управлява няколко неща както и графичен LCD . Има няколко бутона . С данните от РС-то и от Слейв-а , пък смята доста други работи . Успях доста да го натоваря от към програмен код паметта му е на 90 % пълна

Slave-a отчита честотата на импулсите и от нея ще се изчисляват доста други неща ( това още не съм го реализирал : ) ) .

Та остана този вариант , да разделя задачите на два процесора .

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

Да де , и аз се опасявах че ще се бърка работата на другите процеси, но пък като съм сигурен дали наистина е така .... та за това питах . .
Благодаря ти !

Може би най-добре ще е да си реализираш някакъв софтуерен SPI откъм мастера. Така или иначе когато на мастера му трябват данните, ще му се наложи да си ги "поиска" и да си ги "клокне" сам. А CCP-то ще може да си работи с преъксванията си. А и синхронно може да постигнеш добра скорост - с други думи комуникацията ще е в птъи по-бърза отколкото по USARТ-а.

Аз съм правил такава комуникация ама 5-те слейва (12ф675) бяха на 4MHz а мастера на 20 и видях малко зор със синхронизацията. При това го правих с ChipSelect и слейва се подготвя да предава - е все пак не става като при хардуерните SPI устройства дето можеш да ги клокваш на 4-5 MHz.

Да и аз за това първо се насочих към SPI , заради доста по-високата скорост.

А иначе по въпроса ..... оказа се недоглеждане от моя страна
На Slave-а където задавам приоритетите на прекъсванията , заедно със SPI съм сложил CCP и TIMER1. Оставих само SPI , като с най-висок приоритет и нещата се оправиха

Тествах го до към 1000 Hz на CCP-то и нямаше омазване на данните .
Даже не влияе на измерената честота .

Много ти благодаря за отделеното внимание !

Що приказваш глупости?!?

Прав си е човекът. Ако си писал софтуерно приемане на SPI и си останал доволен от производителността, значи или си голям гений, или са ти много ниски изискванията.

relsys : няма невъзможни неща. Има неща които не си заслужават гърча. Асинхронно приемане на данни софтуерно си е безсмислен гърч. Особено пък с тия мижави процесори.

Както и да е... Абе нали имаше пикове с 2 USART-a ... Верно че са с повечко крачета (TQFP), ама като трябва що да не се ползва и такъв.

Въобще не са глупости. Ако можеш да напишеш софтуерен УАРТ в двупосочен режим, който да яде по малко от 50% от процесорното време при 9600, ще те призная за гении на пиковете

А колегата - ако не е късно, вземи си по голям процесор. Да си има 2/3 уарта и още толкова SPI и не се занимавай с глупости. 458 е античен процесор.

Ако комуникацията не е много натоварена, няма проблем УАРТ-а да е софтуерен.
Относно предаването - проблем няма. Трябва таймер, който да генерира прекъсвания с едно битово време. И това прекъсване се генерира само докъто има нещо за предаване. Е, натоварва се проца, но пълно щасние няка.

Относно приемането - същия сценарий - При "-" фронта на старт бита на Rx се стартира таймер, който да генерира прекъсване в средата на битовото време. При това прекъсване се чете поредния бит. Слад стоповия бит - таймера се спира и не се генерират повече прекъсвания. И така до следващия "-" фронт на Старт бита.

Та при този сценарий с малък трафик през УАРТ-а средното използване на проца за комуникация може да е значително под 50%.

Има и разни изгъзици с Оутпут къмпеара и използването на хардуерното му ФИФО. Така е възможно да се направи по-оптимално предаване по УАРТ-а без прекъсвания на всеки бит.

Е, при тези непрекъснато поевтиняващи процесори - по-добре да се избере такъв с 2 УАРТ-а и човек да не се занимава с глупости ... Въпрос на компромис с цената разбира се

Ненатоварен интерфейс е много относително понятие. За да е работоспособен един интерфейс трябва да може да поеме 100% натоварване. Т.е. ако работиш на 9600 - в най-тежкия случай трябва да си тече стрим поток на предаване и стрим поток на приемане. Т.е. данните спират само колкото за стоп-старт битове и текат непрекъснато. И през това време да ти върви останалия софтуер и да му оставиш минимум 20Мхз образно казано.

Пробвал съм се с подобни глупости и на 9600 е пълен мазохизъм, а кода заприличва на кадаиф. Ама бях объркал една серия платки.... Накрая се отказах и платих направата на нова серия платки (щото грешката беше моя).

Пък и както казах, на пазара е пълно с процесори с 2+ уарта, дето са по евтини от 458-цата. Който скоро може и да няма от къде да се купи.

Ами ето какво съм сътворил за Н8 при клок 18 MHz, реална скорост на изпълнение на кода около 4-5 MHz. Доколкото си спомням при тестването отхапваше по-малко от 25-30% на процесора.

За 9600, прекъсване на 52 us:



и съответно функциите за четене и запис:



PS: Не че мен ме кефят такива извратени неща, но в случая просто се наложи. Дори на 9600 нещо не се стикова добре с останалия софтуер /който не е писан от мен/ но на 4800 и 2400 нямаше никакви забележки. Пък после го сменихме с I2C. Та така...

да де и аз така. Правих го, уж трябваше да работи, ама му нямах вяра.....