BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: Jeroen van Tol op 30 January 2009, 12:22:14
-
Laat ik maar met de deur in huis vallen: Ik heb de doos van pandora opengetrokken en weet nu even niet meer welke kant ik op moet zoeken om de uitgang weer te vinden...
??? ??? ???
Onlangs heb ik besloten om de treinhobby weer serieus op te starten. Maar omdat ik een heel ander mens ben dan pak m beet 15 jaar geleden kom ik nu het ene interessante onderwerp na het andere tegen, waar ik 'vroeger' nooit naar gekeken had... :-|
Laat ik beginnen met de 'deel-projecten' die ik ondertussen allemaal heb lopen. (En ik ben nog geen 2 maanden onderweg dus dan wordt jullie meteen duidelijk dat ik heeeeeeel veeeeeel zaken mijn interesse gewekt hebben!) Dit zijn dus projectjes naast het 'standaard' project om een zolderbaan te bouwen...
- DDL/DDW: Dit wekte mijn interesse omdat ik graag programmeer. Door de 'centrale' als software op de pc te programmeren heb je volledige zeggenschap over het dcc signaal (en dan op het nivo van nullen en enen) dat naar de baan gestuurd wordt. Het werkt alleen via de seriele port (RS232) en dat vond ik wat ouderwets. Middels een USB interface leek me 'moderner' maar die optie blijkt niet voorhanden... Zo kwam ik op het volgende project.
- OpenDCC: Hoewel dit weer een centrale in 'een doos' is wekte dit toch mijn interesse om verschillende redenen. Ten eerste is het een opensource project, en daar HOU ik van. :P Ten tweede is goed nagedacht over de (software)architectuur, prioriteiten, en tal van andere zaken (over bijna alles eigenlijk) wat geweldige input is voor mijn ideeen bij een centrale op de pc. En tot slot is het enerzijds een apparaat wat middels USB aan je pc gekoppeld kan worden en anderzijds een apparaat wat als output mooie dcc signalen levert aan een booster. Kortom, zij hebben bewezen dat je 'iets' kan bouwen wat middels de pc wordt aangestuurd, over een USB interface werkt, en dcc signalen genereert. (Oplossing voor bovenstaande project) Maar omdat het nog steeds een aparte centrale is blijf ik het gevoel houden dat ik geen volledige zeggenschap heb over het te genereren dcc signaal...
- Atmel: Door het opendcc project kwam ik bij Atmel uit omdat die chip het hart vormt van de opendcc centrale. Nu ben ik geen elektronika wonder dus daar ging bij mij al snel het licht uit. Omdat ik dat niet uit kon staan >:( heb ik een paar boeken gekocht en ben me wat in elektronische schakelingen gaan verdiepen. Reuze interessant allemaal!
- Zelfbouw USB Controllers: Leuk boek ('Schakelingen voor de buitenwereld - G.H.K. Dam) gevonden om zelf printjes te bouwen welke met de USB interface werken. Daar heb ik voorbeelden gevonden om data tussen de pc en het printje heen en weer te kunnen sturen. Dit heeft mijn interesse voor elektronika nog verder versterkt! Alleen hoe kan ik nu die data 'omzetten' naar een dcc signaal... ???
En toen stond ik dus ineens op een kruising met wel 100 mogelijke wegen om in te slaan! Ik geef het toe: Ik ben verdwaald :-|
Wat ik wil (maken of kant en klaar vinden, dat maakt me niet uit):
- Vanuit 'eigen' software (vergelijkbaar met DDL/DDW) zelf de data voor de dcc signalen (letterlijk in nullen en enen, geen voorgedefinieerde commando's) genereren en deze zo direct mogelijk naar de baan sturen over een USB interface.
- De USB interface moet de data vervolgens als een correct dcc signaal uitzenden naar de booster (of beter gezegd, de decoders).
- De USB interface moet het liefst ook in staat zijn om data van bijvoorbeeld terugmelders door te sturen naar de pc. (Wellicht kan dit achterwege blijven door daar bestaande interfaces voor te gebruiken, als het maar USB is)
Kortom, mijn doel is (nog steeds) om een 'centrale' te creeeren welke geen beperkingen kent. Nu niet en in de toekomst niet. Zodoende wil ik zoveel mogelijk intelligentie op de pc houden omdat dat het stukje is waar ik vrij gemakkelijk invloed op uit kan oefenen. DDW voldoet daarom precies aan mijn wensen maar werkt helaas niet over USB. Ik zoek dus een oplossing met dezelfde vrijheid maar dan via een USB interface... De opendcc centrale is mogelijk die oplossing maar dat hangt wel van een paar vragen af. ::)
Mijn vragen:
1. Heeft het zin om de intelligentie uit bijvoorbeeld de opendcc centrale naar de pc te verhuizen of kan ik die centrale volledig naar mijn hand zetten? (Kortom, heb ik de vrijheid om de Atmel chip te (her)programmeren om zo elk gewenst dcc signaal te kunnen genereren, nu en ooit?)
2. Is het mogelijk om de opendcc centrale uit te kleden zodat deze alleen nog bestaat uit de USB interface en de techniek om het dcc signaal te genereren?
3. Of kan ik in plaats van het uitkleden van die centrale beter een andere chip/print/module gebruiken/maken om te bereiken wat ik wil?
Ik weet dat wat ik wil niet 'gangbaar' is, een berg werk oplevert, wellicht niets toevoegt aan bestaande mogelijkheden enz. enz. maar het is voor mij de ideale manier om weer een berg bij te leren en me te verdiepen in nieuwe onderwerpen.
Ik zoek geen hapklaar antwoord (mag natuurlijk wel ;)) maar hoop dat er hier elektronika goeroes zitten die me allereerst in de juiste richting willen sturen en me eventueel daarna willen helpen met meedenken over de gekozen oplossing.
Tot slot: Ik had eerder een draadje gestart over een USB naar RS232 converter maar die oplossingsrichting blijkt niet uitvoerbaar... En ja, het is sneller/simpeler om een pc te gebruiken waar nog een RS232 op zit... Mijn 'besturings-pc' wordt echter een laptop en daar zitten ze zelden tot nooit op. Dus ik wil gewoon USB, of het nou handig is of niet... ;D
Jeroen.
-
Oh ja, ik vergeet nog te melden dat het uiteindelijke doel natuurlijk is dat allen die graag met DDW-achtige oplossingen aan de gang willen straks over een 'zelfbouw' print kunnen beschikken maken om dit via USB aan de praat te krijgen...
Zoals ik al zei: Ik HOU van opensource en alles wat ik leer/weet deel ik graag...
-
tja ...
Je wilt zelf het dcc signaal genereren, waarom zou je dat willen doen?
Je kunt de firmware van de opendcc centrale aanpassen, mocht je zelf extra dcc pakketjes op de rails willen zetten. Maar heeft dat zin? Ik denk het niet, want je zult dan ook zelf dcc decoders moeten maken. Op zich kan dat ook nog voor wissel en seindecoders, voor lok decoders zou ik het niet doen.
Ik heb het idee dat je zelf toevoegingen wilt maken op het dcc protocol. Ik denk dat dat geen goed idee is.
De meeste zaken zit al in het protocol, dus daar hoef je het protocol voor overhoop te halen. Wat mis je b.v.?
Dan heb je het over de open dcc centrale uitkleden.
Je kunt besluiten om de s88 interface niet aan te sluiten, je kunt het programmeerspoor niet voorzien van componenten, en je hoeft ook de xpressnet interface niet te bouwen.
Wat hou je dan over? Een Atmel chip met een beperkte dcc booster die je naar keuze via rs232 of via usb->rs232 kunt aansturen.
Even nog je antwoorden:
1) Er zit een jtag aansluiting op de opendcc centrale, je kunt dus ten alle tijden nieuwe firmware op de chip zetten. Er zit ook een seriele bootloader in de chip, kan dus ook zonder jtag adapter....
2) Als je de componenten weglaat kleed je de centrale uit
3) zie 2.
Guus
-
Hoi Jeroen,
Als ik je verhaal zo lees, zou ik gaan voor een Microcontroller met ingebouwde USB ( Atmel / PIC ) die de DCC refreshstack beheert en van daaruit het DCC signaal genereert.
Via de USB en een mini protocolletje moet je dan opdrachten aan de refreshstack kunnen toevoegen en er uit verwijderen.
Al de rest kun je dan gewoon vanuit je PC regelen.
Dus printje met USB-microcontroller en een booster-driver en ackdetector-ingang ontwerpen en programmeren.
Iets dergelijks zal niet veel meer kosten dan een standaard US-Serial kabel ;)
Grtzz,
Karst
-
@Guus
Ik had mijn hoop een beetje op jou gevestigd... Ik had op je site gezien dat je stukken van de decoder achterwege had gelaten (Ja de USB, precies wat ik juist wilde behouden ;D) en hoopte dat je wellicht de elektronika kennis had om te kunnen zeggen of ik zo ook andere delen weg kon laten...
Jij zegt eigenlijk dat wanneer ik die centrale uitkleedt, dat ik dan min of meer alleen de Atmel over hou? Dus 'achter' de chip zit niets meer wat het dcc signaal 'bewerkt'?
Overigens is het niet de bedoeling dat ik 'eigen' dcc signalen ga verzinnen. Het gaat me er om dat decoders steeds meer kunnen en ik de mogelijkheid wil hebben om mijn centrale steeds op die nieuwe mogelijkheden aan te kunnen passen.
@Karst
Het printje met USB microcontroller denk ik gevonden te hebben in de EZ-USB starterkit van Anchorchips (AN2131 met 8051 compatible kern). Is dat een begin?
Daar zit namelijk ook meteen een driver bij met broncode...
Ack heb ik iets over gelezen... Iets met status? Moet ik opnieuw lezen ;D
Booster-driver? Volgens mij zit in die term besloten waar ik mijn vinger steeds niet op kan leggen... Is dat het stukje wat 'feitelijk' de stack leest en daaruit digitale pulsen genereert? Zal overigens wel een printje worden met eigen voeding om het signaal sterk genoeg te krijgen?
Ik ga met even worstelen met de termen die je allemaal noemt. Misschien kan ik er dan iets meer op antwoorden dan: Uhhh... Hoeveel?
Wordt vervolgd...
-
Karst,
Na weer wat zoeken en lezen valt me op dat jij duidelijk veel meer over dit soort zaken weet...
Ik daarentegen begeef me op gebied waar ik duidelijk niet genoeg van weet. Bij Atmel is de keuze voor een geschikte microcontroller al bijna niet te doen. Lees ik vervolgens hoe ik met dat ding om moet gaan dan begrijp ik alleen het stuk over het programmeren van het kreng. Al moet ik de assembler boeken er dan wel weer op naslaan. Maar alles daaromheen gaat duidelijk boven mijn pet :'(
Ga ik daar ooit uit komen denk je?
En zo niet, weet jij niet iemand die (zonodig tegen betaling) zo'n ontwerp wil maken?
Groet,
Jeroen.
-
Hoi Jeroen,
Nou, bij Atmel hoeft die keuze helemaal niet moeilijk te zijn... Eigenlijk verre van bijna niet te doen.
Het assortiment is minder breed dan dat van Microchip volgens mij. Echter denk ik dat in jouw geval toch een beetje de 'onwetendheid' mee speelt. Maar... Alles is te leren... ;)
Waarom assembler boeken? Je kan met AVRStudio i.c.m. WinAVR (GCC compiler en wat libraries) gewoon probleemloos in C programmeren. Kennis van assembler is niet vereist, maar kan toch wel eens handig zijn bij debug-werkzaamheden en optimalisaties. Echter geen noodzaak. ;)
AVRStudio en WinAVR zijn overigens beiden GRATIS.
Enige kennis van 'alles daaromheen' is wel handig.
Maar, ik zou zeggen... Haal een experimenteerbordje (breadboard) in huis, wat extra onderdelen t.b.v. spanningsvoorziening e.d., een programmer en ga er mee aan de slag. Informatie en beginners-cursusjes / oefeningetjes zijn er her en der ook wel te vinden. Mogelijk ook in boek-vorm...
Het projekt OpenDCC waar ook Guus het over had, is misschien ook wel een leuk gevalletje voor je om wat mee te experimenteren e.d... Er zijn hier overigens op het forum al een aantal draadjes meer over zelfbouw centrales, zoek maar eens op 'zelfbouw centrale'. Mogelijk kun je daar ook nog wat handige/nuttige info uit halen...
Groetjes,
Dave
-
Dave,
Leuk om te horen dat het vertrouwen er is ;D ;D ;D
Ik heb bij Atmel wel een keuze kunnen maken (weliswaar niet bepaald een weloverwogen keuze, maar het leek me te voldoen) namelijk de AVR32UC3A.
Vervolgens kwam ik er inderdaad achter dat ik het beste met een evaluatiekit aan de slag kon gaan (dat bedoel je toch met breadboard?) en kwam zodoende uit de op EVK1100. Vervolgens wil je dat kopen... (waar???)
Niet heel erg dat overal een prijskaartje aan zit, maar om 'blind' dit idee uit te proberen gaat me ook wat ver... Vooral als ik merk dat ik ook nog moet 'leren' welke elektronika er nog omheen moet. Heb bijvoorbeeld geen idee hoe ik een 'uitgangssignaal' van die microcontroller kan versterken (als dat al nodig is, moet ik ook nog uitzoeken ::)). Ook weet ik nog niet of ik dat signaal zo kan gebruiken naar de booster toe of dat ik het nog moet 'nabewerken' met andere elektronika...
Hahaha, je hoort het... Er is een beetje teveel wat ik niet weet. ;D
Maar okee, ik vind het zeker interessant genoeg om dat allemaal uit te proberen... Zou alleen fijn zijn als ik iets gerichter kon werken...
Oftewel: Bovenstaande microcontroller, is dat wat? En zo niet, andere opties die ik kan onderzoeken?
Groet,
Jeroen.
-
De AVR32 serie is een 32bits microcontroller. Ik denk voor het doel wat je hebt, misschien een behoorlijke over-kill.
Met een AVR uit de AT90USB serie (8bits microcontrollers) gaat dit ook prima en scheelt weer in de totale kosten.
Hier vindt je overigens een handig overzichtje (en ook veel andere AVR info / projektjes):
http://www.avrfreaks.net/index.php?module=Freaks%20Devices&func=viewDev (http://www.avrfreaks.net/index.php?module=Freaks%20Devices&func=viewDev)
Met een breadboard bedoel ik een experimenteer-bordje, zo'n wit ding met allemaal gaatjes (http://nl.wikipedia.org/wiki/Breadboard (http://nl.wikipedia.org/wiki/Breadboard)).
Een evaluatiekit kan ook, echter als je foutjes maakt in je aansluitingen/hardware-ontwerp kan dat een evaluatiekitje kosten. Op een breadboard meestal alleen een paar onderdeeltjes. Je kunt op een breadboard ook vanalles testen en er mee experimenteren. En een stuk goedkoper dan een evaluatiekitje. Onderdeeltje defect, prop er een nieuwe in. Schakeling uitbreiden of aanpassen is hiermee zonder soldeerwerk ook kinderspel.
Een evaluatiekitje is vaak wel compleet met de diverse aansluitingen welke je op een breadboard zelf zal moeten maken. Dat is dan weer een groot voordeel. Verder kun je je evaluatiekitje ook aansluiten op een breadboard voor het testen van je eigen elektronica e.d.
Uitgangssignaal versterken kan overigens op verschillende manieren, maar ook daarover is weer vanalles te vinden op internet. Er zijn genoeg mensen die zich hier ook mee bezig houden en hun schema's e.d. online zetten. Ook daarvan kun je leren... Wederom is OpenDCC dan weer een goed voorbeeld. ;)
Ik zou i.i.g. eens beginnen met VEEL lezen en kennis vergaren, kijken hoe anderen dit doen en beginnen met een eenvoudige 8bits microcontrollertje, een ISP programmertje (mySmartUSB van myAVR.de b.v.) en een breadbordje.
Groetjes,
Dave
-
Pfff, nou de sprong is genomen...
Weer een hobby er bij! ;D
Ik heb besloten om eerst maar aan de slag te gaan met de simpelere ATMega8 om uit te proberen hoe het allemaal werkt, als ik dat eenmaal snap probeer ik het wel hogerop...
Via avrfreaks (goeie tip Dave!) bekeken waar ik moet beginnen en meteen maar wat spullen bij conrad besteld. Ben heel benieuwd!
Ik hou jullie op de hoogte!
Jeroen.
-
Misschien loop je iets TE hard van stapel, maar ach... Leergierigheid heeft mij ook altijd geholpen. ;)
Nog een paar tipjes voor je 1e experimenten:
- KISS !!! Oftewel: "Keep It Simple, Stupid" en "Keep It Short and Simple"
- Let op de max. toelaatbare stroom per pin en het totaal (zie datasheet van de AVR).
- Let op met het programmeren van fuse-bits. Als je bepaalde fuse-bits verkeerd insteld, loop je het risico dat je niet meer via ISP kunt programmeren, enkel nog via serieel of parallel programmeren op een iets hogere spanning.
- Goedkopere AVR's en wat andere handige componenten en gereedschapjes: www.aavrs.nl (http://www.aavrs.nl) (geen hoge verzendkosten bij enkele onderdeeltjes en een TOP!-service)
Verder... Van je fouten kun je leren, dus doe dat dan ook. ;D
Groetjes,
Dave
-
@Dave
Ik loop altijd te hard van stapel... Ben nu eenmaal een enthousiast typje ;D ;D ;D
Zat al even te twijfelen of ik dit (zoveelste) project zou aanpakken zoals je gaandeweg het draadje kunt zien, maar als iemand dan maar half zegt dat het zou moeten kunnen dan wil ik het voor elkaar krijgen ook!
En ik denk dat een beetje kennis op elektronicavlak op de spoorbaan altijd van pas kan komen...
Groet,
Jeroen.
PS: Als het niet lukt weet ik je te vinden! 8)
-
;D ;D ;D
Ben blij dat 't i.i.g. niet aan mij ligt als 't jou niet lukt. 8)
Een complete zelfbouw centrale is hier reeds een tijdje in bedrijf. ;)
Echter heb ik daar toch ook wel een tijdje over gedaan om ervan te maken wat het nu is.
Een beetje kennis op elektronicavlak is overigens bij gebruik van AVR's en het bouwen van een centrale toch ook wel handig. ;)
Groetjes,
Dave
-
Als ik je verhaal zo lees, zou ik gaan voor een Microcontroller met ingebouwde USB ( Atmel / PIC ) die de DCC refreshstack beheert en van daaruit het DCC signaal genereert.
Via de USB en een mini protocolletje moet je dan opdrachten aan de refreshstack kunnen toevoegen en er uit verwijderen.
Al de rest kun je dan gewoon vanuit je PC regelen.
Lijkt me de *the way to go* te zijn, echter ik zou nog één stap verder afzakken, namelijk de microcontroller enkel en alleen een zuivere bitstream laten opwekken zonder hier direct een protocol aan te koppelen. Dit laat toe om bvb. in een later stadium ook andere, niet DCC, protocollen toe te voegen (Motorola, MFX, ...). De microcontroller is dan als het ware een zuivere bitstream engine die enkel moet weten hoe lang een bepaalde bit moet duren en ook dat wordt natuurlijk meegegeven via de USB.
Hetzelfde principe pas ik toe in mijn commandstation. Weliswaar gebeurt het opwekken van het DCC signaal en Marklin/Motorola bij mij door dezelfde microcontroller maar principieel kan het genereren van de zuivere protocol onafhankelijke bitstream verplaatst worden naar een andere microcontroller
mvg,
Patrick Smout
-
Ik zou beginnen met het nabouwen van een dcc decoder.
Gebruik dat als leermoment...
Ga daarna te rade of het waard is om 3 jaar tijd te investeren in iets dat je 'gewoon kunt downloaden'.
Ik ga er zomaar van uit dat OpenDCC in de toekomst bij gewerkt wordt met de laatste mogelijkheden. Ook MR-Direct, de centrale van Dave en de centrale van Patrick zullen bij blijven. Robert Evers heeft ook nog een zelfbouw centrale.
Die 3 jaar tijd kun je ook ergens anders voor gebruiken.... een mooie baan bouwen bijvoorbeeld.
-
Het belooft een leuk projectje te worden!
Ik heb me de afgelopen week heel wat verder verdiept in de wereld van de electronica. Een GROTE hulp daarbij waren de boeken van Tony R. Kuphaldt: "Lessons in Electric Circuits" (gratis en on-line te vinden op [www.ibiblio.org/obp/electricCircuitsurl][/url])
Het begint op een goed te volgen nivo over wat basiszaken (wet van Ohm, e.d.) maar zodra je wat verder komt is het best pittig te noemen. Ondanks dat is het op een manier geschreven dat een beetje doorzetter er uiteindelijk wel uit moet kunnen komen. Overigens heb ik niet alles uit de boeken doorgenomen maar met name de stukken die ik interessant vond. (DC, Semiconductors (zware kost!), en Digital)
Met deze info ga ik de openDCC decoder eens onder de loep nemen, alsmede de daarbij genoemde zelfbouw booster.
Tevens heb ik de spullen binnen van Conrad (Atmel/EVK en diverse onderdelen) ;D ;D ;D dus daar kan ik ook mee gaan experimenteren. (info daarover heb ik van AVRFreaks op http://www.avrfreaks.net/wiki/index.php/Main_Page (http://www.avrfreaks.net/wiki/index.php/Main_Page))
Inmiddels heb ik gezien dat wat ik wil bouwen vrij 'simpel' te doen moet zijn. (In mijn geval niet zo simpel natuurlijk omdat ik niet alle benodigde kennis bezit 8)) Gelukkig heb ik een neef welke ingenieur is en me met raad en daad kan bij staan, maar ik ga proberen het zoveel mogelijk zelf uit te vogelen.
Ik ga enerzijds een simpel USB interface maken zoals ik dat gevonden heb in een elektuurboek. De data vanuit de pc (ik noem het maar even de seriele bitstream) wordt door de interface opgevangen in een tweetal FIFO buffers (de grootte is afhankelijk van de hoeveel vertraging die de USB bus maximaal kan oplopen). Eén buffer voor dcc commando's met normale prioriteit, en één voor hoge prioriteit (te bepalen door de software). Bestaande software kent dit onderscheid niet dus zorg ik er voor dat data standaard in de normale buffer terecht komt.
Tussen de zelfbouw booster(s) en de USB interface komt het "dcc - timer" circuit. Dit circuit leest gegevens uit de buffers van het USB interface en sluist deze data 1 op 1 door naar de zelfbouw boosters. Eigenlijk is de enige functie van dit circuit om het doorgeven van de data op basis van een klokpuls te laten verlopen, zodat de dcc signalen de juiste timing krijgen. Dit laatste ga ik uitvoeren met een simpele Atmel.
Is dat eenmaal gelukt kan ik proberen om de functies van het USB interface en de dcc-timer samen te voegen tot 1 circuit met een slimmere microcontroller zoals Karst voor stelt. Ik wil daar echter eerst wat meer ervaring voor hebben en tot die tijd zoveel mogelijk bestaande circuits aan elkaar knopen.
De weg lijkt lang maar als ik zie hoe ver ik nu al gekomen ben in een paar weken tijd dan denk ik dat ik dit circuit nog dit jaar werkend moet kunnen krijgen...
Overigens even terugkomend op de term "dcc-refresh stack". Hoewel ik stacks ken vanuit het programmeervlak zegt dit me nog steeds niet zo heel veel. Ik gok dat ik dat tegen ga komen bij de openDCC centrale maar even vooruit lopend daarop: Wat bedoelt Karst daar precies mee?
Hoe dan ook, ik hou jullie op de hoogte!
Groet,
Jeroen.
-
Jeroen,
wat Karst wil zeggen is dat het commandstation periodiek DCC paketten met snelheidsinfo en de status van extra functies periodiek gaat versturen voor rijdende locs. Dit heeft als voordeel dat Locs die te maken krijgen met een kortstondige spanningsonderbreking toch terug de juist info ontvangen zonder dat het command station deze info opnieuw ontvangt van de host controller (PC of handregelaar). Zuiver software technisch gesproken is de term refresh stack eigenlijk niet correct omdat de voor de hand liggende implementatie niet echt als een stack werkt. Een implementatie volgens een Circular Linked List geeft de gedachte beter weer.
mvg,
Patrick Smout
-
Zuiver software technisch gesproken is de term refresh stack eigenlijk niet correct omdat de voor de hand liggende implementatie niet echt als een stack werkt. Een implementatie volgens een Circular Linked List geeft de gedachte beter weer.
Helemaal mee eens Patrick :) ( goede uitleg overigens :D )
Grtzz,
Karst
-
Hier zie je een scherm afdruk van het sniffen van een dcc signaal:
(http://www.piksov.com/pictures/showdcc.jpg)
Op dat moment zaten de adressen 94, 1,2, 4, 5, 6, 7 en 3 in de refresh stack.
-
Dus dat bedoelden jullie met refresh-stack... In mijn geval is die term dan zo gek nog niet. Alleen moet ik het dan een refresh / new dcc-signal stack noemen. ;D
Mijn buffers/geheugen werken (lees: moeten gaan werken ;)) namelijk als een stack van waaruit de signalen volgorderlijk uitgevoerd worden. Die stack wordt door de pc met ofwel herhalingen, ofwel nieuwe signalen gevuld.
Ik heb er aan gedacht om de herhalingen door het dcc-timer circuit af te laten handelen (zoals in jullie beschrijving) maar ik kwam er achter dat ik daar niet heel veel mee won...
Het probleem was namelijk dat ik in dat geval moest zorgen dat bij een crash van de pc het circuit moest stoppen met herhalen.
Kortom, of ik stuur regelmatig een signaal dat de pc nog werkt, of ik stuur gewoon de herhaling (of het nieuwe signaal).
Betekent weliswaar meer dataverkeer maar het betekent ook dat ik geen grote buffers nodig heb op het dcc-timer circuit, ongeacht met hoeveel treinen ik rij. (Op de pc een herhalingstabel bijhouden is qua geheugenbeheer wat flexibeler)
Eind goed, al goed. De "dcc-refresh stack" heeft in ieder geval een plekje gekregen in het ontwerp. ;D ;D ;D
Bij de EVK van Atmel zat trouwens "gratis en voor niets" een AT90S8515 (lees: ik had m niet verwacht... want voor de prijs van de EVK kunnen ze inderdaad wel zo'n PIC kado doen 8)).
Leuk speelgoed! De eerste programmeerstapjes zijn inmiddels genomen. Het is even wennen ten opzichte van 'normaal' programmeren maar al met al is het allemaal goed te volgen.
Ook 'begrijp' ik nu de schema's van de opendcc centrale en booster een stuk beter. Dat wil zeggen dat er nog maar weinig componenten genoemd worden die ik niet begrijp en ook is me duidelijk aan het worden waarom op bepaalde plaatsen een component zit. (Pull-up/down weerstanden, condensatoren enz.)
Heb met componentjes van het weekend een 'wekker' gemaakt (dat wil zeggen, punaises op een plankje geprikt waartussen de componenten gesoldeerd zitten bij wijze van printplaat), welke begint te jengelen zodra het licht wordt! Volgende stap is kijken of ik een PIC kan toevoegen aan het verhaal. (Moet ik wel over stappen op echte printplaten want dat gaat me nie lukken nie met punaises ;))
Al met al, we zitten op de goede weg!
Groet,
Jeroen.
-
Jeroen,
je zal in elk geval toch een aardig stukje software handshaking in moeten bouwen om het dataverkeer tussen de Host en de microcontroller over de USB in goede banen te leiden. Als de host te snel zend (en dat is met USB helemaal geen probleem) dan heb je binnen de korste keren een buffer overflow. Zend je te traag dan riskeer je een buffer underflow met als resultaat geen (digitaal) signaal (of DC) wat ook niet als prettig ervaren wordt door een decoder.
Je kan dit probleem mooi vergelijken met de buffersturing in een softwaretool voor het branden van een CD.
Als ik jou was zou ik me hier eerst op concentreren. Bij wijze van experiment de buffer in de microcontroller voor 50% gevuld houden ongeacht de load van de PC. Lukt dit niet dan hoef je niet echt verder te gaan dunkt mij.
mvg,
Patrick Smout
-
Patrick,
Buffer underruns en overflows zijn reeds ondervangen in het ontwerp. Een en ander zal nog wel met live-experimenten getoetst moeten worden maar ik heb goede hoop.
De hamvraag in het verhaal is hoeveel tijd USB maximaal nodig heeft om te reageren. Qua data-overdracht is de USB heel veel sneller dan noodzakelijk maar is de USB ook in staat om bijvoorbeeld altijd binnen een seconde te reageren op een commando vanuit de software? Om alles mogelijk te maken wil ik het liefst zelfs minimaal 2 keer per seconde pakketjes over de USB kunnen versturen.
De reden daar voor ligt in het feit dat er volgens mij op de baan al behoorlijk wat mis kan gaan als treinen meer dan een seconde 'onbeheerd' rond kunnen rijden. (bv. bij pc crash)
Kijk ik naar het plaatje waarbij je via de pc een 'normale' centrale aanstuurt (en bijvoorbeeld een RS232 - USB converter gebruikt) dan lijkt me datzelfde vraagstuk ook te spelen. Dat is dan ook de reden dat ik goede hoop heb dat het zou moeten kunnen.
De data die ik over de USB ga sturen is weliswaar anders dan bijvoorbeeld LocoNet opdrachten maar je zult nog steeds 'op tijd' de opdrachten bij je treinen moeten kunnen krijgen, toch?
Er vanuit gaande dat de USB inderdaad snel genoeg zal reageren heb ik het volgende op underruns en overflows bedacht:
Een underrun is voor mij reden om aan te nemen dat er met de pc iets mis is. Oftewel, loopt de buffer leeg dan zal het circuit uit zichzelf ongeveer een halve seconde lang "Idle packets" gaan genereren. Is de buffer dan nog steeds leeg dan volgt ook weer vanuit het dcc-circuit zelf een broadcast signaal met "alles stoppen".
De doorvoersnelheid van dcc-signalen ligt tussen de 5247 en 8046 bits per seconde (afhankelijk van de verdeling in 0 en 1 bitjes) dus met volle buffer (in totaal 512 Bytes = 4096 bits) kunnen de treinen maximaal 0.75 seconden rijden. Tel daar de 0.5 seconde "Idle packets" bij op en de treinen schieten na maximaal 1.25 seconden in de noodrem.
Overflow van de buffer zal regelmatig voor komen omdat ik doorlopend pakketjes van 128 Bytes ga sturen. Een lege buffer is dus vol na 4 pakketjes. Zorgt het 5e pakket voor een overflow dan gaat de pc een pauze inlassen van 0.1 seconde, alvorens een nieuw pakketje wordt gestuurd.
Omdat er steeds gewerkt wordt met pakketjes van 128 Bytes wordt het geheugen in 4 'slots' verdeeld. Een overflow betekent dus dat er geen vrije slot was. Ik heb dan ook geen last van 'halve data' in de buffers.
Je ziet het, aan het meeste is gedacht...
Maar een live-test zal dit natuurlijk nog wel 'even' moeten bevestigen. ;D
Groet,
Jeroen.
-
Jeroen,
en hoe weten we dat het 5e pakketje wel of niet voor een overflow zorgt? Software handshaking op de application layer of via de ACK/NAK/STALL van USB? Blinde timing?
mvg,
Patrick Smout
-
Patrick,
De term 'overflow' is technisch misschien niet helemaal correct omdat ik softwarematig ga 'voorkomen' dat er een overflow plaats vind.
Het verhaal werkt met 2 pointers, we noemen ze pointer-In en pointer-Out. Beide pointers tellen van 1 tot 4 en dan weer naar 1. Deze verwijzen beiden naar de 4 geheugenslots van elk 128 Bytes.
In volgorde gebeurt er bijvoorbeeld het volgende:
- Pointer-Out wijst naar slot 1 (gegevens uit slot 1 worden op dit moment verwerkt tot dcc-signaal)
- Pointer-In wijst naar slot 4 (het eerste 'lege' slot, dus 2 en 3 zijn inmiddels gevuld)
- Er 'arriveert' een pakketje van 128 Bytes
- Pointer-In wijst niet naar hetzelfde slot als pointer-Out: Dus pointer-In wijst naar een beschikbaar slot.
- De 128 Bytes worden opgeslagen in slot 4
- Antwoord terug naar pc = 'OK'
- Pointer-In wordt opgehoogd en wijst nu naar slot 1
- Inmiddels is slot 1 omgezet naar dcc-signalen.
- Pointer-Out wordt met 1 opgehoogd en wijst nu naar slot 2.
- Dit is niet gelijk aan pointer-In: dus slot 2 is niet 'leeg'.
- De verwerking van slot 2 begint
- Er arriveert weer een pakketje van 128 Bytes
- Pointer-In wijst weer niet naar hetzelfde slot als pointer-Out: Dus pointer-In wijst naar een beschikbaar slot.
- De 128 Bytes worden opgeslagen in slot 1
- Antwoord terug naar pc = 'OK'
- Pointer-In wordt opgehoogd en wijst nu naar slot 2
- Er arriveert weer een pakketje van 128 Bytes
- Pointer-In wijst nu wel naar hetzelfde slot als pointer-Out: Buffer is vol!
- De 128 Bytes worden niet opgeslagen in slot 2
- Antwoord terug naar pc = 'FOUT: Overflow'
- Pointer-In wordt niet opgehoogd en wijst nog steeds naar slot 2
- Inmiddels is slot 2 omgezet naar dcc-signalen.
- Pointer-Out wordt met 1 opgehoogd en wijst nu naar slot 3.
- Dit is niet gelijk aan pointer-In: dus slot 3 is niet 'leeg'.
- De verwerking van slot 3 begint
(We gaan slaan even een stukje over, slot 3 en 4 zijn inmiddels omgezet en door een pc-crash zijn er geen nieuwe pakketjes binnengekomen)
- Inmiddels is ook slot 1 omgezet naar dcc-signalen.
- Pointer-Out wordt met 1 opgehoogd en wijst nu naar slot 2.
- Dit is wel gelijk aan pointer-In: dus slot 2 is 'leeg'.
- Er worden tijdelijk Idle packets gegenereerd.
Hoe ik 'OK' danwel 'FOUT' terug moet communiceren over de USB heb ik nog niet uitgezocht. Daar zal in het protocol/driver een voorziening voor moeten komen. Dat gedeelte zie ik (nog) niet als heel erg spannend... Ik moet eerst nog een keuze maken mbt tot welk IC ik ga gebruiken voor de USB communicatie (alles in één? of aparte IC voor puur USB communicatie zoals Anchorchips? Weet het nog niet... ???)
Daarna moet ik dan nog aan de slag met MS-SDK om een driver/protocol te fabriceren.
Vooralsnog ben ik nu alleen bezig om uit te zoeken hoe ik de AVR moet programmeren om met het bovenstaande pointer verhaal gegevens uit de buffer te lezen en deze om te zetten in dcc-signalen. Waarbij het omzetten niet veel meer is dan steeds clock-cycles van de AVR tellen tot 58 microseconden en dan, al naar gelang het een '0' of '1' moet zijn, wisselen van hoog naar laag na 1 of 2 x het klokje rond.
Eerstvolgende stap is kijken of ik niet liever met 'WinAVR' aan de slag ga want programmeren in Assembler beheers ik nauwelijks. Nu is C ook niet mijn 'moerstaal' (ben meer van de VB) dus dat wordt sowieso weer een boek lezen! ;D ;D
We komen er wel...
Groet,
Jeroen.
-
Eigen WDM driver lijkt me overkill. Zoek maar eens wat op over de USB HID Class (met eigen HID USB device). Kan je met standaard Win driver zo aan de slag ... of natuurlijk via de driver(s) van FTDI als je deze chips gebruikt.
mvg,
Patrick Smout
-
Patrick,
Dave had me ook al in de richting van ftdi laten kijken. Is inderdaad een veel makkelijkere optie...
Nu heeft Karst me overigens weer op een idee gebracht om eens naar Ethernet/LocoNet te kijken... Wordt het misschien weer een heel ander verhaal. ::)
Gelukkig heb ik me handen (nog) vol aan het stuk daarna dus de keus is nog open.
Overigens begint mijn project (en dus ook dit draadje) heel erg veel overeenkomsten te krijgen met het draadje van Peter, met als enige verschil de keuze voor een bepaald IC. (Hier Atmel, daar PICmicro)
Misschien beter om alles in 1 draadje te bundelen, dus wellicht dat mijn verhaal daar verder gaat.
Hier de link: https://forum.beneluxspoor.net/index.php?topic=16967.0 (https://forum.beneluxspoor.net/index.php?topic=16967.0)
Groet,
Jeroen.
-
Jeroen,
je verhaal ook PointerIn en PointerOut klopt volgens mij niet helemaal.
Begin eens met de situatie waar er nog geen paketten binnengekomen zijn (bvb. na power on)? In deze situatie wijzen zowel PointerIn als PointerOut naar hetzelfde slot (1). Dit is dezelfde situatie als volledig vol. De implementatie zoals jij hier voorstelt vereist het gebruik van een counter die aangeeft hoeveel slots er in gebruik zijn. De pointers kunnen enkel gebruikt worden om aan te geven wat het volgende slot is om te lezen en te schrijven maar bepalen niet eenduidig hoeveel slots er in gebruik zijn.
mvg,
Patrick Smout
-
Patrick,
Je hebt helemaal gelijk! Zover had ik nog even niet gekeken...
Goed om te weten dat je een oplettende lezer bent ;D
Groet,
Jeroen.
-
Het is met bijvoorbeeld een PIC mogelijk om een samen met een netwerkkaart een mini 'pc' te creeeren. Fout gezecht eigenlijk, maar je via je netwerk de oproepen en dan ermee te communiceren.
-
Goed om te weten dat je een oplettende lezer bent ;D
En ruim 25 jaar ervaring in embedded software (lees vallen en opstaan maar vooral pijnlijk vallen ;)).
-
@Evert
Grappig dat je daar over begint. Ik ben eigenlijk hetzelfde aan het bouwen maar dan met USB interface. Kijk ik vervolgens naar LocoNet dan is dat in grote lijnen een peer to peer netwerk dus moet het inderdaad ook mogelijk zijn om het met een LAN interface te doen. Welke optie sneller is (of beter werkt voor deze toepassing) durf ik niet te zeggen...
Groet,
Jeroen.
-
Over LocoNet gesproken in combinatie met USB en/of LAN interfaces...
Ik heb begrepen dat het mogelijk is om (snel genoeg) een bezetmelding, over een LocoNet aansluiting, middels een interface (volgens mij ook nog middels een RS232 -> USB converter) op de pc te krijgen zodat bv. Koploper op de melding kan reageren.
Vervolgens stuurt koploper aan de hand van die info bv. een opdracht naar een trein (via de centrale welke ook weer met 'een' (of dezelfde) interface aan de pc gekoppeld is).
Is diezelfde route (2 keer langs een 'traag' interface) ook snel genoeg om bv. een handregelaar te laten werken?
Normaal gesproken is dat natuurlijk niet aan de orde (de handregelaar praat direct met de centrale, en hoeft dus niet langs de pc) maar in mijn geval komt de centrale op de pc waardoor het wel een probleem zou kunnen zijn.
Groet,
Jeroen.
-
Jeroen,
LocoNet's 'baudrate' is maar 16.6666 KBaud dus elke verbinding sneller dan dat is prima ;)
Om twee maal de route te vermijden zou je zoals in het het andere draadje vermeld de PC de centrale moeten laten zijn waaraan je KL koppelt. Dit zou dan b.v. gewoon via het LAN kunnen. Weg vertraging ;)
Grtzz,
Karst