Welk dataprotocol microcontrollers grotere afstand

Bij RS485 heb je het veelgebruikte modbus RTU protocol.
Is geschikt voor langere afstanden.
Indien interesse kan ik je een stuk C programma voor pic ervan doorspelen.

Groeten,
Dries

[Bericht gewijzigd door Mère op maandag 5 juni 2006 09:36:56 ]

En het hangt ook helemaal af wat je over de bus wilt gaan transporteren, als het alleen een paar signaalgevers zijn of weinig data overstuurt, er zijn buffers voor de I2C zodat je een paar honderd meter kan overbruggen, wil je mat meer intelligente data overdracht, dan is een Modbus over Rs485 een goede optie, voor audio/video overdracht (misschien niet echt haalbaar met een PIC, maar als voorbeeld) toch een TCP/IP stack (met Cat trouwens ook RS485) implementeren....

Je hebt ook de CAN-bus, naast RS485, ik zou toch voor de laatste gaan (tis het gemakkelijkste).
Stel gewoon zelf je protocol op, als je er geen vind dat je aanstaat of je het simpel wil houden, tis helemaal niet moeilijk (begin met byte "S", adres, "L", aantal bytes dat volgt (gemakkelijker om te ontvangen), en dan je eigen code's).

Bedankt voor de antwoorden,
Van de modbus had ik nog nooit gehoord, ik moet nog even googelen wat het precies is.
Ik vind de overhead bij CAN en ethetnet erg groot.
De gedachte is dat er niet veel data transport zal zijn, en om de microcontroller niet te veel te belasten zoek iets dat net als iic een interrupt genereerd bij een adresmatch.
Dus iets alla iic met lijn drivers zou mooi zijn.

Op 5 juni 2006 21:55:02 schreef rrob:
Bedankt voor de antwoorden,
Van de modbus had ik nog nooit gehoord, ik moet nog even googelen wat het precies is.
Ik vind de overhead bij CAN en ethetnet erg groot.
De gedachte is dat er niet veel data transport zal zijn, en om de microcontroller niet te veel te belasten zoek iets dat net als iic een interrupt genereerd bij een adresmatch.
Dus iets alla iic met lijn drivers zou mooi zijn.

Gewoon RS485 dus, en werken met de UART van je µP.

of als je je belasting erg laag wilt houden I2C + buffers. sommige processoren halen je dan een hele hoop werk uit je handen.

Op 5 juni 2006 21:55:02 schreef rrob:
Bedankt voor de antwoorden,
Van de modbus had ik nog nooit gehoord, ik moet nog even googelen wat het precies is.
Ik vind de overhead bij CAN en ethetnet erg groot.

Modbus heb je in vele soorten. In de industrie is op dit moment de meest gebruikte Modbus RTU. Voor zelfbouwprojekten kun je ook kijken naar Modbus Ascii.

Ethernet heeft over het algemmen veel overhead. Dit is echter geen vast gegeven. Ethernet is nl niet echt een protocol. Er bestaan ook ethernetprotocollen met veel minder overhead zoals bv EtherCat

Op 6 juni 2006 08:58:06 schreef GJ_:
[...]
Ethernet heeft over het algemmen veel overhead. Dit is echter geen vast gegeven. Ethernet is nl niet echt een protocol. Er bestaan ook ethernetprotocollen met veel minder overhead zoals bv EtherCat

Ethernet (echt ethernet dan) heeft niet noodzakelijk veel overhead, dat zijn preamble (8 byte), DEST (6) Source (6), Type (2) en dan de data. Dus een 22 byte overhead. Het probleem zit hem eerder in de min frame lengte, die namelijk 64 byte is (door de mogelijkheid om met csma/cd collisions te detecteren). Daardoor moet je als je maar 1 byte wil doorsturen 45 byte padding mee opgeven, wat nogal een verspilling is. Daardoor is ethernet niet zo ideaal daarvoor.

Ik zou ook voor RS485 gaan. Is een mooie standaard en niet al te moeilijk te implementeren lijkt me...

Op 6 juni 2006 09:51:11 schreef stecj366:
[...]

Ethernet (echt ethernet dan) heeft niet noodzakelijk veel overhead, dat zijn preamble (8 byte), DEST (6) Source (6), Type (2) en dan de data. Dus een 22 byte overhead. Het probleem zit hem eerder in de min frame lengte, die namelijk 64 byte is (door de mogelijkheid om met csma/cd collisions te detecteren). Daardoor moet je als je maar 1 byte wil doorsturen 45 byte padding mee opgeven, wat nogal een verspilling is. Daardoor is ethernet niet zo ideaal daarvoor.

Ik zou ook voor RS485 gaan. Is een mooie standaard en niet al te moeilijk te implementeren lijkt me...

Echt ethernet is geen protocol. En bij bv ethercat (toch echt ethernet) stuurt men 1 frame met info voor alle gebruikers. Deze halen de voor hun interessante info eruit en stoppen hun eigen info er terug in. Zo kun je met 1 telegram alle gebruikers van informatie voorzien en tegelijk alle informatie ophalen.
Er zijn nog meer realtime synchrone ethernetprotocollen.

Laten we nou vooral een duidelijk onderscheid maken tussen de soorten wegen, de bijpassende voertuigen en de hulpmiddelen om te laden en te lossen.

Op 6 juni 2006 10:17:38 schreef GJ_:
[...]
Echt ethernet is geen protocol. En bij bv ethercat (toch echt ethernet) stuurt men 1 frame met info voor alle gebruikers. Deze halen de voor hun interessante info eruit en stoppen hun eigen info er terug in. Zo kun je met 1 telegram alle gebruikers van informatie voorzien en tegelijk alle informatie ophalen.
Er zijn nog meer realtime synchrone ethernetprotocollen.

Laten we nou vooral een duidelijk onderscheid maken tussen de soorten wegen en de bijpassende voertuigen.

Maar als ethercat echt ethernet wil zijn zal het toch ook een min frame lengte moeten hebben van 64 bytes, of het voldoet niet aan de standaard opgelegd door Ethernet. IEEE802.3 heeft ook een min lengte van 64 bytes.

Het kan dan wel zijn dat je met 1 frame meerdere gebruikers iets meedeelt, met een multicast dan (ik dacht MAC all 1's), maar je zal zowiezo toch 64 bytes minimaal moeten hebben. En anders staat er een mega fout in mijn cursus (die ik de afgelopen dagen onder de neus had :s ) en word ik graag gecorrigeerd...

En neen, ethernet is inderdaad geen "protocol", het is een datalink (layer 2). Layer 3, daar zitten de communicatieprotocollen (IP, IPX, ...)

Op 6 juni 2006 10:25:08 schreef stecj366:Het kan dan wel zijn dat je met 1 frame meerdere gebruikers iets meedeelt, met een multicast dan (ik dacht MAC all 1's), maar je zal zowiezo toch 64 bytes minimaal moeten hebben. En anders staat er een mega fout in mijn cursus (die ik de afgelopen dagen onder de neus had :s ) en word ik graag gecorrigeerd...

Er is meer dan IEEE op ethernet;-)
Het gaat bij Ethercat niet om een multicast. Het is een apart protocol waarbij alle gebruikers "hun" deel van de boodschap in het voorbijkomen ook mogen aanpassen. Dit is een industrieel ethernetprotocol en niet de enige: er zijn in de industrie meer dan 20 ethernetprotocollen in omloop. We hadden het hiervoor nog over modbus: er is ook een modbus/tcp protocol over ethernet om er maar een te noemen.

Ethernet is overigens ook voor dit soort projecten best handig omdat je geheel conform IEEE 802.3af ook de voeding kunt meesturen over dezelfde kabel/connector. Het dient dan wel 48V te zijn waarschijnlijk om de stroom laag te houden.

silicon labs heeft een klein eternet controller ictje.
das heel eenvoudig te gebruiken.

aak zelf een kleinprotocolletje e jaag je data over twisted pair. klar is kees. gebruik desnods udp als protocol. das in 123 geimplementeerd jehebt alleen een mac address en header nodig ( en die zijn constant ) .
de rest is payload. en die chips hebben genoeg buffer aan boord om berichten te bufferen terwijl jij effe iets anders doet.

Op 6 juni 2006 17:05:10 schreef free_electron:...aak zelf een kleinprotocolletje e jaag je data over twisted pair. klar is kees. gebruik desnods udp als protocol. das in 123 geimplementeerd jehebt alleen een mac address en header nodig...

Gebruik jij soms ook een Sweex keyboard?

Op 6 juni 2006 12:24:41 schreef GJ_:
[...]
Er is meer dan IEEE op ethernet;-)
Het gaat bij Ethercat niet om een multicast. Het is een apart protocol waarbij alle gebruikers "hun" deel van de boodschap in het voorbijkomen ook mogen aanpassen. Dit is een industrieel ethernetprotocol en niet de enige: er zijn in de industrie meer dan 20 ethernetprotocollen in omloop. We hadden het hiervoor nog over modbus: er is ook een modbus/tcp protocol over ethernet om er maar een te noemen.

Ethernet is overigens ook voor dit soort projecten best handig omdat je geheel conform IEEE 802.3af ook de voeding kunt meesturen over dezelfde kabel/connector. Het dient dan wel 48V te zijn waarschijnlijk om de stroom laag te houden.

Maar Ethernet is geen protocol, het is een Datalink. En bij ethernet (dus echt echt echt ethernet, dat wij allemaal kennen) is de lengte minimaal 64 bytes. Dat is zo om op alle fysieke lagen waarop ethernet gespecifieerd is nog collisions te kunnen detecteren.

Ethercat, IP, IPX, ... zijn protocollen vanop layer 3. Dat houdt dus in dat de packetten wel kleiner dan 64 bytes (dus minder dan 46 byte data) KUNNEN zijn, maar da's op layer 3. Op layer 2 (en feitelijk ook op layer 1) zit u ethernet specificatie, met een eigen LLC en als MAC sublayer CSMA/CD.

IEEE803.2 is ook een ethernet specificatie, gelijkwaardig met ethernet. Er zit alleen een klein verschil in de opbouw van het frame -> in ethernet heb je een type, in 802.3 heb je een lengte veld van 2 bytes. IEEE803.2 bevindt zich ook niet op de LLC laag zoals ethernet dat wel doet, maar enkel op de MAC sublayer van Layer 2. De LLC laag is hier IEEE802.2.

Waarom nu dit allemaal:
Stel: je hebt een protocol (bv IP) die zich dus op laag 3 bevindt. Deze zal aan Layer 2 (Dus neem nu Ethernet) de data doorgeven die deze moet versturen. Daarin zal dan wel iets of wat van header in zitten die beslist naar wie/wat dat allemaal moet. Layer 2 zal dan de data van layer 3 inpakken in haar frame formaat (de Ethernet dus) met eigen headers, adressen, ... Dit frame formaat is bij Ethernet zowel als bij IEEE802.3 nu eenmaal minimum 64 bytes. Dus je zal altijd als je een ethernet frame verzend minimum 64 byte hebben, ook al verstuur je maar 1 byte data.

Maar het zou even goed ook kunnen dat Ethercat een specificatie is die zich ook laag 1 en 2 uitstrekt. Maar dat impliceert dan dat het GEEN ethernet is wat daaruit komt. Ethernet heeft een vast frame formaat, dat min 64 byte lang is. Anders is het echt geen ethernet.

En TCP is zowiezo al Layer 4 aangelegenheid, daar moet nog een Layer 3 tussen (netwerklaag) en een layer 2 (Datalink) en een layer 1 (physical).

Dat is de truuk van ethercat: veel bitjes voor diverse gebruikers verzamelen in 1 ethernetframe en dat 1 keer verzenden. Iedere gebruiker pakt wat ie nodig heeft. Zo kunnen enkele bitjes toch heel snel verstuurd worden. Dit wordt gebruikt om heel snel remote I/O van data te voorzien zonder dat naar iedere gebruiken een apart telegram verstuurd hoeft te worden.

Protocollen als Ethercat, Modbus/TCP en Profinet zijn ethernetprotocollen die gewoon over een normaal netwerk lopen. De gebruikers van deze protocollen zitten op hetzelfde touwtje als de "normale" PC's.

Ik ben echter bang dat dit verder niet echt interessant is voor de TS.

[Bericht gewijzigd door GJ_ op dinsdag 6 juni 2006 19:34:14 ]

Ethernet lijkt me mooi voor data tussen PC en microcontroller.
Ik heb liever synchrone data overdracht , zadat ik ook de interne klok kan gebruiken.
Als ik het goed heb gezien zijn bij RS485 de verbinding naar processor allemaal asynchroon
IIc en SPI zijn synchroon.
SPI krijg ik niet storings vrij en heeft per gebruiker een enable.

Op 5 juni 2006 09:47:37 schreef LaStei:
En het hangt ook helemaal af wat je over de bus wilt gaan transporteren, als het alleen een paar signaalgevers zijn of weinig data overstuurt, er zijn buffers voor de I2C zodat je een paar honderd meter kan overbruggen, wil je mat meer intelligente data overdracht, dan is een Modbus over Rs485 een goede optie, voor audio/video overdracht (misschien niet echt haalbaar met een PIC, maar als voorbeeld) toch een TCP/IP stack (met Cat trouwens ook RS485) implementeren....

Ff lezen dus!!! Om wat voor afstand gaat het? Een paar honderd meter is met de juiste buffers (P82B715, ziehttp://www.voti.nl/winkel/catalog.html?IC-P82B715-DIP) prima te overbruggen over CAT5 incl voeding bij niet al te hoge snelheid.

Een andere mogelijkheid is, als je persee synchroon wilt werken, om 2 RS485 buffers te gebruiken, eentje voor SCL en eentje voor SDA. Je moet dan wel de TX/RX van 1 van de buffers op het juiste omschakelen.

Houdt er ook rekening mee dat RS485 netjes afgesloten moet worden (voor cat5 120 ohm) aan beide uiteinden. Dan zou je in principe wel de maximale snelheid over de maximale lengte moeten kunnen halen.

Hangt ook van de afstand en de bekabeling af. I2C werkt (met buffer-ic) volgens Philips specs tot max 1 mijl (~ 1609m)