# RS232 / USB / Bezvadu komunikācija >  SPI/PIC18f4550

## rengens

Vai kādam ir nācies darboties ar hardware ISP uz PIC18F4550?
Paņēmu divus PIC18F4550 un saslēdzu - DI->DO DO->DI CK->CK, SS->SS... Viens PIC sūta, otrs saņem un rezultātu sūtu caur COM uz kompi.
Uztaisīju "Bit-banging" variantu, viss strādā lieliski. Piejūdzu SPI caur hardware - sūtītājs sūta, bet saņēmējs strādā randomā... 
Kodu rakstu C izmantojot microchip <SPI.h>.
Saņēmējs


```
TRISAbits.TRISA5 = 1;    //CS
TRISBbits.TRISB0 = 1;    //DI
TRISCbits.TRISC7 = 0;    //DO
TRISBbits.TRISB1 = 1;    //SCLK
OpenSPI(SLV_SSON, MODE_00, SMPEND)
while (true) {
     if (DataRdySPI()) {
        comOut(getcSPI());
     }
}
```

 Sūtītājs:


```
    TRISBbits.TRISB1 = 0; // SCK
    TRISBbits.TRISB0 = 1; // SDI
    TRISCbits.TRISC7 = 0; // SDO
    TRISAbits.TRISA5 = 0; // CS
    OpenSPI(SPI_FOSC_64, MODE_00, SMPEND);
    while (true) {
        PORTAbits.RA5 = 0;
        WriteSPI(1);
        PORTAbits.RA5 = 1;
        // garāka pauze....
    }
```

 sūtītājs darbojas uz 32KHZ

----------


## ansius

esi dzirdējis par jēdzienu interrupt (IRQ)?

----------


## rengens

jā, drusku  :: 
bet šajā gadījumā līdz tam pat vēl netiku. Nestrādā pat while (!DataRdySPI());

----------


## M_J

Esmu izmantojis SPI datu pārsūtīšanai, tiesa ne starp PICiem, bet starp ATMEL kontrolieriem. Datu apmaiņu caur SPI ļoti viegli ir sačakarēt ar nekorektu montāžu, daudz vieglāk kā, teiksim, datu apmaiņu caur UART. Ja kontrolieri atrodas uz vienas plates, vadu garums minimāls, zeme uz plates kopēja, pareizi savienota - viss strādā. Novietojam kontrolierus 1m attālumā, SPI vadi gaisā, zemes platēm savienotas kaut kur, nezin kur - nekas nestrādā.

----------


## rengens

Paldies M_J ...
UART tiešām strādā galvas tiesu kvalitatīvāk. Visticamāk problēma ir manos 20cm vados..

----------


## Vikings

Ja pa tēmu.
Šorīt atrisināju, šķiet, ļoti radniecīgu problēmu autora problēmai. Viena devaisa maketā no vienas plates uz otro iet 12MHz clock signāls pa vadiņu. Vienkārši saslēdzot plates kopā (izeja->ieeja) devaiss nestrādā. Kādu brīdi apsmadzeņojot problēmu un izslēdzot visus citus iespējamos faktorus pieņēmu, ka pie tik augstas frekvences 20cm garš vadiņš jau rada problēmas dēļ nesalāgotas viļņa pretestības. Pieliku saņēmēja galā 1K rezistoru pret zemi - aizgāja bez problēmām. Domāju ir vērts par tēmu palasīties vairāk no kā jāuzmanās strādājot ar augstas frekvences signāliem, jo šis 1K bija no gaisa pagrābts.
Autor, cik Tev ir SCK signāla frekvence? Vai vēl ir iespējams mēģināt saslēgt SPI un pārbaudīt vai konkrētais risinājums der?

----------


## egilssk

> Paldies M_J ...
> UART tiešām strādā galvas tiesu kvalitatīvāk. Visticamāk problēma ir manos 20cm vados..


 Tas ir tikai šķietami, jo UART strādā daudzkkārt lēnāk un tas ir asinhronais protokols atšķirībā no SPI, kas ir sinhronais protokols. Ja SPI līnijas būs salāgotas, tad tas būs ātrāks un stabilāks.

----------


## marizo

Autor, pēc kā secini, ka "saņēmējs strādā randomā"?
Man izskatās, ka vaina ir nevis 20 cm garajos vados, bet faktā, ka SPI saņēmējs reizēm ir aizņemts ar sūtīšanu caur COM.

----------


## rengens

Nē, uz COM portu sūtu caur 25. kāju (TX), bet SPI izmantoju: 26, 33, 34.
SPI mēģināju startēt ar 32KHZ un vēl 64 dalītāju, bet tāpat līdz sakarīgam variantam netiku.
Tagad gaidu divus PIC32, pamēģināšu ar šiem novietojot tos 2 cm attālumā. Tad trokšņa problēmai nevajadzētu būt...

----------


## kaspich

aftor..
1. par hardware lietu. ja ir aizdomas par nekorektiem IN datiem, in n tuukstoshi prastu metozhu, kaa risinaat. iesakumam: IN procha tuvumaa : C pret zemi, R virknee uz raidiitaaja proci. R un C izvelies taadus, lai signaala forma saak liidzinaaties trapecei.
2. par softu. es nezinu, varbuut kaads ir gatavs konkreto C no galvas zinaat/komentet. es nee. ja buutu kods PEEC kompileeshanas, domaaju, daudz vairaak ko daudzi speetu liidzeet.

----------


## marizo

> Nē, uz COM portu sūtu caur 25. kāju (TX), bet SPI izmantoju: 26, 33, 34.
> SPI mēģināju startēt ar 32KHZ un vēl 64 dalītāju, bet tāpat līdz sakarīgam variantam netiku.


 Nu bet tas ir viens kontrollers, kurš var darīt tikai vienu darbību konkrētā laika brīdī. Ja tas sūta datus pa COM, bet tajā pašā laikā pa SPI tam grūž iekšā kaut ko - lōģiski, ka nespēs korekti saņemt.
Tev raidītāja kodā ir koments:


```
// garāka pauze....
```

 Nu to tad arī ieliec. Būs laiks izpildīt:


```
 while (true) {
    if (DataRdySPI()) {
        comOut(getcSPI());
     }
```

 Un, manuprāt, vari droši celt augšā SPI frekvenci. Es ar 4Mhz kvarcu no PIC16 sūtīju uz 74HC595 reģistru (tas nav PIC, bet SPI protokols tik un tā) ar max ātrumu, ko var izspiest, nebija nekādu problēmu ar 20..30 cm vadiem.

----------


## Slowmo

Nav taisnība par vienu darbību konkrētā brīdī. Ja izmanto aparātiskos portus un pareizi uzstāda pārtraukumus, viss notiek paraleli. Nostrādā pārtraukums tajā brīdī, kad porta bīdes reģistrs tukšs un tajā var rakstīt nākošo porciju, vai arī, kad uz porta saņemta jauna datu vienība.

----------


## kaspich

nu te, skjiet, peec buutiibas nav ponjas.
1. SPI iebuuveetie [receive/transmit] buferi ir ljoti iisi - baits/4 baiti, ar kaartu
2. par sho buferi piepildiishanos/iztukshoshanu zinjo konkreti statusa biti [nezinu c, moska vinjsh maak korekti izcelt tos]
3. normaalai komunikaacijai ir nepiecieshami normaala izmeera receive/transmit buferi [ram] - nelielu apgabalu gadiijumaa: regjistrus, lielaaku - regjistrus [buferzona] un porcijaam uz aareeju ram [da arii kaut aareeja SPI ram, vai caur paraleelo shinu/regjistru]
4. jaa, normaali ir straadaat ar irq: tajaa piepildam sho receive/transmit buferi + saliekam karogus lielaa bufera lietaam, paarbiidam to pointerus
5. staavu zemaak [ok, var arii ar irq, bet to atstaat tikai karoga liimenii, karogs regulaari tiek apskatiits, un pie nepiecieshamibas tiek apkalpota shii subprogramma] darbojamies ar lielaako buferu lietaam.
6. lielos buferus, peec vajadziibas: var kaa blokus, var ar peldoshajiem pointeriem, var ar shadow blokiem..

ceru, ka kaads ko saprata  ::

----------


## Vikings

Vispār jā, priekš komunikācijām buferu lietas ir ļoooti noderīgas. Piemēram, ja pa seriālo jāpārraida čupa baitu bez IRQ tad sanāk daudz liekas gaidīšanas. Reiz uzrakstīju softisku FIFO buferi seriālā porta datu apmaiņai. Sanāk, ka softs ieraksta buferī datus un palaiž pārraidi. Tikko baits pārraidīts - IRQ, ja buferī vēl ir dati, izvada nākošo baitu un tā līdz brīdim, kad buferis ir tukšs. + status biti, ka buferis ir tukšs vai pilns. Saņemšanai - tas pats. Sanāk, ka tagad varu piekrāmēt kaut pilnu buferi momentā un tad darīt citas lietas kamēr buferis tiek palēnām iztukšots tik ik pa brīdim apstrādājot IRQ.

----------


## JDat

Man kaut kur bija 20 baitu pašrakstīts fifo buferis. Murgaini bija ar ASM rakstīt bet gala sānā kaut kas arī strādāja.

PS: Kods, diemžēl, piekš AtMega48.

----------


## kaspich

korektaa softaa prastu gaidiishanu neizmanto. tas ir iesaaceeju/rupjsh tonis.
respektiivi, normaali ir:
daudzliimenju irq [vai nu hardwariski, ja to paredz mcu, vai softiski, kaa piciem]
pamatliimenii loop notiek leeno/pamatprocesu apstraade nonstopaa
vienigaa gaidiishana varetu buut: ja pamatlaikaa nav nepieciesamiibas loop, tad taa staav/gaida kaadu irq vai taa karogu.

gaidiishana irg, apaksprogrammaas - kategoriski jaaizmirst.

----------


## rengens

To gaidīšanu es tur iebāzu tikai uzskatāmībai un izmantoju tikai testam. Dabīgi, ka nopietnākā risinājumā iesaldēt visu ar loop nav smuki..

ar buferi te lieliski noder pics ar lielāku atmiņu. Taisīju savu "video adapteri", kur viens PIC18 sūta otram PIC (sākotnēji 18, pēc tam 32) caur UART datus (0,5Mbit). Izmantojot ārējo RAM (SPI) uzkāpu uz izaicinājuma, ka tas strādāja lēnāk par manu UART, turklāt grūti caur SPI vienlaicīgi ķeksēt datus ārā un rakstīt uz IRQ, kā nekā IRQ bremzēt nevar. Tad taisīju otru iekšējo rindu, bet nu figņa... 
Par laimi PIC32 atmiņas ir pietiekami lai šo realizētu... Vispār 32nieks izskatās baigā pasaka.. 

Par to paralēlo darbību ar SPI un UART - arī biju iedomājies, ka šie nevar darboties vienlaicīgi, tāpēc atslēdzu UART eksperimentāliem nolūkiem, bet ar "ciet acīm" grūti strādāt. Rezultāti neuzlabojās...  Osciļa man nav, tas visu mazliet sarežģa... 

Pagaidām esmu izdīrājis savu risinājumu un atgriezīšos pie tā vēlāk, liels paldies visiem par komentiem!

----------


## kaspich

> To gaidīšanu es tur iebāzu tikai uzskatāmībai un izmantoju tikai testam. Dabīgi, ka nopietnākā risinājumā iesaldēt visu ar loop nav smuki..
> 
> ar buferi te lieliski noder pics ar lielāku atmiņu. Taisīju savu "video adapteri", kur viens PIC18 sūta otram PIC (sākotnēji 18, pēc tam 32) caur UART datus (0,5Mbit). Izmantojot ārējo RAM (SPI) uzkāpu uz izaicinājuma, ka tas strādāja lēnāk par manu UART, turklāt grūti caur SPI vienlaicīgi ķeksēt datus ārā un rakstīt uz IRQ, kā nekā IRQ bremzēt nevar. Tad taisīju otru iekšējo rindu, bet nu figņa... 
> Par laimi PIC32 atmiņas ir pietiekami lai šo realizētu... Vispār 32nieks izskatās baigā pasaka.. 
> 
> Par to paralēlo darbību ar SPI un UART - arī biju iedomājies, ka šie nevar darboties vienlaicīgi, tāpēc atslēdzu UART eksperimentāliem nolūkiem, bet ar "ciet acīm" grūti strādāt. Rezultāti neuzlabojās...  Osciļa man nav, tas visu mazliet sarežģa... 
> 
> Pagaidām esmu izdīrājis savu risinājumu un atgriezīšos pie tā vēlāk, liels paldies visiem par komentiem!


 
pag, Tu iedoamajies taapeec, ka Tev nav datasheet pieejams, Tev patiik ko izdomaat, nespeej datasheet atrast aprakstu, vi kas par vainu.
ir mcu, kas ljauj vuenlaikus, ir kas ljauj vainu/vainu..
cilveek, Tev bi iemaaciities 16F84, un tad taalaak. a to buus veel viens, kas 32 series meegjinaas gismas diodi mirkskjinaat..

----------


## rengens

> a to buus veel viens, kas 32 series meegjinaas gismas diodi mirkskjinaat..


 Ļaušu Tev mirkšināt savu gaismas diodi. Gan jau Tev vēl vienu palīgu nevajadzēs  ::

----------


## Delfins

imho, izspiest no čipa 99% var tikai rūdīts specs.
Jauniņiem jau "atļauts" ņemt jaudīgāku dzelzi  :: .. kaspich, vai tev žēl, ka kāds mācās!?  :: 

es pats uz atmega128 miršķināju LED-u.. un pārāk nestresoju, arhitektūru jau izprast var tikai eksperimentējot. Tas ka gatavā produktā izmanto 1% no čipa - tad gan fail.

----------


## kaspich

> imho, izspiest no čipa 99% var tikai rūdīts specs.
> Jauniņiem jau "atļauts" ņemt jaudīgāku dzelzi .. kaspich, vai tev žēl, ka kāds mācās!? 
> 
> es pats uz atmega128 miršķināju LED-u.. un pārāk nestresoju, arhitektūru jau izprast var tikai eksperimentējot. Tas ka gatavā produktā izmanto 1% no čipa - tad gan fail.


 nee, tieshi otraadi - es PRIECAJOS, ja/kad kaads maacaas. vnk uz maza mcu ir daudz vinkaarshaak pamatlietas sadariit. atkriit ntaas konfiguraacijas, alternatiivie porti, milziigaas atminjas, u.c. man vnk skjiet, ka 90% visu gribeetaaju peec 2 vakaru pachakareeshanaas ar tiem briesmonjiem visu izmet miskastee un pieveershas citiem hobijiem. varbuut kljudos  ::

----------


## Delfins

Nu par to atmešanu jā, jāpiekrīt... redz, ja cilvēks saprot, ka tas "nav viņa īstais hobijs", tad nekas cits neatliek.
Tu taču neapgalvosi, ja jau pievērsies kādam hobijam, tad tas "jāvelk" līdz mūža galam, pat ja nepatika? Tā kā šeit nav svarīgi MCU portu/atmiņas izmērs ja vajag pamēģināt vai dabūt ātri rezultātu  ::

----------


## RobinDAB

> vnk uz maza mcu ir daudz vinkaarshaak pamatlietas sadariit


 ar piebildi - ja lieto asm.
Diemžēl ar dziļām skumjām jākonstatē, ka lielais vairums sāk ar c vai kautkādu klucīšbīdīšanas grafisko vidi, kur par mcu ir jāzin tikpat kā nekas. 
Un tad arī sākas problēmas.
Un tad arī vienmēr "piertūkst".

----------

