| Микроконтролери и електроника http://mcu-bg.com/mcu_site/ |
|
| SPI и CCP1 заедно ? http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=8336 |
Страница 1 от 2 |
| Автор: | amdatlon [ Съб Ное 27, 2010 7:57 pm ] |
| Заглавие: | SPI и CCP1 заедно ? |
Здравейте , понеже ми трябва комуникация м/у два ПИК-а ( 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 ) . Бладодаря предварително за помоща , тъй като съм начинаещ и срещам доста трудности |
|
| Автор: | Cekins [ Съб Ное 27, 2010 9:19 pm ] |
| Заглавие: | |
Ми нали има USART тоя пик - що се мъчиш? Там можеш да си минеш на чисто хардуерно ниво без никаква външна намеса и си бачка. |
|
| Автор: | amdatlon [ Съб Ное 27, 2010 9:29 pm ] |
| Заглавие: | |
Забравих за да спомена че хардуерния USART на МАСТЕР-а го ползвам за връзка към компютър Но не съм много сигурен но мисля можеше да пусна втори - на други пинове ( софтуерен ) . Дали не греша, и ще стане ли с 2 едновременно ? Може би ще питате защо не пусна директно CPP модула на МАСТЕР-а Мастера взима данни от РС -то и от Слейв-а . Освен това управлява няколко неща както и графичен LCD . Има няколко бутона . С данните от РС-то и от Слейв-а , пък смята доста други работи . Успях доста да го натоваря от към програмен код Slave-a отчита честотата на импулсите и от нея ще се изчисляват доста други неща ( това още не съм го реализирал : ) ) . Та остана този вариант , да разделя задачите на два процесора . |
|
| Автор: | Cekins [ Съб Ное 27, 2010 9:39 pm ] |
| Заглавие: | |
Софтуерения става само за пращане. За приемане не е удобен, щото нали се сещаш че не знаеш кога ще трябва да приемаш, а като почнеш да приемаш от него софтуерно, ще е много трудно да правиш каквото и да било друго. |
|
| Автор: | amdatlon [ Съб Ное 27, 2010 9:46 pm ] |
| Заглавие: | |
Да де , и аз се опасявах че ще се бърка работата на другите процеси, но пък като съм сигурен дали наистина е така .... та за това питах . Благодаря ти ! |
|
| Автор: | Cekins [ Съб Ное 27, 2010 11:43 pm ] |
| Заглавие: | |
Може би най-добре ще е да си реализираш някакъв софтуерен SPI откъм мастера. Така или иначе когато на мастера му трябват данните, ще му се наложи да си ги "поиска" и да си ги "клокне" сам. А CCP-то ще може да си работи с преъксванията си. А и синхронно може да постигнеш добра скорост - с други думи комуникацията ще е в птъи по-бърза отколкото по USARТ-а. Аз съм правил такава комуникация ама 5-те слейва (12ф675) бяха на 4MHz а мастера на 20 и видях малко зор със синхронизацията. При това го правих с ChipSelect и слейва се подготвя да предава - е все пак не става като при хардуерните SPI устройства дето можеш да ги клокваш на 4-5 MHz. |
|
| Автор: | amdatlon [ Нед Ное 28, 2010 12:21 am ] |
| Заглавие: | |
Да и аз за това първо се насочих към SPI , заради доста по-високата скорост. А иначе по въпроса ..... оказа се недоглеждане от моя страна На Slave-а където задавам приоритетите на прекъсванията , заедно със SPI съм сложил CCP и TIMER1. Оставих само SPI , като с най-висок приоритет и нещата се оправиха Тествах го до към 1000 Hz на CCP-то и нямаше омазване на данните . Даже не влияе на измерената честота . Много ти благодаря за отделеното внимание ! |
|
| Автор: | relsys [ Нед Ное 28, 2010 4:16 pm ] | |||||||||
| Заглавие: | ||||||||||
Що приказваш глупости?!? |
||||||||||
| Автор: | bateAz [ Нед Ное 28, 2010 4:26 pm ] | ||||||||||||||||||
| Заглавие: | |||||||||||||||||||
Прав си е човекът. Ако си писал софтуерно приемане на SPI и си останал доволен от производителността, значи или си голям гений, или са ти много ниски изискванията. |
|||||||||||||||||||
| Автор: | Cekins [ Нед Ное 28, 2010 4:56 pm ] |
| Заглавие: | |
relsys : няма невъзможни неща. Има неща които не си заслужават гърча. Асинхронно приемане на данни софтуерно си е безсмислен гърч. Особено пък с тия мижави процесори. Както и да е... Абе нали имаше пикове с 2 USART-a ... Верно че са с повечко крачета (TQFP), ама като трябва що да не се ползва и такъв. |
|
| Автор: | Цецо [ Пон Ное 29, 2010 11:13 am ] | ||||||||||||||||||
| Заглавие: | |||||||||||||||||||
Въобще не са глупости. Ако можеш да напишеш софтуерен УАРТ в двупосочен режим, който да яде по малко от 50% от процесорното време при 9600, ще те призная за гении на пиковете А колегата - ако не е късно, вземи си по голям процесор. Да си има 2/3 уарта и още толкова SPI и не се занимавай с глупости. 458 е античен процесор. |
|||||||||||||||||||
| Автор: | emilvtc [ Пон Ное 29, 2010 11:35 am ] |
| Заглавие: | |
Ако комуникацията не е много натоварена, няма проблем УАРТ-а да е софтуерен. Относно предаването - проблем няма. Трябва таймер, който да генерира прекъсвания с едно битово време. И това прекъсване се генерира само докъто има нещо за предаване. Е, натоварва се проца, но пълно щасние няка. Относно приемането - същия сценарий - При "-" фронта на старт бита на Rx се стартира таймер, който да генерира прекъсване в средата на битовото време. При това прекъсване се чете поредния бит. Слад стоповия бит - таймера се спира и не се генерират повече прекъсвания. И така до следващия "-" фронт на Старт бита. Та при този сценарий с малък трафик през УАРТ-а средното използване на проца за комуникация може да е значително под 50%. Има и разни изгъзици с Оутпут къмпеара и използването на хардуерното му ФИФО. Така е възможно да се направи по-оптимално предаване по УАРТ-а без прекъсвания на всеки бит. Е, при тези непрекъснато поевтиняващи процесори - по-добре да се избере такъв с 2 УАРТ-а и човек да не се занимава с глупости ... Въпрос на компромис с цената разбира се |
|
| Автор: | Цецо [ Пон Ное 29, 2010 3:28 pm ] |
| Заглавие: | |
Ненатоварен интерфейс е много относително понятие. За да е работоспособен един интерфейс трябва да може да поеме 100% натоварване. Т.е. ако работиш на 9600 - в най-тежкия случай трябва да си тече стрим поток на предаване и стрим поток на приемане. Т.е. данните спират само колкото за стоп-старт битове и текат непрекъснато. И през това време да ти върви останалия софтуер и да му оставиш минимум 20Мхз образно казано. Пробвал съм се с подобни глупости и на 9600 е пълен мазохизъм, а кода заприличва на кадаиф. Ама бях объркал една серия платки.... Накрая се отказах и платих направата на нова серия платки (щото грешката беше моя). Пък и както казах, на пазара е пълно с процесори с 2+ уарта, дето са по евтини от 458-цата. Който скоро може и да няма от къде да се купи. |
|
| Автор: | relsys [ Пон Ное 29, 2010 5:11 pm ] | |||||||||||||||||||||||||||||||||||||||||||||
| Заглавие: | ||||||||||||||||||||||||||||||||||||||||||||||
Ами ето какво съм сътворил за Н8 при клок 18 MHz, реална скорост на изпълнение на кода около 4-5 MHz. Доколкото си спомням при тестването отхапваше по-малко от 25-30% на процесора. За 9600, прекъсване на 52 us:
и съответно функциите за четене и запис:
PS: Не че мен ме кефят такива извратени неща, но в случая просто се наложи. Дори на 9600 нещо не се стикова добре с останалия софтуер /който не е писан от мен/ но на 4800 и 2400 нямаше никакви забележки. Пък после го сменихме с I2C. Та така... |
||||||||||||||||||||||||||||||||||||||||||||||
| Автор: | Цецо [ Пон Ное 29, 2010 6:09 pm ] |
| Заглавие: | |
да де и аз така. Правих го, уж трябваше да работи, ама му нямах вяра..... |
|
| Страница 1 от 2 | Часовете са според зоната UTC + 2 часа [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|