Seriell komunikation med PIC.ar

[squiz3r]

Hej,
Jag behöver kunna köra seriell komunikation mellan två PIC.ar på endast en kanal (signal- och GND-kabel). jag undrar hur det är best att sända, jag har testat lite med pulser med olika längd. jag kopplade så att om en puls med längden under 0,5 sekunder komm tändes LED1, komm en pulls över 0.5 sekunder men under 1,0 sekunder tändes LED2 o.s.v. men jag behöver ju "såklart" snabbare komunikation, och jag kan tänka mig att det är svårt med denna sorten, någon som vet något bättre? Jag vill ha minst runt 10 olika "kanaler".
Mina kunskaper inom PIC.ar är begränsade så gärna något lätt, jag kör ASM...

Tack!
//Daniel A

[buscalle]

Om du anväder PIC'en UART förutsatt att du har en modell som är utrustad med det som typ min favort 16F876A. Så kan du skicka ett seriellt ord till en annan pic som får ett interrupt när den har tagit emot hela byten. Sedan kan du låta programmet tolka den som du vill. PIC'en an ju då också sända en kvittens men då kravs det ju en ledning till. Jag har lite kod i C för att hantera det där om du är intresserad.

// Christian

[squiz3r]

Hmm.. låter intresant men ganska svårt... jag kan inte C men det kanske inte skadar att ta en titt på det om du har det liggandes Jag hadde tänkt använda en 16F628A men det går nog bra med en 16F876A också, bara priset är rätt på den. Hur långtid tar det att skicka över en bit på det sättet?

//Daniel A

[sodjan]

Du kan ju alltid hitta på ett eget protokoll och köra med
open collector och ett externt pullup motstånd. Låt en
PIC vara "master" och styra det hela.

Sen är det inte helt trivialt att köra med en självklockande datakanal.
Kolla lite på Manchester kod t.ex.
Om du kan lägga till en separat klockkanal så blir det både säkrare
och du kan sannolikt köra snabbare.

Det är lite oklart i ditt inlägg :

> Jag behöver kunna köra seriell komunikation mellan två PIC.ar på endast en kanal
> Jag vill ha minst runt 10 olika "kanaler".

Är det två PIC'ar med 10 kanaler eller 10 (11 ?) PIC'ar med varsin kanal ???

> Hur långtid tar det att skicka över en bit på det sättet?

Hur snabbt *VILL* du köra ?????

Och det blir knappast enklare för att man byter till C.

[squiz3r]

>Om du kan lägga till en separat klockkanal så blir det både säkrare

tyvär så kan jag inte göra det då jag bara har tillgång till två sladdar (GND, signal)


>Är det två PIC'ar med 10 kanaler eller 10 (11 ?) PIC'ar med varsin kanal ???

Vad jag menar med det är att jag ska kunna skicka informationen i en kabel, men den informationen ska kuna styra runt minst ca 10 t.ex. LED


Hur snappt jag vill kunna köra, jag vill kunna styra alla tio LED.na på mindre än typ 0,25 Sekunder

Hoppas att jag var tydlig nog! jag förstog inte så mycket av det du sade, men jag får läsa på det lite mera!

>Och det blir knappast enklare för att man byter till C.

Jag menade inte att jag skulle byta till C, jag menade att det kanske är bättre att se ett exempel i C än inget alls...


Tack!
//Daniel A

[sodjan]

> då jag bara har tillgång till två sladdar

OK, inte olösligt. Googla t.ex efter "Manchester code". Det är ett sätt
att blanda klocka och data i samma signal/linje.

> men den informationen ska kuna styra runt minst ca 10 t.ex. LED

OK, så två PIC's alltså. Då är det bara att hitta på olika kommandon för
det du vill at den andra PIC'en ska göra.

> styra alla tio LED.na på mindre än typ 0,25 Sekunder

*Väldigt* gott om tid...
Hur långt är det mellan PIC'arna ?

[squiz3r]

Så som jag fattar det så sänds "Manchester code" i "växelspänning" så att den är negativ iblnd o pussitiv ibland?

Det är inte mer än några meter mellan picarna ( är tanken i alla fall) så det kan ju inte va några problem...

Tack!!

[sodjan]

Med ett par meter har du inga problem med att köra tillräckligt fort
för dina krav att styra 10 LED's på max 0.25 sek.

Ska den andra PIC'en göra något annat är att styra 10 LED's ?

[squiz3r]

Den andre PIC'en ska inte göra något annat (va jag kan komma på nu), det finns risk för att det blir någon liten sak men...

jag har exprimenterat lite mer nu, o kommit framm till att det gåt bra att köra så som jag beskrev ovan med olika långa pauser, jag har nu:
En signal på 15mSek en på 30mSek, och en på 45mSek, och det är inga problem alls med dem. Det betyder att om jag ska ha tio sådana blir det 150mSek.


Tack för all hjälp!!
//Daniel A

[sebbe]

låter som ett kul projekt jag håller själv på att lära mig lite ASM skulle du vilja dela med dig av lite kod?

sebbe

[squiz3r]

Visst kan jag det, men problemet är att jag skriver koden på en dator utan internett så jag får bara leta reda på en disket först... men den är inte särskilt "bra" kod, jag har fortfarande "equ" på variablerna när jag bestemmer vilket register dem ska ligga i

har du byggt något än då?

//Daniel

[Marta]

Varför göradet svårare än det är? Kör asynkront, det brukar fungera alldeles utmärkt.

Även utan UART går det fint att göra det. Seriell kommunikation i programvara är lätt om det inte finns någon interrupt som stör timingen.

Är det korta trådar och rimlig fart så sätt ettmotstånd emellan så inte utgångarna kan mötas direkt med varandra om kretsarna skulle råka komma i otakt.

[sodjan]

> jag har fortfarande "equ" på variablerna när jag bestemmer vilket register dem ska ligga i

Tja, det är ju "rätt" metod när/om man skriver kod i det gamla formatet ("absolute mode").

I "Relocatable mode" så används ju andra metoder (UDATA, RES o.s.v)

Så EQU är inte "fel", bara lite omodernt...

Visst kan man köra med USART'arna, det blir dock lite extra
pyssel eftersom USART använder separata pinnar för TX/RX och squiz3r
ju här vill använda enbart en enda dubbelriktad linje.

Absolut enklast vore att lägga till en extra tråd på linjen så att TX/RX
kan separeras...

> jag skriver koden på en dator utan internett

Right, man gör det så svårt för sig som man själv vill, antar jag...

[Radioman]

... men den är inte särskilt "bra" kod, jag har fortfarande "equ" på variablerna när jag bestemmer vilket register dem ska ligga i

Det går utmärkt att fortsätta så för de små projekt du testar nu. Inget att skämmas för alls. Jag såg din tråd http://elektronikforumet.com/forum/view ... ock#187272 där Sodjan jättefint beskriver hur man på ett elegant sätt bör göra för att få riktiga variabler. Men det gäller att få det att fungera i MPLAB också.
Jag hänvisade en kompis till mig till den tråden. Han har också precis börjat med PIC och assembler. Han gick en jättefint program på gymnasiet (länge sedan förstås) som hette microdatorn, eller nåt, så han har lite att stå på från början. Han är duktig och envis så de egenskaperna saknas inte.

Han tände till och har lagt en del timmar på detta med udata mplink osv. Dock utan att lyckas. Han plöjer dokumentationen som finns men kan inte ens få det enklaste exempel *i dokumentationen* att fungera i MPLAB. Något kryptiskt larm om att det är för svåra instruktioner ? Hade jag haft mer detaljer så hade han kanske kunnat få hjälp här. Han är dock ingen person som hänger så mycket på forum. Jag får väl stödja honom när han går i väggen och sitter som Kalle Anka gör efter att hackspetten nockat honom på julafton .
Själv har jag tagit en genväg för att snabbt få till något projekt mer än blinkande lysdioder och köpt mig fri med en basic kompilator/simulator där jag också lär mig assemblerkod genom att titta på resultatet efter assembleringen.
Den kompilatorn använder också equ ....

[sodjan]

Säg bara till, jag kan enkelt posta ett litet "skal" för relocatable mode.

Det är ju inte bara att byta EQU till RES, bl.a tillkommer :

Byte av ORG till CODE
Lägga till ett "Linker Script" till projektet.

Så länge som man låter all källkod ligga i *en* ASM fil, så behöver man
inte bekymra sig om sådant som EXTERNAL, GLOBAL o.s.v.

Notera att relocatable mode inte är *svårare* i sig, men ger många
fördelar när man väl har valt att skriva koden så.
Se även : http://www.jescab.se/Rellocmode.html

Slutligen så är relocatable mode det *enda* sättet att skriva kod till
nyare processorer som PIC24 och PIC30. Absolute mode stöds inte
alls till dessa.

> Dock utan att lyckas.
> Något kryptiskt larm om att det är för svåra instruktioner ?

Vad är problemet ?
Exakta felmeddalnden vore bra.