BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: Peter Korsten op 21 January 2009, 22:31:46
-
Dit is een stel nogal specifieke vragen, dus houd me ten goede.
Microchip heeft een aantal PIC micro-controllers waar je kinderlijk eenvoudig een USB-poort op kunt aansluiten. Bijvoorbeeld, de 20-pins PIC18F14K40 (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en533924).
Nu hebben die doorgaans één USART aan boord en het lijkt me dat je die via een opto-coupler een Loconet-aansluiting kunt geven. So far, so good.
Maar als je dan ook nog eens het DCC-protocol zou willen doen met dezelfde PIC, heb je dan een tweede U(S)ART nodig? Want dan zit je al meteen aan een 64-pins TQFP en dat lijkt me minder handig.
En als je dan het DCC-signaal (dat van een software-matige centrale af zou kunnen komen) al weet te genereren, is het mogelijk om een galvanische scheiding aan te brengen zoals bij Loconet? En zou je het zonder meer op een booster (al dan niet zelfbouw) aan kunnen sluiten?
Alvast bedankt!
- Peter
-
Nope, voor genereren van het DCC protocol heb je geen (extra) USART nodig.
Enkele wat slimme routines en een timer is voldoende.
Scheiding d.m.v. een optocoupler aan DCC zijde is geen probleem, gebruik ik zelf ook.
Voor een strak/net uitgangssignaal / ingangssignaal op de booster dien je wel gebruik te maken van een wat snellere opto-coupler. Al heeft het hier ook tijden lang met PC817's gewerkt, al verdiende dat geen schoonheidsprijs.
Groetjes,
Dave
-
Hé, dankjewel voor je antwoord! Dat is goed nieuws.
Dus je gaat in feite een U(S)ART nabootsen in software? Dan zal het ook niets uitmaken of je Loconet aan de 'echte' of 'nep'-UART hangt, neem ik aan.
De reden voor mijn vraag is dat ik me afvroeg hoe doenlijk het is om een klein en goedkoop apparaatje te maken dat zich op de computer aanmeldt als twee virtuele seriële poorten, eentje voor Loconet en de andere voor DCC.
Immers, je kunt wel een PC voor microcontroller laten spelen en zelf de timing laten doen, maar dat is toch een beetje zonde van de hardware, om het nog maar niet te hebben over het stroomverbruik. Wat dat betreft lijkt het zinvoller om een centrale als de Intellibox in software na bootsen. Die software bestaat immers al, is niet afhankelijk van hele strakke timing en kan op dezelfde computer draaien als een programma als Koploper.
Nog een vraagje over DCC: stel dat je twee of meer boosters hebt, kun je die parallel op de opto-coupler aansluiten, of kun je boosters in serie schakelen? Of zet je de opto-coupler in de booster? (In zowel de interface als de booster zal vast geen goed idee zijn.) Ik heb eens zitten zoeken in Uhlenbrock-handleidingen en schema's van boosters, maar dat is niet geheel duidelijk.
Dan is er nog de 'kleinigheid' dat ik digitale elektronica weliswaar begrijp ('t is niet veel anders dan programmeren), maar dat het analoge gedeelte, zoals wanneer zet je ergens een condensator of een weerstand neer en met welke waarde, toch enigszins zwarte magie voor me is. Maar daar zal met datasheets en veel zoeken en lezen wel wat aan te doen zijn. :)
- Peter
-
Zo kun je het inderdaad wel bekijken (soort van software-UART zoals ze dat dan noemen).
Mijn eigen centrale heeft ook maar 1 UART welke ik voor XpressNet (RS485) gebruik. 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.
En inderdaad... Loconet 'praten' kan ook in software afgehandeld worden. Evt. kun je gebruik maken van de analog comparator indien deze aanwezig is in de betreffende PIC. Dat scheelt weer een extra IC op je print, maar dan is er wel ietsjes meer code nodig om ook dit weer te regelen.
Waarom eigenlijk een virtuele COM-poort voor DCC? Als je PIC Loconet ondersteuning krijgt, kun je ook Loconet opdrachten interpreteren en de bijbehorende DCC opdrachten eruit poepen. Anders speelt je PC alsnog min of meer voor microcontroller. ;)
Als je achter de opto-coupler een buffertje zet is het parallel schakelen van meerdere (gelijk-soortige) boosters hier achter geen enkel probleem, met het in acht nemen van het common-ground verhaaltje uiteraard.
Opto-coupler voor data en kortsluit-signaal zit bij mij direct achter de centrale (niet in of op de booster).
W.b.t. analoge techniek, dat is inderdaad een kwestie van veel lezen, de bijbehorende wetten en regels bestuderen en ook veel experimenteren. Echter zijn hier op internet heel veel Nederlands- of Engelstalige 'cursusjes' e.d. over te vinden. In de tijd dat ik er mee begon, liep ik elke week de bibliotheek uit met een tas boeken als aanvulling op het leer-materiaal wat ik van school mee kreeg. Internet was nog een luxe destijds... ;)
Groetjes,
Dave
-
Waarom eigenlijk een virtuele COM-poort voor DCC? Als je PIC Loconet ondersteuning krijgt, kun je ook Loconet opdrachten interpreteren en de bijbehorende DCC opdrachten eruit poepen. Anders speelt je PC alsnog min of meer voor microcontroller. ;)
Ik had gedacht omdat je boosters dan ingewikkelder en dus duurder zouden worden, maar bij nadere beschouwing lijkt een Loconet-boosters louter simpele componenten te bevatten. (http://users.telenet.be/deloof/booster/hdm07nl.pdf) Dat valt dus weer mee. Alleen heeft dit ontwerp weer geen galvanische scheiding.
- Peter
-
kijk eens hier... (http://www.mhellm.de/dcc/spax/spax.html)
Ik gebruik zelfs ook deze Spax-Booster van de fremo...
Groet
Bernd
-
De USART is niet zo één twee drie te gebruiken voor Loconet. Loconet is namelijk een bus waarop elke busdeelnemer uit zichzelf kan gaan praten. Het kan voorkomen dat busdeelnemers door elkaar heen gaan praten, en dan moet ze allemaal stoppen met uitzenden, en een bepaalde periode wachten. Dit in tegenstelling tot een RS485 bus zoals als Xpressnet waarbij de master de individuele slaves toestemming geeft om te zenden.
Het project 'Embedded Loconet' is bezig (geweest) om de hardware UART te gebruiken, zie onderandere het volgende mailinglist item:
http://sourceforge.net/mailarchive/forum.php?thread_name=45F2DF24.2000609%40nord-com.net&forum_name=embeddedloconet-developers
-
...Nu hebben die doorgaans één USART aan boord en het lijkt me dat je die via een opto-coupler een Loconet-aansluiting kunt geven. So far, so good...
...De USART is niet zo één twee drie te gebruiken voor Loconet...
Helemaal correct GlaskasteN, Om de LocoNet Specs goed te kunnen implementeren, met name de collision detectie moet je gaan 'bitbangen' dus niet gebruikk maken van een USART, omdat je namelijk bij elke 'hoog' die je het LocoNet opstuurt, moet checken of er geen collision plaats vind.
Peter, aan de USB heb je in dit geval niets helaas. Het LocoNet heeft zijn eigen Hardware protocol. De USB zou je wel kunnen gebruiken als PC-interface...
Maar als je dan ook nog eens het DCC-protocol zou willen doen met dezelfde PIC, heb je dan een tweede U(S)ART nodig? Want dan zit je al meteen aan een 64-pins TQFP en dat lijkt me minder handig.
...Nope, voor genereren van het DCC protocol heb je geen (extra) USART nodig.
Enkele wat slimme routines en een timer is voldoende...
Inderdaad, ook het DCC protocol kun je beter 'bit-bangen' dan de ingewikkelde UART constructie zoals die door de diverse 'direct-drive' programma's gebruikt wordt.
...dien je wel gebruik te maken van een wat snellere opto-coupler. Al heeft het hier ook tijden lang met PC817's gewerkt, al verdiende dat geen schoonheidsprijs...
;D de 6N137 is the chip to have here ;)
...Immers, je kunt wel een PC voor microcontroller laten spelen en zelf de timing laten doen, maar dat is toch een beetje zonde van de hardware, om het nog maar niet te hebben over het stroomverbruik...
Nou, de LocoNet en DCC timing is dermate kritisch, dat je dat zonder Realtime-OS op de PC niet zal lukken... :( ( tenminste als je niet van de PC UART gebruiktmaakt voor generatie van het DCC signaal. LocoNet op de PC, zelfs via de UART, is nooit betroubar aan het werk te krijgen. We praten hier in tijdseenheden tot op de microseconde nauwkeurig.
Maar... ;D een hardstikke leuk project Peter. En PIC programmeren is echt back to basics ;) Leuk dus :P
Grtzz en suc6,
Karst
-
Oké, dat is duidelijk. Trouwens, op de datasheets van de 6N137 staan enkele en dubbele uitvoeringen. Maar met een dubbele uitvoering kom je vast in de knoei omdat er een elektrische verbinding tussen DCC en Loconet is, niet?
Dan nog een vraagje over het programmeren. Er zijn zat schema's voor goedkope programmeurs op het internet te vinden, maar die zijn meestal voor PIC16 chips van meer dan 20 pinnetjes. Zou dat verder nog wat uitmaken, zolang je maar de juiste aansluitingen gebruikt?
Of zou een PicKit2-programmer ($35 + verzending + BTW), of één van deze kits (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805) ($50 + verzending + BTW) een goed idee zijn, mocht ik nog meer met PICs gaan doen?
- Peter
-
Inmiddels heb ik de specificaties van zowel Loconet als DCC gedownload (en uitgeprint en netjes in een mapje gedaan) en daar worden de meeste vragen in beantwoord. Voor DCC heb je inderdaad niet gek veel aan een USART.
Karst, USB is specifiek voor de computer-interface en stroomvoorziening voor de PIC.
- Peter
-
Programmer + demo-bordje + 3 PICs (om het geheel boven de €50 te krijgen en niet de 'handling fee' te betalen) op de site van Microchip Direct besteld.
- Peter
-
Peter,
Ik zie in jouw project wat overlap met mijn projectje... En in het 'gebrek aan electronica kennis' zit geloof ik ook wat overlap. ;D
Om de lege gaten op het gebied van standaard componenten wat op te vullen kwam ik de volgende boeken tegen op internet:
www.ibiblio.org/obp/electricCircuits (http://www.ibiblio.org/obp/electricCircuits)
Misschien heb je er iets aan!
Overigens misschien leuk om eens 'ervaringen en ideeen' uit te wisselen. Mocht je daar interesse in hebben zie ik vanzelf wel een PB'tje...
Groet,
Jeroen.
-
Kijk eens aan, dankjewel!
Het setje van Microchip is eergisteren al aangekomen, daar hoop ik van het weekend wat mee te kunnen spelen, mits mijn zoontje me met rust laat. :)
- Peter
-
Karst,
LocoNet op de PC, zelfs via de UART, is nooit betroubar aan het werk te krijgen. We praten hier in tijdseenheden tot op de microseconde nauwkeurig.
Nu maak je me heel zenuwachtig...
Betekent dat wat ik probeer te bouwen (https://forum.beneluxspoor.net/index.php?topic=17350.0 (https://forum.beneluxspoor.net/index.php?topic=17350.0)) ook niet kan werken?
Groet,
Jeroen.
-
microseconde timing is voorbehouden voor Real Time Operating Systems, een category waar Win* niet eens kort bij komt.
De modale Win programmeur werkt met threads. De maximale tijd die een thread toegekend krijgt alvorens gewisseld wordt naar een andere thread wordt bepaald door de thread quantum tijd en is ongeveer 20-30ms. Dit betekent dat, met een worst case scenario, als meerdere (slecht ontworpen) threads met dezelfde prioriteit hun quantum tijd volledig opgebruiken het ettelijke 100n ms kan duren vooraleer je eigen stukje code terug aan de slag kan.
Wat kan je er aan doen ... weinig, behalve een hogere prioriteit toekennen aan je eigen threads en zo weinig mogelijk andere software draaien als het echt *snel* moet gaan.
Voor je andere project betekent dit vooral erbij stilstaan dat sleeps programmeren om te wachten puur tijdverlies is en dat overlapped IO veel beter werkt. Juiste aanpak hangt af van de USB driver die je hebt (FTDI?) en de API die je aangeboden wordt.
Patrick Smout
-
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
-
@Patrick
Dank voor het beginnen over threads! ;D 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.
-
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
-
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.
-
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
-
Zelf werk ik met de WISP648 van http://www.voti.nl (http://www.voti.nl)
Hij heeft een zeer complete webshop en is betaalbaar.
-
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. ;D
***
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.
-
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
-
Peter,
Ik heb voor Atmel gekozen uit pure onwetendheid. ;D ;D ;D
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 (http://www.ftdichip.com))
De site die Evert noemt is voor jou misschien de moeite waard. (www.voti.nl (http://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.
-
Jeroen, wacht dacht je van dccout.c ...
:-*
-
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
-
;D
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). ;D
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
-
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
-
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.
-
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:
#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
-
Jeroen, wacht dacht je van dccout.c ...
Dat is nu juist het punt. No such file...
-
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 (http://www.opendcc.de/elektronik/opendcc/download.html)
En dan bij de zipjes met source code.
Er gaat een wereld voor je open...
-
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
-
@piksov
Dank!!! Dat zocht ik...
@Peter
Elegant? Wanneer je LocoNet gebruikt is dat volgens mij zelfs keihard de bedoeling... 8)
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.
-
LocoNet??? AVR???
Hier heb je mogelijk wel iets aan: http://embeddedloconet.sourceforge.net/ (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
-
@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:
var = var * 2;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
-
@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 ..... ;)
-
Bedankt Guus! ;D
(Alleen is het wel een hoofdletter 'K'.... Sssst, niet verder vertellen ;))
-
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.
-
Terugmelding, handregelaars, dat idee. LocoNet is een slim systeem voor dit soort zaken en volgens mij de aansluiting met de meeste toekomst.
- Peter
-
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).
-
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
-
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.
-
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
-
Ha Heren ;D
Interessant draadje begint dit te worden 8)
@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' :P ;D 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 ! :o ) zijn goed verkrijgbaar. En USB-2 heeft een tenminste evengrote snelheid en is vorstelijk goedkoper.
Grtzz,
Karst
-
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 ! :o ) zijn goed verkrijgbaar. En USB-2 heeft een tenminste evengrote snelheid en is vorstelijk goedkoper.
[Ontzettend lollig proberen te zijn]
En dan plugt iemand zijn muis in en daar gaat je lok, vooruit,achteruit, vooruit, achteruit,vooruit, achteruit
[/Ontzettend lollig proberen te zijn]
Maar het is in ieder geval wel interessant om over te brainen en wie weet wordt het nog wat! Ik ga morgen maar eens voorstellen dat ik in jaar met betaald verlof ga, kan ik me eens op allerlei boeiende dingen storten zoals dit soort dingen ;D
Gr. Remco.
-
Dit is idd zeeeeeeeeeeeer interessante materie Remco 8) ;D :P
Best wel een jaartje sabbatical aan te besteden ;)
Grtzz,
Karst
-
Ja maar vertel dat m'n chef maar ;)
Gr. Remco.
-
Heb je z'n telefoonnr.? Bel ik 'm wel ff! ;D
[ontopic]
Er valt inderdaad iets van te zeggen deze gedachten...
Als PC pak je gewoon zo'n micro-nano-pico-PC-geval, allemaal standaard voorzien van USB.
Echter ben ik het totaal-plaatje / (hoofd)reden van gebruik PC een beetje kwijt...
Waarom wil je in dit geval dan een PC als 'regel-neef' gebruiken? En niet ook in een AVR/PIC (of ARM met Embedded Linux b.v.) hiervoor gebruiken met een LocoNet interface?
[/ontopic]
Groetjes,
Dave
-
Echter ben ik het totaal-plaatje / (hoofd)reden van gebruik PC een beetje kwijt...
Waarom wil je in dit geval dan een PC als 'regel-neef' gebruiken?
Hierom volgens mij:
...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...
Grtzz,
Karst
-
Owja... Dat was 'm...
Echter als je b.v. een ARM met Embedded Linux hiervoor gebruikt hoeft dat niet per definitie 'beperkt te zijn'.
Nadeel van een PC is dat je een hoop toeters en bellen (hardware) erbij hebt die je niet gebruikt.
Voordeel kan zijn wanneer je toch wenst deze te gaan gebruiken (audio, DVI/VGA aansluiting, ethernet).
Ok... Ik ben er weer helemaal bij (avond dipje??). Geen gek idee-tje! Uiteindelijk kan de PC nog veel meer taken voor zijn rekening nemen in een dergelijk modulair systeem, je kan er veel kanten mee op. En inderdaad minder beperkt dan b.v. een AVR of PIC. ;)
Groetjes,
Dave
-
Karst, ik ben even in de war. Wat is precies het verschil tussen wat ik zeg en wat Jeroen zegt?
Overigens zie ik het niet zitten om de DCC refresh buffer op de PC te laten draaien. Dat is een 'domme' activiteit en de PIC gaat de 'domme' dingen doen. Waarom zou je rekentijd gaat verstoken en je USB-bus belasten voor zoiets banaals?
Verder zal ik toch eens dat LocoNet-document eens goed moeten doorlezen, want dat heb ik nog niet gedaan (alleen vluchtig).
Een groot voordeel van USB is dat het 'bus-powered' is. En volgens mij moet je genoeg stroom kunnen trekken om een paar boosters aan te sturen (10 of 25 mA per stuk). Ethernet is leuk, maar niet echt zinvol als je niet overal UTP hebt liggen.
Maar Ethernet wil ik zeker niet uitsluiten voor de toekomst, niet in de laatste plaats omdat ik dat op zolder heb liggen. Alleen is USB veel simpeler te bouwen, al was het maar vanwege het demo-bordje. Er zijn PICs in de 18F-serie waar je zo Ethernet aan kunt hangen, dus die mogelijkheid bestaat zeker.
En ja, het idee is om met een programma als Koploper de hele boel te bedienen. Aangezien een PC veel meer geheugen en rekencapaciteit heeft dan welke hardwarematige centrale dan ook, is er geen enkele reden om alle intelligentie en het bijhouden van treinen niet naar de computer te verplaatsen, als je toch al met Koploper of iets dergelijks rijdt.
- Peter
-
Hoi,
Karst, ik ben even in de war. Wat is precies het verschil tussen wat ik zeg en wat Jeroen zegt?
Jeroen stelt 2 devices voor: 1 die tussen PC en DCC zit en 1 die tussen PC en LocoNet zit.
Jij wilde ( volgens mij ) 1 device, dat zowel DCC als LocoNet afhandelt.
Overigens zie ik het niet zitten om de DCC refresh buffer op de PC te laten draaien. Dat is een 'domme' activiteit en de PIC gaat de 'domme' dingen doen. Waarom zou je rekentijd gaat verstoken en je USB-bus belasten voor zoiets banaals?
Helemaal eens, maar dat schrijf ik ook niet ;) Het 'refresh' device refreshed zelf natuurlijk. Alleen via USB zegt de PC wat ie moet refreshen ( aan de hand van de slot info van de centrale ). Dus de PC 'beheert' de refresh, het device vooert de refresh daadwerkelijk uit ;)
Maar Ethernet wil ik zeker niet uitsluiten voor de toekomst,
Wellicht niet, maar waar 'staat' dan je 'Centrale-PC' ? zodat je Ethernet nodig zou hebben vanwege de afstand. Het lijkt mij juist wel handig die dicht bij de interface devices te hebben.
Grtzz,
Karst
-
Jeroen stelt 2 devices voor: 1 die tussen PC en DCC zit en 1 die tussen PC en LocoNet zit.
Jij wilde ( volgens mij ) 1 device, dat zowel DCC als LocoNet afhandelt.
Ja, maar wat bedoel je nou met 'device'? Een fysiek of een logisch apparaat? Wat ik in gedachten heb is één kastje dat zowel DCC als LocoNet afhandelt, waarschijnlijk op dezelfde fysieke RJ12-aansluiting, maar als twee logische USB-apparaten voor de PC. Vergelijk het met een toetsenbord met ingebouwde trackball, of een draadloze toetsenbord+muis-combinatie: die tonen zich ook als twee apparaten terwijl er maar één USB-stekker is.
Helemaal eens, maar dat schrijf ik ook niet ;) Het 'refresh' device refreshed zelf natuurlijk. Alleen via USB zegt de PC wat ie moet refreshen ( aan de hand van de slot info van de centrale ). Dus de PC 'beheert' de refresh, het device vooert de refresh daadwerkelijk uit ;)
Maar beheert de PC dan ook de inhoud van de buffer? Want dat wil ik namellijk niet. 'Het kastje' (bij gebrek aan een beter woord; ik houd me aanbevolen voor suggesties) moet toch al de buffer aan het schrijven blijven, dus dan kan het net zo goed verantwoordelijk zijn voor de inhoud. Het idee is nog steeds om het als een seriële poort te presenteren waar je DCC-bytes naar stuurt (of in ieder geval adres- en data-bytes, zonder dat gehannes met start bits en zo). Als je de verantwoordelijkheid van het verversen van de buffer bij de PC legt, moet je daar dus altijd een stuk software hebben dat daar zorg voor draagt. Daarmee zou de hele oplossing systeem-afhankelijk worden, wat daarmee een groot voordeel van USB teniet zou doen.
Wellicht niet, maar waar 'staat' dan je 'Centrale-PC' ? zodat je Ethernet nodig zou hebben vanwege de afstand. Het lijkt mij juist wel handig die dicht bij de interface devices te hebben.
Dat zou een centrale file server kunnen zijn, waar je ook al je muziek en films opslaat, zodat je die met je Playstation/Xbox/Wii op je TV kunt afspelen. Als je dan nog een draadloos netwerk hebt, kun je met een Nokia N800 rondlopen om je baan te bedienen. Want met een stukje software op je server zou je namelijk de data van de N800 om kunnen zetten in LocoNet-signalen...
Ik denk altijd graag vooruit. Soms heeft dat tot gevolg dat ik niet meer bij het heden stilsta. :) Maar voorlopig ben ik nog aan het studeren en daar valt deze discussie ook onder.
- Peter
-
Even kort ;) vanavond wel weer uitgebreid verder ;D
Een device: PIC met USB aansluiting.
Beheren Refreshbuffer: Inhoud van de refreshbuffer is aan het device. Welke lokadressen in de buffer moeten, moet de PC vertellen.
Grtzz,
Karst
-
Hallo heren,
Ik moet zeggen dat ik wel even stond te kijken van deze uitgebreide ideeën na een (behoorlijk) tijdje afwezig te zijn geweest. Zelf heb ik ook wel eens met het idee rondgelopen het een en ander te maken. Alleen door gebrek aan tijd en zin om de volledige documentatie door te lezen nooit wat gedaan. Zelf heb ik ook wel het een en ander met PIC's en C gedaan dus ik blijf dit zeker volgen. Ik hoop dat jullie de code en documentatie openbaar willen maken. Ik hoop hier zodoende nog wat van te leren.
Veel succes en ik hoop hier binnenkort mooie dingen te vinden :D
Timo
-
Ja, daar sta je van te kijken, hè? Je zou al helemaal staan te kijken als ik daadwerkelijk zo'n apparaat zou weten te bouwen. ;D
Karst, volgens mij zitten we op één lijn wat betreft de DCC-buffer en wie wat doet.
Alleen over het LocoNet, dat zou je iets moeten toelichten. Maar ik denk dat ik zo eens mijn bedje in duik, morgen moet ik alweer om zes uur (oké, eer dat ik me uit bed heb weten te slepen is het al gauw half zeven) opstaan.
- Peter
-
Heren,
ik heb dit draadje van voor naar achter gelezen en kom tot de conclusie dat ik naast complimenten voor zoveel inventiviteit en innovatie niets kan toevoegen. Sterker nog, ik begrijp er helemaal niets van maar vind het prachtig dat jullie zo samen enorme kennis weten te bundelen tot een setje modulaire producten waar velen nog veel plezier aan gaan beleven.
Veel succes gewenst ga alsjeblieft vooral zo door. Misschien kan er uiteindelijk zelfs nog een OBB-artikel voor dit forum van gemaakt worden (ik ga weer terug naar mijn diodematrixje en een handjevol relais :-[ ).
-
Ja ja, jij ziet zeker een snoepreisje naar Malta in het verschiet. ;)
- Peter
-
Ik heb dit draadje vol belangstelling gelezen, en ook het verhaal over Karst Drent zijn DCC seindecoder heb ik vol interesse gelezen (en het filmpje bekeken).
Ook heb ik al eens eerder een schematje geplaatst om met behulp van wat extra electronica en de LocoIO print van Hans de Loof alle Nederlandse seinbeelden weer te kunnen geven.
Sinds een paar weken ben ik me een beetje aan het verdiepen in het programmeren van PIC's en heb ik een simpel schakelingetje gemaakt met een 16F628A welke hetzelfde kan als het onderstaande schema.
Ook dat werkt nu.
(https://images.beneluxspoor.net/bnls/seindecoder.jpg) (https://images.beneluxspoor.net/bnls/seindecoder.jpg)
Nu wil ik deze projekten en ideeen samenvoegen.
Ik wil proberen een simpel decodertje te maken wat het Loconet signaal uitleest en direkt het sein aanstuurt. Of nog beter, een programma schrijven wat ik in de PIC op de LocoIO module kan zetten zodat ik 4 Nederlandse seinen kan aansturen met de de LocoIO print zonder extra electronica. Dus 4 seinen (met cijferlichtbak) op de LocoIO aansluiten, andere software in de PIC (met de adressen etc al juist geprogrammeerd) en je hebt 4 goedwerkende Nederlandse seinen :D.
Nu mijn vraag, heeft iemand al eens een programma geschreven met behulp van PICBasic wat LocoNet uit kan lezen? En ben je bereid die code vrij te geven?
Aangezien er een hoop kennis van LocoNet en PIC's programmeren in dit draadje zit plaats ik mijn vraag hier bij.
Groetjes,
Jelle.