Zelfbouw centrale - Atmel chips - USB - Maar dan anders...

[Jeroen van Tol]

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)  dus daar kan ik ook mee gaan experimenteren. (info daarover heb ik van AVRFreaks op 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  ) 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.

[Patrick Smout]

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

[Karst Drenth]

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  )

Grtzz,

Karst

[piksov]

Hier zie je een scherm afdruk van het sniffen van een dcc signaal:



Op dat moment zaten de adressen 94, 1,2, 4, 5, 6, 7 en 3 in de refresh stack.

[Jeroen van Tol]

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. 
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. 

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  ).
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.

[Patrick Smout]

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

[Jeroen van Tol]

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. 

Groet,
Jeroen.

[Patrick Smout]

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

[Jeroen van Tol]

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! 

We komen er wel...

Groet,
Jeroen.
 

[Patrick Smout]

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

[Jeroen van Tol]

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

Groet,
Jeroen.

[Patrick Smout]

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

[Jeroen van Tol]

Patrick,

Je hebt helemaal gelijk! Zover had ik nog even niet gekeken...
Goed om te weten dat je een oplettende lezer bent 

Groet,
Jeroen.

[Evert M]

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.

[Patrick Smout]

Goed om te weten dat je een oplettende lezer bent 

En ruim 25 jaar ervaring in embedded software (lees vallen en opstaan maar vooral pijnlijk vallen  ).