USB, PICs, Loconet en DCC

[Jeroen van Tol]

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

Dat is nu juist het punt. No such file...

[piksov]

ooo,

wacht even jij had het over sourceforge...

Da's een hele oude versie, met stof erop enzo ....

Gij zult eens kijken op  http://www.opendcc.de/elektronik/opendcc/download.html

En dan bij de zipjes met source code.

Er gaat een wereld voor je open...

[Peter Korsten]

Zodra je het wachtwoord hebt, ja. Als je niet wil dat iemand anders je source code jat, moet je geen open source project beginnen.

- Peter

[Jeroen van Tol]

@piksov
Dank!!! Dat zocht ik...

@Peter
Elegant? Wanneer je LocoNet gebruikt is dat volgens mij zelfs keihard de bedoeling...  

De UART hebben we niet nodig, tenminste, niet voor het genereren van het dcc-signaal. We gaan weliswaar op een seriele manier gegevens naar de baan sturen maar dat is volgens mij niet hetzelfde 'serieel' als in de zin van UART communicatie.
Volgens mij kunnen we met een doodgewone I/O poort aan de slag en die gedurende (n *) 60 us hoog of laag schakelen.

Qua polariteit (je reeks met + en -) is dat inderdaad hoe het signaal er uit moet komen te zien.

De timing/timer zal volgens mij gebaseerd moeten worden op een kristalletje welke als ik het me goed herinner ergens op de XTAL aansluitingen van de chip aangesloten kan worden. (Mogelijk zelfs al in de PIC ingebakken) Op basis daarvan vinden de clock-cyles in de chip plaats dus wellicht kun je ook gewoon een teller programmeren die per cycle 1 ophoogt en vervolgens uitrekenen hoeveel cycles 60 us is...

Ik neem aan dat je de reeks vertaalt naar + en - om te laten zien hoe het signaal er qua polariteit uit moet zien? Want je hoeft de bits natuurlijk niet echt te vertalen naar een reeks + en - om het te laten werken. Kwestie van de timer 2 x starten per polariteit bij een '0', in plaats van 1 x per polariteit bij een '1'.

Ik ga vanavond eens spieken hoe ze het bij OpenDCC aangepakt hebben.

Overigens zie ik meteen dat jouw nivo van programmeren een flink stukje hoger ligt dan dat van mij... Ik heb laaang geleden een aantal jaren in Cobol geprogrammeerd voor mijn werk, met een heel klein beetje assembler. Sindsdien programmeer ik alleen nog voor de hobby af en toe in VB en een klein beetje C. Kortom, ik zal proberen je bij te houden.  

Groet,
Jeroen.

[Dave van der Locht]

LocoNet??? AVR???

Hier heb je mogelijk wel iets aan: http://embeddedloconet.sourceforge.net/

En w.b.t. genereren van het DCC signaal e.d... Kijk inderdaad maar eens in de OpenDCC source. Zelf heb ik dit op soortgelijke wijze gedaan. In de grote lijn komt het op hetzelfde neer.

Groetjes,
Dave

[Peter Korsten]

@Jeroen

Dit stuk source code is bedoeld om te laten zien hoe je een buffer van bytes om kunt zetten in positieve en negatieve polariteit. Wat je zou moeten doen is de buffer gevuld houden met DCC-bytes, dus inclusief de 'preamble', waar je twee bytes van 0xff (255) zou kunnen gebruiken.

Voor die extra '0' en '1' bits tussen de bytes zou nog wat extra code geschreven moeten worden, uiteraard. Maar als je de trans() functie iedere 60 μs aanroept, dan ben je al een eind.

Dat is namelijk de reden dat alle variabelen binnen die functie static zijn, zodat ze hun waarde behouden zodra de functie eindigt. Dit is opzettelijk gedaan, zodat je die functie via een interrupt kunt aanroepen, in plaats van handmatig een tellertje bij te houden. Want hoe ga je anders zowel DCC als LocoNet tegelijk doen?

Of dit ook daadwerkelijk zal werken op een PIC is een ander verhaal.

En wat mijn niveau betreft, tja, dat zou je mogen verwachten na 26 jaar ervaring met programmeren - het is dan ook mijn beroep. Om terug te gaan naar C is eigenlijk best wel leuk.

En als je iets met twee moet vermenigvuldigen, doen deze twee statements hetzelfde:

Code: [Selecteer]

var = var * 2;

Code: [Selecteer]

var <<= 1;Maar de tweede is veel efficiënter te compileren naar machinecode. Dat soort zaken krijg je met ervaring en ervaring krijg je door (1) veel te oefenen en (2) heel veel af te kijken.

- Peter

[piksov]

@Peter Korsten,

que ?

Eerder - toen zat er een password op de zipfiles

^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z^z

sh*t je hebt gelijk...

De files laat winzip wel zien, maar als je IN een file wilt kijken heb je een ww nodig.....

De oplossing is zoals altijd heel simpel...

Even een mailtje sturen naar Wolfgang Kufer, en je krijgt volgens mij zo het ww.

En als je Peter Korsten of Jeroen van Tol heet, dan krijg je dat ww van mij via pm ..... 

[Jeroen van Tol]

Bedankt Guus! 

(Alleen is het wel een hoofdletter 'K'.... Sssst, niet verder vertellen  )

[Jeroen van Tol]

Peter,

Ik heb inmiddels de LocoNet specs wat diepgaander bekeken. Nu begreep ik uit jouw verhaal dat je met de PIC zowel het dcc-signaal wil genereren als met LocoNet wil communiceren, maar dat het verder een software-centrale moet worden op de pc.

In bovenstaand plaatje snap ik even niet waarom je de PIC met LocoNet wil laten praten.
Wat wil je daar mee bereiken?

Groet,
Jeroen.

[Peter Korsten]

Terugmelding, handregelaars, dat idee. LocoNet is een slim systeem voor dit soort zaken en volgens mij de aansluiting met de meeste toekomst.

- Peter

[Jeroen van Tol]

LocoNet is een slim systeem voor dit soort zaken en volgens mij de aansluiting met de meeste toekomst.

Helemaal mee eens!

Terugmelding, handregelaars, dat idee.

Wanneer je dat soort opdrachten op de LocoNet bus wilt oppakken met de PIC dan ben je volgens mij een complete 'stand-alone' centrale aan het bouwen... Dan kun je denk ik net zo goed de OpenDCC centrale nemen. Er blijft dan immers niets meer over om met de 'pc-centrale' te verwerken. De treinbesturingssoftware zoals bv. Koploper kan dan gewoon LocoNet opdrachten naar de PIC sturen, zonder dat daar nog een software-centrale tussen hoeft te zitten..


Ik heb trouwens de code van OpenDCC bekeken. De dcc-signalen worden daar gegenereerd met een PWM (Pulse Width Modulator).

[Peter Korsten]

Ik zou dan even OpenDCC moeten bekijken, maar waar het mij vooral om gaat is om geen centrale op basis van een PIC of AVR te bouwen, omdat die altijd beperkt zal zijn. Indien Koploper alle functies van een centrale, op de specifieke timing na, over kan nemen, dan is mij dat ook goed.

- Peter

[Jeroen van Tol]

Ik ben weer eens niet helemaal duidelijk... sorry 

Wat ik bedoel is het volgende:
De PIC een LocoNet aanluiting geven betekent dat je LocoNet apparaten (zoals bv. een handregelaar) direct met de PIC wilt laten praten en niet via een centrale op de pc. Om dat mogelijk te maken moet dus alle intelligentie van de centrale op de pc 'verhuizen' naar de PIC, waardoor je geen centrale op de pc meer nodig hebt.
(lees: bouw/koop een willekeurige externe centrale)

Wil je de intelligentie (de centrale) wel op pc houden, dan hoeft je PIC geen LocoNet aansluiting te hebben want dan zal de PIC alleen met de pc (en de booster) praten en met niemand anders. De communicatie tussen PIC en PC staat dan los van LocoNet.

Dat laatste is volgens mij wat je wou (is overigens ook mijn insteek) maar daar heb je dan geen LocoNet aansluiting voor nodig.

De centrale op de pc kun je natuurlijk weer wel laten voldoen aan de LocoNet specs, en met een LocoNet verbinden. (Dus parallel aan de verbinding met de PIC)
Ik weet alleen even niet of dat allemaal snel genoeg zal functioneren...

Groet,
Jeroen.

[Peter Korsten]

Misschien zeg ik nou iets raars, maar ik zie LocoNet vooral als een seriële aansluting. Noem het een bus, maar het komt er op neer dat er een reeks bytes in en uit gaat.

De rol van de PIC is om het LocoNet-signaal goed gesynchroniseerd naar binnen en buiten te krijgen, zonder dat de PC zich zorgen hoeft te maken over zaken als microseconde-timing. De PC (of Mac, ik ben niet selectief) ziet LocoNet dan als een gewone seriële aansluiting; een virtuele com-poort dus.

Wat de software op de PC daarmee gaat doen is een ander verhaal.

Uiteraard wordt deze LocoNet-aansluiting één van de vele op de bus, maar het hele idee is dus om een 'domme' schakeling te bouwen die aan de ene kant DCC en LocoNet spreekt en aan de andere kant USB. Alles wat een beetje 'intelligentie' vereist, gaat op de PC draaien. En als je een softwarematige centrale hebt die op een handregelaar reageert, is het wel zo handig dat die LocoNet begrijpt.

- Peter

[Karst Drenth]

Ha Heren 

Interessant draadje begint dit te worden 

@Peter

Ik denk dat Jeroen gelijk heeft. In de ( onze ) modulaire wereld maken we vaak gebruik van het 'Separation of Concern' beginsel ( OO en dus Java doet eigenlijk niet anders )

Zo zou je dit 'probleem' ook aan kunnen vliegen:

Neem een 'tussen bus'  Namelijk USB !

Maak vervogens een DCC refreshgenerator met USB interface en een LocoNet USB interface... Dit Loconet interface kan helaas geen bestaande versie zijn, daar het het z.g. MASTER busy ( OPC_BUSY ) moet sturen na ontvangst van elk commando en wel zolang totdat je PC - centrale antwoord heeft gegeven.

Verder kun je dan idd in de PC de complete functionaliteit maken die een LN centrale normaal heeft: Het beheer van de slots en het onderhouden van de DCC refresh-ringbuffer. ( niet te verwarren met de daadwerkelijke signaalgeneratie dat door het DCC-USB interface wordt gedaan )
Daar kun je verder nog allerlei goodies aan toevoegen, zoals een Fast Clock, socketinterface met loconet protocol of SRCP, route control, rijwegsturing, pendelbaan of wat dan ook.

Ik denk, dat in essentie b.v. de EcOS en Marklin CS2, maar ook de ViessMann commander niet veel anders werken. Zij het dat deze van embedded Linux gebruikmaken.

Dus... Hele goede ideeen hier ! En wat mij betreft hoe modulairder, hoe beter !

@Jeroen

Je zou dit ook allemaal via Ethernet ( LAN ) kunnen doen. Het grootste nadeel daarin zie ik in de prijs. PIC en AVR's met USB ( 2 = 480 Mbps !  ) zijn goed verkrijgbaar. En USB-2 heeft een tenminste evengrote snelheid en is vorstelijk goedkoper.


Grtzz,

Karst