Micro-PlC

[conducteur]

Ja... maar met het plaatje heb ik het niet over I²C, maar over gewone seriele communicatie via RX&TX pinnen (RS232, maar dan op 0 &5V)

[Havoc]

Daar ben ik zo geen voorstander van tenzij je enkel lage snelheden gaat gebruiken. Probleem met een pull-up is dat de stijgsnelheid van je signaal enkel door de pull-up en de capaciteit van je bekabeling bepaald wordt. En processoren vragen aan de ingang van IO zeker minimum waarden daarvoor (datasheet). De vraag is dan ook als je weerstanden neemt die klein genoeg zijn om die stijgtijden te halen of je TX uitgang die nog wel laag genoeg kan trekken in de tijd van 1 puls.

[MickeyMouse]

RS-485? Kan snel en ver...

[conducteur]

RS-485? Kan snel en ver...

Zoiets min of meer wil ik bekomen, maar heb nog niet gevonden of dat kan/ hoe het moet om dat te programmeren in JAL...

[MickeyMouse]

en aja, veel ongevoeliger voor storingen.

[Havoc]

RS-485 is geen protocol, enkel een elektrische standaard. Kan inderdaad ver en snel maar is beperkt tot 256 punten mits de juiste transceivers, de meeste laten maar 32 punten toe.

[MickeyMouse]

RS-485 is geen protocol, enkel een elektrische standaard. Kan inderdaad ver en snel maar is beperkt tot 256 punten mits de juiste transceivers, de meeste laten maar 32 punten toe.

Inderdaad!!

[conducteur]

Met 32 Kun je toch al iets doen, zeker als het uit te breiden valt naar 256... Veel meer moet dat niet.

[MickeyMouse]

Met 32 Kun je toch al iets doen, zeker als het uit te breiden valt naar 256... Veel meer moet dat niet.

Het aantal nodes hangt af van de gebruikte transceiver, best meteen starten met de juiste voor 256.

[Geert]

Lig niet wakker van afstanden bij communicatie bij gebruik van microcontrollers op je modelbaan. (Of deze moet al tientalle meters groot zijn)

De in output poorten voor communicatie zijn speciaal ontworpen en op elkaar afgestemd voor optimaal verzend en ontvangst, zeker onderling wat toch de bedoeling is.

Op deze link: http://www.mikroe.com/chapters/view/7/chapter-6-serial-communication-modules staat meer info over communicatie met de PIC 16F887 microcontroller.


Geert

[Havoc]

Met 32 Kun je toch al iets doen, zeker als het uit te breiden valt naar 256... Veel meer moet dat niet.

Het aantal nodes hangt af van de gebruikte transceiver, best meteen starten met de juiste voor 256.

Ja, je moet direct beginnen met de goeie tranceiver. Nadeel van de versie met 256 nodes is dat dit meestal ook "langzame" types zijn tot 1Mbps en niet zo gemakkelijk te vinden (toch niet voor hobby). Dikwijls ook 3.3V types. Langs de andere kant zijn dit meestal standaard footprints dus je kan later zonder aanpassingen een ander type zetten. Beginnen met de makklijk te krijgen standard load (ADM/LTC/MAX1485) en dan later de 1/8 load type in de plaats. Kijk bvb eens naar de SN65LVD12.

Lig niet wakker van afstanden bij communicatie bij gebruik van microcontrollers op je modelbaan. (Of deze moet al tientalle meters groot zijn)

Ken genoeg voorbeelden waar I2C tegen de lamp loopt in het echt eenmaal je de pcb afgaat, zelfs binnen hetzeflde toestel. (*) Eenmaal je de print afgaat moet je specifieke interface chips inschakelen. Kabels driven, storingen, esd als je inplugt etc. Gewoon je processor aan een kabel hangen is een risico. Zo'n drivers zijn gemaakt om tegen wat mishandeling te kunnen. En je stuurt nog al de rommel die op de voeding van een cpu zit mee die kabel op ook.

(*) niet meer dan een I2C thermometer waarmee de temperatuur aan de connector werd uitgelezen. Zelfs in een volledig metalen doos hangt dit zodra je het licht inschakelt. Ander geval is een master die 4-16 slaves beheert, slaves hangen met een flatcable aan de master max 1 meter. Hangt regelmatig zonder dat er iets speciaals gebeurt. Ook allemaal in dezelfde behuizing.

[MickeyMouse]

Inderdaad, je wilt niet weten wat het 'antenne'-gehalte van een paar meters draad is. Als deze rechtstreeks aan uw microcontroller hangt en je gaat er dan mee buiten uw print dan vangt die vanalles op, en dan maar uitzoeken waarom die controller hangt en/of reset.

[conducteur]

maar met een checksum kun je toch telkens controleren of de "boodschap" just is? Of is zo'n systeem geen echte waterdichte oplossing om fouten weg te filteren?

[Havoc]

Ja, dat kan een oplossing zijn. Maar een checksum maken langs de ene kant, die eruit halen langs de andere kant, controleren en als het fout is de andere kant verwittigen om opnieuw te sturen en alles opnieuw te beginnen vraagt tijd, bandbreedte en processingpower. Elke fout die er niet is is pure winst. In het slechtste geval is je aanvraag om opnieuw door te sturen ook verminkt en begint het spel van 2 nodes die elkaar steeds maar opnieuw hetzelfde vragen en er nooit uitkomen. Livelock heet dat. En in het geval van I2C kan je in een situatie komen dat de communicatie stilvalt. En vermits het volgens de standaard ok is om dat te doen...

Je hebt natuurlijk gelijk als je stelt dat je altijd crc checks of zoiets moet inbouwen, anders weet je nooit of er fouten zijn. Zelfs als je denkt dat je communicatie perfect is doe je dat. Maar beter alles op voorhand robuust maken.

[Sattrickske]

Hi Rian,

Als ik dat hier allemaal lees, denk ik dat er toch een paar misvattingen zijn over de lengtes die kunnen gebruikt worden bij dit soort (seriële) comunicatie...
De beperkingen liggen bij de frequentie, puls-vorm en het soort bekabeling.  Elke kabel heeft zijn eigen specifieke weerstand per meter en ook een capaciteit per meter; de kabel gedraagt zich als een low-pass RC-filter.  Des te langer de kabel, des te lager de cut-off frequentie.

Dus zeggen dat je geen I2C wil gebruiken ten voordele van een ander protocol of standaard is een beetje kort door de bocht.  Als je dezelfde bekabeling gebruikt, zal je steeds tegen dezelfde beperking botsen.  Ik heb al afstanden gehaald van meer dan 100m met I2C, wel met buffering.  Kijk hier maar eens naar: http://www.nxp.com/documents/application_note/AN10658.pdf
Transmissie lijnen en de bijhorende hardware zijn jammer genoeg niet eenvoudig te ontwerpen, wat je ook doet/kiest, kijk goed uit!

En Johan heeft het al wat aangehaald, zelf een protocol gaan schrijven is een pak werk