USB, PICs, Loconet en DCC

[Peter Korsten]

Er zijn bepaalde dingen die met een PC beter gaan en bepaalde dingen die met een microcontroller beter gaan.

Als het gaat om het genereren van een DCC-signaal, dus 60 μs + gevolgd door 60 μs - voor een '1'; 120 μs + gevolgd door 120 μs - voor een '0' - dat wil je niet met een PC gaan doen, daar kun je veel beter een mcrocontroller voor gebruiken.

(De DCC-specificatie heeft het overigens niet over precies 60 μs en 120 μs, maar dit is het simpelste te implementeren. Je kunt het zelfs met een eenvoudig kristal en een paar bit shifters aan je parallelle poort implementeren.)

Voor al het andere is een PC aan te bevelen. Immers, een digitale centrale is niets anders dan een simpele computer met een beperkt geheugen, beperkt scherm, beperkte invoermogelijkheden... alles is eigenlijk beperkt ten opzichte van een PC. Als je je modelspoorbaan toch met een computer gaat besturen, heeft een centrale geen toegevoegde waarde boven het soort interface waar we het hier over hebben.

Je moet alleen een eenvoudig programma schrijven dat de data van de USB-poort in een buffer zet en blijft uitsturen als DCC-signaal, dat je dan nog 'eventjes' moet omvormen naar +18/-18 volt en, laten we zeggen, minimaal 100 mA om de boosters aan te sturen. Overigens staat het ook in de DCC-specificatie hoe het precies zit met wat voor spanning en stroomsterkte het signaal van het 'command station' (een centrale of een USB-interface, dus) naar één of meer boosters gestuurd wordt.

- Peter

[Jeroen van Tol]

@Patrick
Dank voor het beginnen over threads!  Ik zat te speuren in de specs van de southbridge maar het is natuurlijk afhankelijk van de processor zelf. Kortom, zat op de verkeerde plek te zoeken. 
Als jouw cijfers overigens kloppen dan kan het af en toe krap worden maar het lijkt nog steeds haalbaar!

@Peter
Je beschrijft precies wat ik aan het fabriceren ben!

Alleen dat 'omvormen naar +/-18V' ben ik niet helemaal met je eens.  Volgens mij is dat afhankelijk van het soort booster dat je gebruikt. De booster van bijvoorbeeld OpenDCC werkt volgens mij met ingangssignalen van 5V, dus als het even kan wil ik mijn circuit vanuit de USB bus voeden...

Al succesjes geboekt met het programmeren van de PIC? Ben wel benieuwd namelijk!

Groet,
Jeroen.

[Peter Korsten]

Nee, nog geen successen, maar wat die +/- 18 volt betreft, dat heb ik uit de documentatie van DCC gehaald. Die 18 volt zou ik verkeerd kunnen herinneren, maaar het is in ieder geval een bepaald bereik en het is zeker geen TTL-niveau (0 en +5 volt).

- Peter

[Jeroen van Tol]

Volgens RP-9.1.2 van de NMRA kun je kiezen tussen 2 varianten:

1: Opto-isolated (current) interface (die bedoel jij, +/-8 tot 22V)
2: Driver/Reciever (voltage) interface (die bedoel ik, +/- 3 tot 12V)

Centrale en booster moeten van hetzelfde type zijn.

Groet,
Jeroen.

[Peter Korsten]

Zoals ik al zei, de precieze voltages wist ik niet uit mijn hoofd. Wel dat je met de opto-coupler-variant maximaal 25 mA mag vragen per booster en voor die andere variant maximaal 10 mA.

En inderdaad geen TTL-niveau.

Ik ben er nog niet uit welke variant ik ga gebruiken... het ligt er een beetje aan wat er gangbaar is.

- Peter

[Evert M]

Zelf werk ik met de WISP648 van http://www.voti.nl

Hij heeft een zeer complete webshop en is betaalbaar.

[Jeroen van Tol]

Dave,

Echter is DCC prima te doen middels een timertje (en bijbehorende interrupts). Welliswaar hier wel op een AVR, maar voor een PIC geldt deze basis ook.

Heb jij toevallig een voorbeeld van jouw code om dcc te genereren vanuit het geheugen van de AVR? In assembler of C ofzo?
Ik probeer het hier met een ATMega8 voor elkaar te krijgen, wat me na verloop van tijd ook heus wel zal lukken, maar een voorbeeld zou me enorm helpen. 

***
edited: Het voorbeeld kan ik natuurlijk bij OpenDCC vinden... Sorry, het is zeker tijd voor weekend 
***

***
edited 2e keer: Kan het dus niet op OpenDCC vnden. Heb me suf gezocht op sourceforge.net maar precies de map waar dat in zou moeten staan is leeg... Iemand een idee welk .c bestand het dcc-genereren bevat???
***

Overigens heb je me ook weer in een leuke richting gestuurd door het noemen van ftdi chips. Als ik het bij USB ga houden zie ik bijvoorbeeld de FT232R als optie (of compleet als UM232R, scheelt lastig soldeerwerk). Of de UM245R... Maakt dat eigenlijk nog wat uit? Het verschil is toch alleen dat ik de data serieel of parallel door de Atmel moet laten verwerken?

Groet,
Jeroen.

[Peter Korsten]

Maar heb je nou voor de Atmel gekozen vanwege de ontwikkelomgeving?

Want de reden dat ik voor de PIC (en het gehannes met de niet-gratis C-compilers) heb gekozen is dat je een USB-poort zonder enige extra elektronica (op een pull-up/pull-down weerstand na om 1.5 of 12 Mbps aan te duiden aan de PC) op een PIC kunt aansluiten én dat die PIC verkrijgbaar is in een PDIP-uitvoering, oftewel gemakkelijk te solderen.

- Peter

[Jeroen van Tol]

Peter,

Ik heb voor Atmel gekozen uit pure onwetendheid. 

Mijn redenen waren:
1. OpenDCC (waar ik veel info uit haal) is op basis van een Atmel
2. Iemand raadde het aan
3. Iemand zei dat ik daarmee kon wat ik wilde

Volgens mij was die iemand in beide gevallen Dave, maar helemaal zeker weet ik dat niet meer...

Hoe dan ook, in mijn enthousiasme had ik vrij snel een paar Atmels gekocht met daarbij een evaluation kit... Pas later bleek het best een prettige keus. 
Gelukkig maar want de EVK was best een investering...

Een chip met USB (ook bij Atmel) heeft inderdaad vaak hele kleine pootjes. Ik kan niet zo goed zulke kleine dingen solderen dus (ook weer met dank aan Dave) ga ik waarschijnlijk kiezen voor een ftdi chip. (Een bedrijf wat alles doet met USB) Ook kleine pootjes maar gelukkig hebben ze ook een variant waarbij de chip op een printje 'voorgesoldeerd' zit, compleet met USB aansluiting en alles... (zoek maar eens op UM232R bij www.ftdichip.com)

De site die Evert noemt is voor jou misschien de moeite waard. (www.voti.nl)
Die kerel doet alles met PIC's en geeft bovendien duidelijke uitleg over het hoe en wat.
Qua productprijzen vind ik m wat aan de dure kant maar de info is gratis. 

Groet,
Jeroen.

[piksov]

Jeroen, wacht dacht je van dccout.c ...

 

[Peter Korsten]

Jeroen, voor €67 exclusief BTW (maar die heb ik dus niet betaald, handig als je vrouw een EU-BTW-nummer heeft) maar inclusief verzendkosten naar Malta, heb ik een demo-bordje van Microchip met een 20-pins PIC, programmeur en nog eens drie extra PICs besteld.

Niet dat ik je aan wil raden om nu over te stappen, hoor.

Wel zou het interessant kunnen zijn om, waar mogelijk, source code te delen.

- Peter

[Dave van der Locht]

 

Ja geef mij maar weer de schuld! Je begon zelf in je 1e post over Atmel's, OpenDCC en open source in dat andere topic...
En als je vraagt of het mogelijk is daarmee, natuurlijk zeg ik ja als microcontroller fan (als er PIC had gestaan zou ik ook ja gezegd hebben dat 't kon). 

Ik denk wel dat Jeroen een goed opstapje en kennismaking heeft in de wereld van microcontrollers met de AVR's.
Ik ben zelf ook ooit eens begonnen met AVR's, daarna nog flink wat met PIC's gedaan (niet modelspoor gerelateerd) en sinds een jaar of 2/3 toch weer terug bij de AVR's. Waarom??? Een aantal dingen die in dit topic minder relevant zijn...

In principe maakt het ook niet zo heel veel uit, je kunt ook in beiden een meester worden.
Jammer dat Atmel's AVR en Microchips PIC-jes altijd als 2 kampen gezien wordt, ze hebben beiden hun voor- en nadelen t.o.v. elkaar. In de 1ne situatie ben je dan met een PICje beter af, in een andere weer met een AVR... Dat hou je toch.

Ik experimenteer hier overigens niet op zo'n develop-bordje met allerlei toeters en bellen. Gewoon een breadbordje, ISP programmer, JTAG debug/program interface en de benodigde onderdeeltjes voor de rest van de schakeling waar ik op dat moment mee bezig ben. Software: AVRStudio met WinAVR (GCC) compiler.

En source delen? In C zou dat goed mogelijk zijn, veelal hardware-specifiek niet 1 op 1 te gebruiken maar 't scheelt niet veel.

Groetjes,
Dave

[Peter Korsten]

Tja, die PIC heb ik puur voor het solderen gekozen. Als programmeur die assembler (Z80, 8088, 68000), geïnterpreteerde talen (Basic, JavaScript), procedurele talen (Pascal, C), script-talen (Perl, Bourne shell), object-georiënteerde talen (C++, Java) en nog wat ander spul (SQL) heeft gedaan, gaat mijn voorkeur toch uit naar Java.In het geval van een microcontroller, C. Maar assembler? Daar ben ik te oud voor.

(Overigens is het bovenstaande lijstje niet compleet; ik zou bijvoorbeeld 'Expect' toe kunnen voegen, maar dit zijn de talen waar ik veel in heb gedaan. Maar gelukkig nooit Cobol of Fortran. )

Maar toch blijk ik me niet helemaal goed geïnformeerd te hebben over C-compilers voor de PIC. Weliswaar heb ik een gratis studenten-versie gedownload, die weer van Redhat schijnt af te komen, maar iets als gcc bestaat niet.

- Peter

[Jeroen van Tol]

Peter,

Het lijkt me zeker interessant om krachten te bundelen want ik heb gemerkt dat alle begin moeilijk is als het gaat om het programmeren van IC's...

Overstappen op PIC ga ik op dit moment niet doen. Is volgens mij ook niet nodig voor een gezamenlijke effort.

We willen denk ik allebei weten hoe je bijvoorbeeld het geheugen in de IC kunt benaderen, wat je met een UART kunt of om het even welke andere functie van de IC zoals USB, hoe je data het beste kunt verzenden (bitbangen?) en hoe je 0 en 1 kunt vertalen naar dcc-signalen, wat al die termen betekenen als Rx, Tx, Ack, enz... enz... enz...

Veel van die zaken betekenen hetzelfde op beide chips.

In een later stadium, wanneer we weten welke technieken we moeten gebruiken, en het tijd wordt om de chip te leren wat we willen doen, zullen er wel verschillen tussen PICmicro en AVR zichtbaar worden.
En zelfs dan denk ik dat we nog steeds leuk kunnen babbelen over vergelijkbare hindernissen.

Wel ben ik ondertussen ook gaan kijken naar LocoNet. Het ging mij in eerste plaats om een 'stand-alone' dcc-generatortje maar het kan geen kwaad om eens te onderzoeken of die generator ook meteen in een LocoNet omgeving zou kunnen werken.

Kortom, we geraken al aardig op 1 lijn en het kan vast geen kwaad om aan het einde van de rit 2 oplossingen te hebben. Kunnen we leuk vergelijken wat de een beter heeft gedaan dan de ander (en andersom) en wellicht van daaruit een 'ideale' oplossing bedenken.

PS: Cobol is hardstikke leuk joh! Beetje stoffig, maar wel leuk.

Groet,
Jeroen.

[Peter Korsten]

Een elegante oplossing kan zijn om het DCC-signaal op pinnen 1 en 6 van de LocoNet-stekker te zetten.

Wat betreft een U(S)ART, dat zou nog wel eens moeilijk kunnen worden omdat DCC op een hele andere manier werkt. Zelf denk ik aan een circulaire bufffer die iedere 60 μs (16.666,67 Hz) via een interrupt de volgende transitie bepaalt. De reeks 10110111 wordt dan +-++--+-+-++--+-+-+-.

In C (getest op Sun Solaris 10) ziet het er zo uit:

Code: [Selecteer]

#include <stdio.h>
#include <strings.h>

#define BUFFER_SIZE 128

unsigned char buffer[BUFFER_SIZE];
unsigned int buffer_length;

void trans();

int main( int argc, char **argv )
{
    int index;

    buffer[0] = 0xb7; /* 101110111 binary */
    buffer_length = 1;

    for( index = 0; index < 256; index++ )
        trans();
    putchar( '\n' );
}

void trans()
{
    static unsigned char bit_mask = 0;
    static unsigned char byte = 0;
    static unsigned int index = 0;
    static unsigned char bit = 0;
    static unsigned char phase = 0;

    if( phase == 0 )
    {
        if( bit_mask == 0 )
        {
            bit_mask = 0xff;
            byte = buffer[index++];
            if( index >= buffer_length )
                index = 0;
        }

        bit = ( byte & 0x80 ) >> 7;
        phase = 4 >> bit;
        byte <<= 1;
        bit_mask <<= 1;
    }

    if( ( phase << bit ) > 2 )
        putchar( '+' );
    else
        putchar( '-' );
    phase--;
}

Het zal vast wel geoptimaliseerd kunnen worden, maar het maakt bijvoorbeeld veel gebruik van bit shifting, wat assembler leuk vindt.

- Peter