Verschillende PIC16F628's aansturen via RS232

[Verwijderd]

Hoi,

ik ben reeds enige tijd bezig met het RGB Led project. Na toestemming van William ben ik dan ook beginnen prutsen met de bijgeleverde software en heb hier en daar enkele nieuwigheden toegevoegd. Ik gebruik de standaard setup die terug te vinden is op William's website. Nu zou ik willen proberen om ipv met 1 PIC te gaan werken, er 4 te gebruiken zodat ik met zogenaamd "verschillende LED circuits" kan gaan werken. Ik heb hierover met William reeds gemailed en al vanalles gezocht ivm zulke EL circuits, maar hierover is bitter weinig te vinden. Ik heb van William wel enkele interessante tips gekregen, maar geraak er nog steeds niet uit, gisteren na mijn laatste poging heb ik een PICje verbrand dus zo kan het niet echt verder. Het systeem dat ik zou willen gebruiken gaat als volgt :

We maken een setup dmv MAX232 en 4x PIC16F628, connectie via SUBD naar PC. Elke PIC afzonderlijk zou moeten apart aangestuurd worden, en dit door middel van een ID code die ik elke Pic zou meegeven. Softwarematig moet ik kunnen gaan aanduiden welke PIC_ID ik ga programmeren. In de ASM code van het RGB led project wordt gecontroleerd op een r of w aan het begin van de EEPROM cyclus. Hierna zou dus moeten gechecked worden welke ID code er actief is. Echter indien er meerdere Pics op de MAX232 zitten zullen deze mekaars Tx signaal gaan beinvloeden. William stelde voor om als volgt tewerk te gaan :

Eerst 6 karakters sturen.

1) r of w
2) ID code > 127
3) ID code > 127
4) ID code > 127
5) ID code > 127
6) ID code > 127

Als deze 6 overeenkomen dan:

De desbetreffende PIC moet eerst zijn Tx doorschakelen op de Rx van de PC.

(Dit kan met een uitgang die hoog wordt op een ingang van een AND poort. Op de andere ingang zit de Tx.
De uitgang van AND poort wordt dan de geactiveerde Tx)

De PIC met de ID code wordt nu een actieve RS232 zender.

Dan pas een antwoord van de desbetreffende PIC.

Nu kan er communicatie plaats vinden.

Aan het einde van de communicatie moet de PIC zijn Tx weer afschakelen.

Waarom de ID code > 127?

Dit voorkomt dat de ID code als een opdracht kan worden gezien.

Dit mag dus > 6 zijn. Maar misschien is het handig om dus bit 7 altijd te setten.

Waarom 5x de ID code?

Dit voorkomt dat er een opdracht is die overeenkomt met de r/w en de ID CODE.

De r heeft een dec code van 114 en de w een dec code van 119.

Als je nu een ID code neemt van 128 dan zal het volgende worden verstuurt

1) 114/119
2) 128
3) 128
4) 128
5) 128
6) 128

Er kan nu geen verwarring ontstaan ongeacht wanneer een PIC wordt ingeschakeld.

Dit is namelijk een reeks die nooit in de opdracht structuur kan voorkomen.

Hier loopt het voor mij volledig in de mist. Ik versta het gedeelte wel ivm de id code >= 127 maar ik ben geen held in ASM en zeker niet in het volgende

De desbetreffende PIC moet eerst zijn Tx doorschakelen op de Rx van de PC.
(Dit kan met een uitgang die hoog wordt op een ingang van een AND poort. Op de andere ingang zit de Tx. De uitgang van AND poort wordt dan de geactiveerde Tx)

Ik heb William reeds verschillende malen om info gevraagd, en daar altijd een snelle en uiterst nauwkeurige respons op gekregen (waarvoor eeuwig dank !) , ik wil echter die man niet om de 5 minuten een email moeten sturen. Daarom plaats ik mijn vra(a)g(en) even hier aangezien er hier ongetwijfeld mensen wel een oplosssing weten of me nog wat verder kunnen duwen in de juiste richting. Indien ik dit alles werkende zou krijgen, ben ik gerust bereid om de aangepaste software + schema's en ASM code hier te plaatsen zodat anderen hieraan ook iets hebben.

Alvast bedankt voor het lezen, het is een hele boterham dat weet ik, maar je weet maar nooit.
groeten,
Ariff

[Sprite_tm]

* Sprite_tm stript ff de [EL]-tag ff... We zitten hier in ELektrotechniek, die tag is wat overbodig

Verder: Ik heb het protocol zelf niet bekeken (teveel bier, dat snap ik atm toch niet) maar voor zover je post strekt, lijkt het of je alle PICs daisy-chained: de TxD van pic 1 aan RxD van pic 2 etc. Is het niet handiger om voor elk commando een PIC-ID-veld te gooien en alle RxDs aan elkaar te knopen? Scheelt je iig een zut and-poortjes Ik ken helaas geen PIC-assembly meer (trauma...) dus ik kan je atm niet verder helpen...

[Verwijderd]

Toch een biertje minder nuttigen de volgende keer Sprite want voorzover ik het verhaal kan volgen zijn de PICs niet daisy chained, maar zit de Tx van elke PIC via een AND poort aan de Rx van de PC en andersom zit het natuurlijk direct aan elkaar geknoopt . Schemaatje:

Zoiets zal het zijn, waardoor elke PIC dus alle data vanaf de PC zal ontvangen en alleen mag antwoorden als die serie bytes is aangekomen. Bij het antwoorden zet de PIC ook een extra I/O lijntje omhoog (in schema aangegeven met o), waardoor zijn signaal wordt doorgegeven @ AND gate, etc, etc. De OR gate die hier getekend is kan in het echt ongetwijfeld weg worden gelaten door wat te klooien met de impedance eigenschappen van zo'n AND poort / aangesloten MAX233 oid.

Aardige oplossing, al lijkt het mij persoonlijk wat handiger om 1 master PIC te gebruiken, die dus 3 uitgangen gebruikt om te bepalen naar wie de communicatie toegaat.

[ Voor 27% gewijzigd door Verwijderd op 22-03-2006 05:05 . Reden: typtyfus rond deze tijd ]

[real-doc]

Misschien een raar idee, maar is het niet slimmer om een ander bus-systeem te gebruiken (1-wire bijvoorbeeld, of CAN), en op de seriele poort van de PC een convertertje te zetten van het seriele protocol naar het bussysteem?

[Verwijderd]

Verwijderd schreef op woensdag 22 maart 2006 @ 04:57:
Toch een biertje minder nuttigen de volgende keer Sprite want voorzover ik het verhaal kan volgen zijn de PICs niet daisy chained, maar zit de Tx van elke PIC via een AND poort aan de Rx van de PC en andersom zit het natuurlijk direct aan elkaar geknoopt . Schemaatje:
[afbeelding]
Zoiets zal het zijn, waardoor elke PIC dus alle data vanaf de PC zal ontvangen en alleen mag antwoorden als die serie bytes is aangekomen. Bij het antwoorden zet de PIC ook een extra I/O lijntje omhoog (in schema aangegeven met o), waardoor zijn signaal wordt doorgegeven @ AND gate, etc, etc. De OR gate die hier getekend is kan in het echt ongetwijfeld weg worden gelaten door wat te klooien met de impedance eigenschappen van zo'n AND poort / aangesloten MAX233 oid.

Ok,
dit lijkt me een aardige oplossing. Ik ben echter een serieuze beginner met electronica en zeker met IC's. Alvast excuses voor de misschien wel 'domme' vragen voor zover deze bestaan. Welk type AND poort zou ik hiervoor best gaan gebruiken ? Ik gebruik momenteel deze opstelling :



Ik teken deze middag eens een nieuw schema, misschien kunnen jullie me dan ff helpen waar ik eventuele fouten gemaakt heb. Alvast bedankt voor de snelle reacties

Ariff

[Verwijderd]

Je kunt hiervoor bijvoorbeeld de 4081 gebruiken, een CMOS 4-voudige 2-input AND gate ic. Deze kun je dan het beste gebruiken op het 5/0 volt level (dus tussen PIC en MAX232), aangezien de control lijnen (de o-lijnen in mijn schema) ook 5 volt zijn.

Edit: Waar wil je trouwens 6 onafhankelijke PICs voor gebruiken? Voor het aansturen van 6 RGB ledjes ? Neem dan een enkele wat grotere PIC. .

[ Voor 47% gewijzigd door Verwijderd op 22-03-2006 13:20 ]

[Verwijderd]

Ik wil gewoon met aparte circuits gaan werken in huis, zodat ik kan gaan kiezen welk circuit welk programma moet gaan uitvoeren. Zo heb ik in de gang een rgb led circuit van 14 spotjes, de living 12, slaapkamer 12 en keuken 8 spotjes. Zoals je begrijpt is het dan handig om bvb de gang in een bepaald programma te laten lopen, en bvb de living constant zacht blauw te laten staan, terwijl in de slaapkamer niets moet branden, enz.... Ik zou deze dan ook gaan samenkoppelen met een LCD touch zodat ik de aparte kringen kan gaan aan of uitschakelen, dimmen, enz...

alvast bedankt voor de info !
groeten
Ariff

[Verwijderd]

Dan zou ik inderdaad een bus-systeem gebruiken (zoals i2c / smb / 1-wire / CAN) waar je dus zonder problemen een tiental apparaten op dezelfde bus kunt gooien. Dan heb je alleen bij de PC een RS232 <--> bus interface ictje nodig.

[wacco]

Of, als je het ICtje dat Emiel suggereert niet kan vinden, kan je niet 1 master doen, en dan de anderen erachter met ChipSelect lijnen?

code:

PC
Serial <----> RS232 <----> PIC (master) <-----------
                           ^       ^  ^            |
              CS lijnen -> |       |  |-----|      | <- Shared bus
                           v       v        v      |    w/ clock & data
                          PIC2<--->PIC3<--->PIC4 <--

Nu weet ik natuurlijk niet of je de mogelijkheid hebt om een 'master' aan te wijzen, deze extra management in die PIC te proppen, en genoeg I/O lijnen hebt voor zoiets. Maar het zou in principe kunnen. Misschien een aparte extra PIC puur en alleen voor het master gedeelte?
Kan je iig het gedeelte waar de PICs data terugsturen naar de PC redelijk onder controle houden. Then again, misschien is deze oplossing zwaar overkill voor wat je wilt. I'll leave that as an exercise for the reader

[naftebakje]

In dit geval is RS-485 de ideale bus voor jou. Je maakt een kleine omzetter, die RS-323 omzet naar RS-485. (max 232 en max 485 als ik me niet vergis). Dan heb je een verzendend dradenpaar, en een ontvangend dradenpaar, als je twisted pair gebruikt kan je 1000 meter ver zonder problemen.
Dat is een bussysteem, dus bij elke PIC zet je weer een omzetter van RS-485 naar TTL (met een max 485, kan zo je PIC in). Zo kunnen alle PIC's met elkaar "praten", je kiest zelf je protocol, het is storingsongevoelig, gemakkelijk uit te breiden (gewoon doorlussen), je moet alleen in je protocol zorgen dat de PIC's niet door elkaar gaan roepen.

Edit: omdat mijn uitleg wat krom is, een schema:

[ Voor 13% gewijzigd door naftebakje op 22-03-2006 20:36 ]

[Verwijderd]

Okidoki, na een avondje verder prutsen en met gebruik van de info van naftebakje, ben ik op het volgend schema uitgekomen. Ik weet echter niet zo goed of het helemaal correct is, aangezien het oorspronkelijke schema met een zwaarder type PIC werkt. Ik veronderstel dat ik deze kan vervangen door gewone PIC16F628'jes ? Het schema is echt wel slordig opgesteld, ik heb hier echter weinig tot niets van ervaring mee. Mijn excuses daarvoor. Misschien kunnen jullie eens ff checken of alles er vrij correct uitziet, of dat ik nog zaken beter kan aanpassen ?



Ik had ook nog een ander vraagje : waar vind ik een Shielded pair kabel ? En op het schema met de PIC16F877 is de LTC485 RE geconnecteerd met de RE0/RD/AN5 op de Pic. Is dit een speciale poort en kan ik die eventueel "aanmaken" op de pic16f628 ?

alvast nogmaals bedankt voor de moeite,
Ariff

[LWY]

RE0 is geen bijzondere poort (in dit geval dan) aangezien 'ie gewoon als digitale I/O wordt gebruikt, je kan hier dus elke willekeurige pin op de 16F628 voor in de plaats nemen. Over je schema - Ik heb niet alles bekeken, maar ik zie in ieder geval dat je de MCLR (pin4) op je PIC niet goed hebt aangesloten. Zoals die nu zit zou je PIC in reset blijven hangen, je moet dat lijntje naar GND nog even onderbreken met een schakelaartje.

[JuuL20]

En je LEDs staan verkeerdom, ook zitten er geen weerstanden tussen.

[Verwijderd]

Hallo hier een bericht van William.

Het schema wat Emiel heeft getekent is idd mijn opzet.
Het hoeven geen echte AND OR poorten te zijn maar transistor/diode/weerstand combinatie is ook goed.

De oplossing van Emiel(extra uC als master om communicatie te handelen) is een goed idee.

Nadeel: 2 broncodes

[Verwijderd]

JuuL20 schreef op donderdag 23 maart 2006 @ 07:39:
En je LEDs staan verkeerdom, ook zitten er geen weerstanden tussen.

Aangezien ik maar een schema zie met de RGB led; even een paar opmerkingen:
De led's staan wel goed. Is namelijk een Common Cathode RGB. En wat betreft de weerstanden. De PIC heeft interne currentlimiters van 25mA. Is niet netjes maar werkt uitstekend.

[kluyze]

2 dingen die ik zie dat mis zijn op je tekening.

- 1 die leds hebben WEL een weerstand nodig!!! aan de pin van de µC staat 0-5V een led neemt een 1.6V over zich en dan moet die andere 3.4V ergens over staan. zoals het nu is staat die spanning over een kabel. Een kabel is een ZEER kleine weerstand en zal er dus een grote stroom vloeien. U is namelijk nog altijd I * R. Nu gaat ofwel je led en je µC kapot ofwel treed die "wat jij noemt" beveiliging in.
Als jij dat zo kunt moet je mij dat vertellen, maar alleen aan mij. Kan ik een nobelprijs verdienen .

- 2 Je condesatoren zijn verkeerd gepolariseerd C5 en C7 op je tekening toch.

[LWY]

Er is niks mis met het 'misbruiken' van de current limiter in de PIC hoor. De stroom wordt begrensd tot 20mA en alles blijft gewoon heel. Geloof je het niet, koop dan zelf eens een PIC en hang er wat LEDs aan, misschien krijg je er zelfs een nobelprijs voor.

Die condensators staan overigens gewoon goed, check de datasheet van de MAX232 maar.

[Verwijderd]

Dank je LWY.

Dus toch geen fout in schema!!!

Ga nu zelf het project voorzien van 75176 drivers (RS485). Zodat een hardware adressering mogelijk wordt. Ik moet wel het communicatie protocol enigzins aanpassen zodat niet alle uC door elkaar heen antworden op de PC.

[virus.elektro]

misschien kan je laten controleren of er spanning op de Tx draad staat, zo ja dan mag die pic dus niet zenden, immers de lijn is bezet door een andere. je kan bijvoorbeeld op dat moment gebruikmaken van een back-off loop die een willekeurig aantal keer wordt doorlopen waarna er nog een keer wordt gekeken.

[naftebakje]

Het gemakkelijkste werkt het op een bus als je één Master zet, en de rest slaves. Bij TS zal zijn PC de master zijn neem ik aan (indien de PC niet altijd aangesloten is, kan je nog wat verzinnen om te bepalen wie master mag spelen). Die master is de enige die mag zomaar iets zenden, en hij zal steeds een slave aanspreken (begin je data met een byte die het adres van de slave voorsteld). De slave mag maar antwoorden, als hem dat gevraagd is door de master. Zo heb je een erg gemakkelijk in de hand te houden systeem, dat exact reageert zoals je wil.

Om gemakkelijk te zijn, stel ik voor om een duidelijke consistentie in je data te steken. De reeksen die je zend, beginnen altijd met een byte voor het adres, en dan een byte die de lengte voorsteld (het aantal bytes, dus er kunnen maximaal 255 bytes in een reeks verzonden worden). Dat is wat meestal gedaan wordt, maar beter goed gejat dan slecht verzonnen

In mijn eindwerk zat er ook zoiets, elk toestel had een dipswitch om het adres in te stellen, en ze werden allemaal doorgelust met netwerkkabels (werkt perfect, ook zonder afsluitweerstanden). De PC was master, en bij het opstarten van het programma werden alle mogelijke adressen afgelopen, telkens werd aan een meettoestel gevraagd om de aanwezige meetmodules te antwoorden, geen antwoord wil zeggen dat op dat adres geen meettoestel zit, wel antwoord gaf meteen aan wat de mogelijkheden waren van het aanwezige toestel.

_{En met die led werkt dat hoor, maar je moet wel opletten dat je niet teveel stroom trekt, ik dacht dat het totaal ergens 100mA mag zijn, dus met 5 ledjes zit je erover (de PIC zelf verbuikt ook nog wat, en andere I/O ook), tot 3 led's zal je ws geen problemen hebben. Als je rare errors krijgt, je GND geen 0V meer is, ... dan ga je te ver.}

[ Voor 34% gewijzigd door naftebakje op 27-03-2006 20:41 ]