Микроконтролери и електроника
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 ]
Заглавие: 

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

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

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

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 , заради доста по-високата скорост.

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

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

Автор:  relsys [ Нед Ное 28, 2010 4:16 pm ]
Заглавие: 

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


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

Автор:  bateAz [ Нед Ное 28, 2010 4:26 pm ]
Заглавие: 

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


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


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

Автор:  Cekins [ Нед Ное 28, 2010 4:56 pm ]
Заглавие: 

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

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

Автор:  Цецо [ Пон Ное 29, 2010 11:13 am ]
Заглавие: 

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


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


Въобще не са глупости. Ако можеш да напишеш софтуерен УАРТ в двупосочен режим, който да яде по малко от 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 ]
Заглавие: 

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


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


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

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


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

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

Код:
interrupt[TPU_TGI0A] void EKLZ_SOFT_RS_INT(void)
{
  TPU_TSR0 = TPU_TSR0 & 0xFE;  //Clear INT Flag
 
  //IF 52us INT - dec a variables which will be used
  //for sending/recv @104us
  int_divider--;
  int_divider_rx--;
 
  //STOP BIT WAITING
  if ((!start_bit_detected) && !stop_bit_detected)// && !int_divider_rx)
    {
      if (PORT3.3 == 1)
        stop_bit_detected = true;
    }
 
  //USART RECEIVE/START BIT DETECTION
  if (!start_bit_detected && stop_bit_detected)  //HERE WE ARE @52 us INT
    {
      if (PORT3.3 == 0)  //START Bit detecting
        {
          TPU_TCNT0 = 0;  //this line for some delay
          start_bit_detected = 8; //8 -> for 8 bits reading
          stop_bit_detected = false;
          isu_rx_buffer = 0;
         
          int_divider_rx = 2;
        }
    }
  else//if (start_bit_detected)//USART RECEIVE
    {
      if (!int_divider_rx)
        {
          isu_rx_buffer >>= 1;
          if (PORT3.3)
            isu_rx_buffer |= 0x80;
          start_bit_detected--;
          if (!start_bit_detected)
            {
              isu_byte_received = true;
            }

          int_divider_rx = 2;
        }
    }
 
  //USART SEND
  if (isu_counter && !int_divider)
    {
      P3DR.4 = isu_buffer & 1;
      isu_buffer = isu_buffer >> 1;
      isu_counter--;
      int_divider = 2;
    }
}


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

Код:
byte INT_SOFT_USART_Data_Ready(void)
{
  return isu_byte_received;
}

byte INT_SOFT_USART_Write_Byte(byte data_to_send)
{
  if (!isu_counter)
    {
      isu_buffer = (data_to_send << 1) | 0x200;
      isu_counter = 10;
      int_divider = 2;
      return True;
    }
  return False;
}

byte INT_SOFT_USART_Read(void)
{
  isu_byte_received = False;
  return isu_rx_buffer;
}


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/