Identificatie chipjes voor eigen electronica project maken

[Sgrovert]

Ik ben al een tijdje bezig met een project om eigen verlichting te maken. Dit bestaat uit verschillende armaturen welke allemaal op elkaar doorgelust worden. Aan het begin van de lijn komt een controller te staan, die moet weten welke fixtures in welke volgorde in de lijn zitten. Uiteraard kan ik dit in de software gewoon elke keer opnieuw intypen, maar het is leuker als ik een systeem heb, wat zelf uit kan vinden welke fixtures in de lijn zitten.
Bij de bekabeling die ik gebruik, heb ik 1 ongebruikte ader. Samen de ground die voor de stroomvoorziening gebruikt word, geeft dit dus de mogelijkheid om data te versturen.
De lijn ziet er als volgt uit :
A1 -> A2 -> A3 -> Master

Op de master wil ik een array ontvangen met ongeveer de volgende data. Elke A is een andere fixture
A1:60 , A2:30, A3:80


De afgelopen maanden heb ik een beetje de Chinese webshops doorzocht en een hoop onderdelen gekocht waarbij ik denk dat het mogelijk is om dit te maken.
Als basis heb ik voor € 11 , 5Pcs 3.3V 8MHz ATmega328P-AU Pro Mini Microcontroller Board For Arduino , gekocht. Ik vermoed dat dit dus 5 Arduino Pro Mini zijn. Ze zien er in elk geval op het oog hetzelfde uit al weet ik dus niet zeker wat ik gekocht heb .

Voor mij is dit eigenlijk het eerste project waarbij ik code ga schrijven zonder dat ik op een beeldscherm het resultaat kan bekijken. Dit topic wil ik gebruiken om te documenteren wat ik aan het doen ben, en hopelijk hulp kan krijgen als ik even vast loop. Hopelijk is Electronica dan ook het juiste forum.
Ook heb ik een hoop extra electronica gekocht welke van pas kan komen bij het maken van mijn identificatie chipjes.

Op onderstaande foto staan alle middelen die ik tot mijn beschikking heb

Wat staat er op de foto :

• 5x Arduino Pro Mini
• 1x 5V 16M Pro Mini Microcontroller Board Improved AtMega328P 328
• 4 cijferig display
• 3 cijferige voltmeter om ergens aan te kunnen soleren
• Voeding + arduino experimenteer plankje
• 180KHz Adjustable Step-Down Power Supply Module Converter DC4-35V 5A For Arduino
• 8 Channel 3.3V To 5V Voltage Convert Module For Raspberry Pi 2&B+
• Assortiment weerstandjes 1/4 W van 2.2 t/m 2.2M ohm
• Raspberry Pi 2
• Normale arduino
• Oude ATX power supply, zodat ik een beschikking heb over verschillende spanningen
• Berg kabeltjes
• Multiemeter
• Soldeerbout

Ook heb ik een stappen uitgedacht in hoe ik dit project aan wil pakken :

1. Uitzoeken wat ik nu precies gekocht heb en hoe de Arduino te programmeren zijn.
   Ik heb helaas geen interface gekocht om de printjes aan de pc te kunnen koppelen. Echter heb ik wel een Raspberry Pi welke op 3.3 volt werkt. Deze wil ik gaan gebruiken om programma's op de Arduino te zetten.
   Volgens deze https://pay.reddit.com/r/...ng_my_hair_out_trying_to/ post moet het te doen zijn.
2. Test programma op arduino 1 laden, welke het ledje laat knipperen
3. 2 mini Arduino aan elkaar koppelen, en Arduino 2 het ledje van Arduino 1 aan letten zetten
4. 4 cijferige display aan grote Arduino koppelen, en een getal erop laten zien.
5. Arduino Mini aan grote Arduino koppelen, waarbij de kleine Arduino het getal voor het display bepaald.
6. Volledige systeem werkend maken, zodat de grote Arduino weet welke kleine er in welke volgorde aan gekoppeld zitten.
7. [optioneel]2 Way communicatie over 1 ader. Ik denk echter dat ik hiervoor extra componentjes nodig ga hebben.[/optioneel]

Hopelijk kunnen jullie mij een beetje op weg helpen. In dit topic zal ik mijn bevindingen en code plaatsen.

[Ploink]

Wil je een bestaand protocol gebruiken of zelf iets verzinnen?
Kijk bijvoorbeeld eens naar DMX512, modbus of 1-wire.

[wolly_a]

1. Arduino's kan je programmeren met de Arduino IDE. Een redelijk simpel werkje.
2. Dergelijk eerste stapjes-programma's zitten als voorbeeld bij de Arduino IDE.
3. Google even rond. Arduino's kunnen redelijk aanvoudig met elkaar communiceren via seriele verbinding, 1-wire, etc. Er is hier veel over te vinden op internet.
4. Wat voor display is het? i2c?
5. Zie 3.
6. Dat gaat je lukken!
7. Tweeweg communicatie werkt prima. Je moet even zorgen dat al je Arduino's in een groep een eigen adres hebben, zodat niet alles door elkaar roept.

Even voor mijn beeld. Waarom meerdere Arduino's? Eén Arduino kan al heel veel in z'n eentje. Meerdere maakt de uitdaging natuurlijk wel leuker!

Ps. Met hierboven. Modbus en DMX zijn mooie protocollen. Modbus is industrieel en biedt veel mogelijkheden. DMX komt uit de lichtgechniek en is wat beperkter. Het lijkt veel op RS422/RS485.

[ Voor 12% gewijzigd door wolly_a op 04-11-2016 21:57 ]

[r6turboextreme]

Leuk projectje! Hoe wil je Arduino's aan elkaar koppelen? Draadloos of bedraad? Ik zou daar even naar kijken ;-)

[Sgrovert]

DMX512 is niet geschikt. Dit werkt vanuit een master, welke meerdere slaves aanstuurt.

De reden dat ik meedere arduino's gebruikt, is omdat ik meerdere fixtures heb. Van te voren weet ik niet of ik 1 fixture, of 50 fixtures in mijn lijn gekoppeld heb. Elke fixture krijgt zijn eigen chipje, waarbij de laatste fixture zijn gegevens doorgeeft aan de voorlaatste, de voorlaatste geeft de gegevens van hemzelf en de laatste door aan de 2 na laatste etc. Op die manier weet de master vooraan precies wat er allemaal in de lijn zit.

Kwa display staat er op de chip 3641BS. Het zou een "4 Bits Digital Tube LED Display Module Board For Arduino" moeten zijn.

Ter verduidelijking, de arduino worden bedraad aangesloten.

[Damic]

Je moet altijd een master hebben, anders weten de slaves niet aan wie ze data moeten doorsturen

[Flake]

Yup, en die slaves zul je vooraf moeten opgeven. Als je dat niet wil dan zul je een vorm van adressering moeten inbouwen.

Hou er ook rekening mee dat communicatiebussen over lange afstand trammelant gaan geven, tenzij je een differentieel signaal gebruikt (RS485 bijvb). Je geeft ook niet aan of die lampen gelijkspanning gaan gebruiken of dat je PWM toepast, met PWM kun je meerdere storingen verwachten.

Voor die communicatiebussen en PWM zul je hoogstwaarschijnlijk extra schakelingen nodig hebben, en ik zou hier niet aan beginnen zonder scope en logic analyser.

[foekie01]

Mijn eerste gedachte is deze opstelling;

3 fixtures,genaamd F1, F2, F3
Tussen iedere fixture ligt er een data ader, in mijn voorbeeld genaamd D1.

D1 is een communicatie poort. De nieuwe fixture zegt "hallo ik ben aangesloten".

Je begint met fixture 1. Laten we zeggen die heeft adres 1. Ik sluit F2 aan. Deze zegt op D1 "ik ben aangesloten". F1 reageert volgens met zijn eigen adres (1). F2 weet dan dat hij zichzelf het adres 2 moet geven. F2 zendt zijn eigen adres richting F3 en dan zetF3 zijn adres op 3.

Ok.nu het voorbeeld opnieuw, maar ik zet er een fixture tussen. Ik wil een fixture F4 tussen F2 en F3 plaatsen.
F4 zegt tegen F2 dat hij er is. F2 stuurt adres 2 naar F4, F4 krijgt dan het adres 3 en zendt zijn eigen adres naar de volgende in de lijn (F3). F3 zet zichzelf dan op adres 4.

Dit geheel kun je simpel realiseren met één serieële poort per arduino.
De TX van F1 komt op RX van F2, de TX van F2 op de Rx van F3 enzovoorts..

In je arduino code check je op inkomende data, als die er is, stuur je jouw nieuwe adres door naar de volgende. Wil je daar nog data aan hangen (lichtsterkte?) dan kun je die comma seperated maken. Dit zie je o.a. ook bij het gebruik van RGB LED aansturingen

[Yoram]

Ik ben zelf ook veel bezig met dit soort projecten op hobby niveau en ben op dit moment aan het spelen met ws2812 ledstrips. Dus wat je beschrijft lijkt ontzettend op wat een ws2812 ledstrip doet. Daarop zitten leds met een ingebouwde driver. Daar heb je 1 data lijn die je naar elke led word doorgelust. De led pikt alleen zijn eigen data eruit en stuurt de rest van de data door naar de volgende led (correct me if i'm wrong).

Misschien kan je op die manier een een programma schrijven dat vanaf een master een lijst met adressen stuurt. Elke led unit pakt het eerste adres in de lijst en stuurt de rest door naar de volgende units. Iedere unit heeft dan z'n eigen adres en kan gaan luisteren naar de RGB waardes op een andere datalijn. Daar zou je dan makkelijk dmx voor kunnen gebruiken.

Als het helemaal mooi wilt maken gebruik je voor het adresseren van de led units RDM. Dat is een toevoeging aan het DMX protocol die voor terugkoppeling zorgt. Op deze manier zijn je led units ook nog een compatible met professionele licht apparatuur. Kan je het nog eens verkopen als het tof werkt

iig succes!!

[D4NG3R]

Sgrovert schreef op vrijdag 04 november 2016 @ 23:46:
DMX512 is niet geschikt. Dit werkt vanuit een master, welke meerdere slaves aanstuurt.

Aan het begin komt toch een controller te zitten die de boel herkent en aanstuurt? Dat is de master.

[Ploink]

Sgrovert schreef op vrijdag 04 november 2016 @ 23:46:
DMX512 is niet geschikt. Dit werkt vanuit een master, welke meerdere slaves aanstuurt.

De reden dat ik meedere arduino's gebruikt, is omdat ik meerdere fixtures heb. Van te voren weet ik niet of ik 1 fixture, of 50 fixtures in mijn lijn gekoppeld heb. Elke fixture krijgt zijn eigen chipje, waarbij de laatste fixture zijn gegevens doorgeeft aan de voorlaatste, de voorlaatste geeft de gegevens van hemzelf en de laatste door aan de 2 na laatste etc. Op die manier weet de master vooraan precies wat er allemaal in de lijn zit.

Je bedoelt dus dat er bij DMX512 alleen sprake is van eenrichtingsverkeer en dan weet de master dus niet welke slaves er aan hangen, tenzij je hem dat expliciet vertelt? Daar is wel een mouw aan te passen:

Wikipedia: DMX512
E1.11-2004, a revision of DMX512-A, also lays the foundation for Remote Device Management (RDM) protocol through the definition of Enhanced Functionality. RDM allows for diagnostic feedback from fixtures to the controller by extending the DMX512 standard to encompass bidirectional communication between the lighting controller and lighting fixtures. RDM was approved by ANSI in 2006 as ANSI E1.20 and is gaining interest.

[Sgrovert]

foekie01 schreef op zaterdag 05 november 2016 @ 16:53:

Dit geheel kun je simpel realiseren met één serieële poort per arduino.
De TX van F1 komt op RX van F2, de TX van F2 op de Rx van F3 enzovoorts..

In je arduino code check je op inkomende data, als die er is, stuur je jouw nieuwe adres door naar de volgende. Wil je daar nog data aan hangen (lichtsterkte?) dan kun je die comma seperated maken. Dit zie je o.a. ook bij het gebruik van RGB LED aansturingen

Dit is de oplossing welke ik nu wil gaan bouwen. Met deze methode kan ik straffeloos fixtures in en uit de lijn halen, waarbij de master altijd weet hoe de lijn eruitziet.

De oplossing van DMX met feedback was mij nog niet bekend en is zeker interessant. Echter zit ik dan dat geval nog steeds met het probleem dat ik de volgorde van fixtures niet meer. Deze volgorde is van belang om de stroom in de bekabeling softwarematig te kunnen limiteren. Er komen fixtures met voeding, en fixtures zonder voeding, welke de voeding van hun buren gebruiken.
Om te zorgen dat de voeding stroom in mijn kabels niet te groot word, moet ik weten wat er waar in de lijn zit, en zo nodig, bepaalde fixtures dimmen of uitschakelen.
Ik heb eerlijk gezegd niet 100% uitgezocht hoe de DMX extensies technisch in elkaar zitten, maar naar wat ik gelezen heb, zit hier geen mogelijkheid tot het detecteren van volgorde in. Dit ook omdat bij DMX alle fixtures in principe parallel aangesloten zijn.

[Sgrovert]

De eerste stapjes zijn gezet. De makkelijkste optie voor stroom was toch de 3.3 lijn van de oude voeding aftakken.
Gelijk uitgezocht hoe het volt meter display werkt, draadjes eraan gesoldeerd en bruikbaar gemaakt om in het breadboard te prikken. Omdat uitlezen van spanning op deze manier veel makkelijker werkt dan de universeel meter, hoop ik geen te hoge spanning om mijn componenten te zetten.
De voeding is op de arduino aangesloten en deze laat een stel ledjes branden.
Tot hier was het allemaal vrij makkelijk.

Probleem is dat ik geen eenduidig antwoord kan vinden hoe ik nu vanaf de Raspberry Pi de arduino programmeer. Volgens https://www.arduino.cc/en/Guide/ArduinoProMini zou hij te programmeren zijn moeten zijn mijn alleen de aansluitingen op de kopse kant.
Pwr, Gnd, Tx en Rx zijn makkelijk. Alleen spreekt elke tutorial (over arduino programmeren met Pi cmd line) die ik kan vinden over de reset pin. Volgens mij zit de reset pin niet op de kopse kant. Dit zou betekenen dat ik een extra draad aan moet sluiten.

Weet iemand of de Reset pin echt noodzakelijk om met een Pi te kunnen programmeren?
En zo ja, waarom kan en Pi niet de data zenden die de FTDI Basic Breakout Board klaarblijkelijk wel kan zenden.

[ Voor 6% gewijzigd door Sgrovert op 07-11-2016 20:53 ]

[itcouldbeanyone]

heb zelf wel eens een reeks modulles gemaakt op CAN, en door dat ik ze in serie zette(dus can in can out)
en de reset line bijvoegde. kon ik ze zelf hun ID laten aanmaken op basis van waar ze in de string zitten.
zodra de master geboot is, gooit hij reset line hoog. slave 1 start op met een standaard ID.
deze vertuurd via de bus dat ID. de master ziet dat en geeft hem een 1.
vervolgens gooit de slave de resetline van de volgende slave omhoog
binnen no trime had ik tientallen slaves die zichzelf aanmelde.
adresering deed ik dan via een publice ID zodat elke slave dit kon lezen, maar de eerste 2 bytes gaf aan of het voor die slave bedoelt was. zo kon ik dus heel wat slaves plug and play maken, zonder dat me canbus load te hoog werd.

me master wist dus hoeveel slaves op de bus zaten. slave dichste bij de master kreeg ID1 automatisch
de tweede slave ID2 enzevoort.
hierdoor hoefde ik alleen te zeggen ID + data om een specifieke slave aan te sturen
en van slave naar master public ID + data (master luister alleen naar het publice ID)
en als alle slave moesten luisteren, gebruikte ik andere unieke public ID's
zo kon ik alle slaves een bepaalde opdracht geven met een adresering.

om de CANbus load nog verder omlaag te helpen heb ik een algoritme bedacht die puiblice ID's op specifieke slaves aanmaakte als ik bijvoorbeeld 12 van de 50 slaves aan wou spreken.
inplaats van 12 keer een bericht te versturen. kon ik dit doen in 2 regels.
eerste regel gaf aan of de slave iets met een publice id moest doen of niet.
tweede regel had de data.
de master ging zelf uitrekenen of hij de slaves per slave ging aanspreken of dat hij dit moest doen via het algoritme. op basis van wat het minste data verkeer nodig achte

[ Voor 40% gewijzigd door itcouldbeanyone op 07-11-2016 23:58 ]

[Sgrovert]

De afgelopen weken wilde het niet echt opschieten. Veel uitgezocht maar weinig resultaat.

Echter heb ik vanavond voor het eerst gezien dat er communicatie tussen de Pi en de Arduino is.

De Setup
PI
pin 6 -> arduino gnd
pin 8 -> arduino Rx
pin 10 -> arduino Tx
pin 15 -> arduino rst

Op de Pi heb ik de stappen die genoemd worden op https://pay.reddit.com/r/...ng_my_hair_out_trying_to/
gevolgd.

Samen met de avrdude tool ben ik tot de volgende output gekomen :

sudo avrdude -p m328p -P /dev/ttyAMA0 -b 57600 -c arduino -vvvv

avrdude-original: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/root/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/ttyAMA0
Using Programmer : arduino
Overriding Baud Rate : 57600
/usr/bin/autoreset:16: RuntimeWarning: This channel is already in use, continuing anyway. Use GPIO.setwarnings(False) to disable warnings.
GPIO.setup(pin, GPIO.OUT)
done with autoreset
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
avrdude-original: Send: 0 [30] [20]
avrdude-original: Send: 0 [30] [20]
avrdude-original: Send: 0 [30] [20]
avrdude-original: ser_recv(): programmer is not responding
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude-original: Send: 0 [30] [20]

...

avrdude-original: ser_recv(): programmer is not responding
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude-original: Send: 0 [30] [20]
avrdude-original: Recv: . [14]
avrdude-original: Recv: . [10]
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : Arduino
Description : Arduino
avrdude-original: Send: A [41] . [80] [20]
avrdude-original: Recv: . [14]
avrdude-original: Recv: . [02]
avrdude-original: Recv: . [10]

...

avrdude-original: Send: A [41] . [98] [20]
avrdude-original: Recv: . [14]
avrdude-original: Recv: . [03]
avrdude-original: Recv: . [10]
Hardware Version: 2
Firmware Version: 1.16
avrdude-original: Send: A [41] . [84] [20]
avrdude-original: Recv: . [14]
avrdude-original: Recv: . [00]
avrdude-original: Recv: . [10]

...

avrdude-original: Send: A [41] . [89] [20]
avrdude-original: Recv: . [14]
avrdude-original: Recv: . [00]
avrdude-original: Recv: . [10]
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

...

avrdude-original: Recv: . [14]
avrdude-original: Recv: . [10]
avrdude-original: AVR device initialized and ready to accept instructions

Reading | | 0% 0.00savrdude-original: Send: u [75] [20]
avrdude-original: Recv: . [14] . [1e] . [95] . [0f] . [10]
Reading | ################################################## | 100% 0.01s

avrdude-original: Device signature = 0x1e950f
avrdude-original: Send: V [56] P [50] . [00] . [00] . [00] [20]
avrdude-original: Recv: . [14]
avrdude-original: Recv: . [00]
avrdude-original: Recv: . [10]
avrdude-original: safemode read 1, lfuse value: 0
avrdude-original: Send: V [56] P [50] . [00] . [00] . [00] [20]
avrdude-original: Recv: . [14]
avrdude-original: Recv: . [00]
avrdude-original: Recv: . [10]

...

avrdude-original: safemode read 3, efuse value: 0
avrdude-original: safemode: efuse reads as 0
avrdude-original: safemode: Fuses OK (E:00, H:00, L:00)
avrdude-original: Send: Q [51] [20]
avrdude-original: Recv: . [14]
avrdude-original: Recv: . [10]
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe
strace: |autoreset: Broken pipe

avrdude-original done. Thank you.

Deze output heb ik op de volgende manier verkregen, Eerst het avrdude commando aangeroepen, waarna het programma 10 request maakt. Als ik alles aangesloten laat, falen alle 10 de request. Tijdens bovenstaande request heb ik echter de stroom van de arduino afgehaald en er weer opnieuw opgezet.
Mijn theorie was dat de arduino tijdens het communiceren een keer gereset moet worden, om de communicatie op te zetten. Het opnieuw aansluiten van de stroom op de arduino resulteerde in attempt 4 daadwerkelijk in andere output.

Gezien de rest van de output vermoed ik dat het communiceren via RX en TX enigszins werkt. Ik vermoed dat de fout in het resetten van de arduino zit.
Reset script

/usr/bin/autoreset:16: RuntimeWarning: This channel is already in use, continuing anyway. Use GPIO.setwarnings(False) to disable warnings.
Het autoreset script is een script dat GPIO pin 22 van de PI gebruikt om de arduino te resetten. De code op regel 16 van dit (python) script :
14:def reset():
15: pin = 22
16: GPIO.setup(pin, GPIO.OUT)

Het lijkt erop dat dit script niks met GPIO pin 22 mag doen.

Hoe kan ik dit oplossen?

[Sgrovert]

Stap 1 en 2 zijn klaar.

Het programmeren via de raspberry PI heb ik niet voor elkaar gekregen. Daarom heb ik voor een paar euro een FTDI232 Ubs naar serieel converter besteld.
Gisteren is deze per post aangekomen en vandaag kon ik eindelijk mijn eerste eigen programma uploaden naar de arduino pro mini.

Binnenkort meer

[Stoney3K]

Is het erg als de fixtures allemaal een vast adres hebben, ook als ze er uit gehaald worden of weer er terug in geplaatst? Of wil je het adres van de fixtures af laten hangen van hun fysieke plaats, of volgorde in de bus?

Wat je bijvoorbeeld zou kunnen doen is een bus maken die elke fixture afzonderlijk weer doorgeeft en als een lus weer terugkomt (zoals bijvoorbeeld SPI of Interbus). Dan kan de master zien welke fixtures er op de bus zitten door te gaan zenden en te kijken hoe lang het duurt voordat de lus weer rond is, en hij zijn eigen bericht weer terug krijgt. Zolang je de berichten een vaste lengte kan geven, kun je de topologie van de bus hiermee redelijk snel uitvissen.

Het terugzenden doe je dan op een 'token ring' principe: Elke fixture krijgt om de zoveel tijd een gelegenheid om een antwoord terug te zenden, als dat antwoord verzonden is, is de volgende fixture aan de beurt. Interbus maakt bijvoorbeeld gebruik van dat principe.

-edit-

Het eerste wat je dus moet besluiten is hoe je je fixtures gaat onderscheiden. Wil je dat doen op het moment dat je het systeem opstart en de volgorde van de fixtures op de bus wordt bepaald? Of ligt er vooraf vast welk adres bij welke fixture hoort (maw. is het van te voren op de fixture in te stellen)?

De tweede vraag is dan of er een centrale aansturing is die altijd het initiatief neemt, of dat alle fixtures onderling gelijkwaardig zijn en dus elke fixture kan bepalen wanneer er verzonden mag worden. In het eerste geval hoef je je niet druk te maken over verschillende fixtures die allemaal beslissen om tegelijkertijd te gaan zenden, maar je hebt wel een centrale aansturing nodig die alle timing en verkeer afhandelt.

Als je de fixtures als een keten aan elkaar koppelt kun je dat op twee manieren doen: Alle fixtures aan elkaar op 1 draad (een werkelijke bus) of de uitgang van de ene fixture die weer de ingang van de andere fixture vormt. In beide situaties kun je tweerichtingsverkeer doen.

In het eerste geval gebruik je een transistor of een optocoupler om het signaal op de bus te zetten als een fixture wil verzenden, als de fixture niet aan het zenden is dan is de bus hoogohmig en kan een andere fixture (of de master) gaan zenden.

Wil je alle verkeer van en naar de master toe hebben, dan gaat het verloop dus als volgt: Master zendt data naar fixture A1, A1 zendt antwoord terug, daarna zendt de master zijn data naar A2, A2 stuurt antwoord, enzovoort.

Je zult dan wel een aantal trucs moeten toepassen om de adressen goed te krijgen als je die niet van te voren bepaalt.

Een andere manier is om de fixtures te benaderen als een soort schuifregister waarbij de ingang van de ene fixture aan de uitgang van de andere fixture zit aangesloten. Aan het einde van de lijn zit de uitgang van de laatste fixture aan de ingang van de master, waardoor je een gesloten ring krijgt. De bus ziet er dan zo uit:

code:

Master (tx) A1 -> A2 -> A3 ----+
   ^ (rx)                      |
   +---------------------------+

Als de master dan wil uitvissen welke fixtures er op de ring zitten, dan zendt hij een speciaal bericht wat door alle fixtures wordt doorgegeven en waarbij elke fixture er bijvoorbeeld een byte achter plakt waarin staat om welk fixture-type het gaat. Bij een ring die uit twee fixtures bestaat krijg je bijvoorbeeld het volgende:

De master verzendt eerst het volgende bericht, wat bij A1 aankomt:

code:

{ Master } { Discovery } { Einde bericht }

Het bericht bestaat hier uit twee onderdelen: Eerst wordt er aangegeven welke fixture het bericht heeft verzonden of doorgegeven, daarna volgt het type bericht (Hoe je de boodschappen logisch indeelt in bytes kun je natuurlijk zelf bepalen). De 'einde bericht' markering heb je alleen nodig als de bericht-onderdelen geen vaste lengte hebben.

A1 krijgt dit bericht binnen, en stuurt het volgende antwoord door naar A2:

code:

{ A1 } { Discovery } { A1 is een RGB fixture met nummer 1234 } { Einde bericht }

Waarbij A2 het bericht doorgeeft en verlengt:

code:

{ A2 } { Discovery } { A1 is een RGB fixture met nummer 1234 } { A2 is een bewegend lampje } { Einde bericht }

Als de master dit laatste bericht terug ontvangt dan weet hij precies welke fixtures er bestaan, en welke fixture zijn laatste buurman is geweest.

Ga je cyclisch verzenden, dan kun je zo gebruik maken van de array waar je het zelf al over had om tweerichtingsverkeer te doen. Iedere fixture weet namelijk welke plaats hij heeft in de bus (want iedere fixture weet wie zijn buurman is), en aan de hand daarvan weet elke fixture ook in welke volgorde de gegevens verwacht worden. Stuurt de master dus de gegevens uit jouw voorbeeld naar 3 fixtures:

code:

0x60 0x30 0x80

Dan kan elke fixture afzonderlijk antwoorden door 'zijn' byte in de array te vervangen met het antwoord en de rest gewoon door te geven. A1 geeft dan bijvoorbeeld antwoord (aan A2) met een status-code:

code:

0x00 0x30 0x80

Met het antwoord van A2 dat er op volgt:

code:

0x00 0x00 0x80

En A3 die tot slot naar de master stuurt:

code:

0x00 0x00 0x00

De andere fixtures hebben de data van A1 toch niet nodig, dus die geven ze blindelings door. Aan het einde van de rit krijgt de master dan elke keer een array met 3 antwoorden terug, en kan hij weer 3 stukken data verzenden, waarna het proces zich continu herhaalt.

[ Voor 69% gewijzigd door Stoney3K op 22-01-2017 18:12 ]