Universele functie decoder voor wagons

[MickeyMouse]

Schrijf je met &PORTA niet het adres van de variabele PORTA in de struct ipv de waarde 5?


Geert

[Sattrickske]

Schrijf je met &PORTA niet het adres van de variabele PORTA in de struct ipv de waarde 5?

Klopt, en da's ook de bedoeling want als ik wat verder m'n outputs aanspreek doe ik het  als volgt:
Bitje setten:

Code Selecteer Uitklappen

*outputs[portOffset].outputPort |= outputs[portOffset].outputBit;
Bitje clearen:

Code Selecteer Uitklappen

*outputs[portOffset].outputPort &= ~outputs[portOffset].outputBit;
Waarbij portOffset de aangesproken output is.

Kleine correctie: PORTA is geen variable, maar een definitie die verwijst naar het adres 0x005.

[MickeyMouse]

volatile unsigned char           PORTA               @ 0x005;
--> PORTA is dan toch een char ergens in het geheugen? of betekent die '@ 0x005' dat die op adres 5 gemapt wordt?
Ik ken de C-notatie '@' niet...


Geert

[Sattrickske]

volatile unsigned char           PORTA               @ 0x005;
--> PORTA is dan toch een char ergens in het geheugen? of betekent die '@ 0x005' dat die op adres 5 gemapt wordt?
Ik ken de C-notatie '@' niet...

Is inderdaad een mapping op adres 0x005.  PORTA is een register en zit zo gedefineerd in de header.  Het '@' teken is iets specifiek voor HI-TECH C compiler waarmee je rechtstreeks naar een adres verwijst, denk ik.  Ik heb het vroeger ook nooit tegengekomen.

[MickeyMouse]

volatile unsigned char           PORTA               @ 0x005;
--> PORTA is dan toch een char ergens in het geheugen? of betekent die '@ 0x005' dat die op adres 5 gemapt wordt?
Ik ken de C-notatie '@' niet...

Is inderdaad een mapping op adres 0x005.  PORTA is een register en zit zo gedefineerd in de header.  Het '@' teken is iets specifiek voor HI-TECH C compiler waarmee je rechtstreeks naar een adres verwijst, denk ik.  Ik heb het vroeger ook nooit tegengekomen.

OK, vreesde er al voor... Vroeger deed ik dergelijke dingen altijd met een #define
Ik zie nu ook niet meteen het probleem...

Geert

[Sattrickske]

Toch bedankt voor het mee zoeken.
Op zich is het nog geen ramp, als er geen oplossing uit de bus komt, worden de PORTx rechtstreeks in de software gebruikt en punt uit.  Mooie code is altijd leuk, maar als 't echt niet lukt, gaan we er met de grove borstel door.   Jammer dan voor diegenen die m'n code willen herbruiken, ze zullen her en der de poorten moeten aanpassen.
Ik zoek nog effe verder, maar als ik 't tegen morgenavond niet gevonden heb, zal het de grove borstel worden

[MickeyMouse]

OK, success!!
Mocht er mij nog iets te binnen schieten laat ik het nog weten...

Geert

[Sattrickske]

OK nu mag ik toch effe vloeken tegen de sterren op!  Wat een ongelofelijke oen ben ik toch!

Bovenstaande code werkt perfect!  Maar deze idioot heeft om te testen de PORTA van de PIC16F877A op de development kit genomen, deze poort is ook gekoppeld aan een A/D converter die default aan staat.  Dus elke waarde die ik probeerde te lezen was verkeerd door de ADC.  En bovendien was ik met de debugger nog eens de verkeerde waarden aan 't lezen (values ipv adressen).  Hoe dom kan je zijn?

Maar soit 't is opgelost geraakt, da's 't voornaamste.  't Waren Geert z'n gerichte vragen die me effe verder deden nadenken en bingo...

Morgen gaan we verder met de EEPROM routines zodat de decoder weet in welke toestand hij was als de stroom (even) wegvalt.

[MickeyMouse]

Allee, blij te horen dat alles in de sjakosh is!!
Tja, het C-programmeren is voor mij al een tijd geleden, uit mijn electronica verleden..., maar het had me wat gebeten omdat ik vroeger ook veel gebruik maakte van typedefs, #defines, ....
En...pointers, en het gebruik ervan zijn nu net de kracht van C om met weinig code veel gedaan te krijgen, toch eens je het goed door hebt.

Succes met het verdere programmeerwerk!!

Geert

[Geert]

De DCC decodering werkt perfect.

DCC decodering heb ik al eens met succes toegepast, maar nooit eerder op een signaal dat via de wielen-sleep overgebracht is naar de µC. Hoe decodeer je het DCC signaal eigenlijk. Via interrupts bij elke wijziging van het inputsignaal? Houw je rekening met slechte wiel-sleepcontacten?   Dit wil ik wel eens graag weten...

De PWM heb ik uitgeschakeld omdat hiervoor te weinig processor tijd overschiet. 

Dit zit toch hardwarematig ingebakken in de 12F683?

Geert

[Sattrickske]

DCC decodering heb ik al eens met succes toegepast, maar nooit eerder op een signaal dat via de wielen-sleep overgebracht is naar de µC. Hoe decodeer je het DCC signaal eigenlijk. Via interrupts bij elke wijziging van het inputsignaal? Houw je rekening met slechte wiel-sleepcontacten?   Dit wil ik wel eens graag weten...

DCC signaal decoderen is niet zo moeilijk, ik gebruik hiervoor 2 interrupts: één hardware interrupt op de GP2 pin (rising edge).  Deze eerste interrupt start een timer die na exact 80µs een tweede interrupt genereert.  Als bij de 2e interrupt de GP2 laag is, heb je een '1' bitje; als ie hoog is, heb je een '0' bitje.  De spec van DCC zegt dat een '1' puls precies 58µs mag duren en een '0' puls 116µs.  Ik ga dus ergens tussenin gaan 'meten' (bij 80µs) dus.  Dan is het gewoon een kwestie van het DCC protocol correct te implementeren.

Wat de fouten door de wiel-sleepcontacten betreft, nog geen problemen mee gehad, om veschillende redenen:
1) Baan is redelijk proper
2) DCC protocol is hierop voorzien.
Voor het tweede zijn er 2 mechanismen.  Eerst en vooral is er een checksum aanwezig (EXOR van alle ontvangen bytes moet nul zijn), zodat je steeds elk bericht kan verifiëren op juistheid.  En ten tweede, de centrale zend hetzelfde bericht een aantal keren vlak na mekaar uit (m'n CSII toch).  Dat laatste is iets lastiger omdat je in geval van geen enkel signaalverlies, de doorgestuurde commandos verschillende malen gaat herhalen.  Dat vang ik op door het gecapteerde commando eerst naar een ringbuffer te sturen, waarvan de logica lichtjes aangepast is: je kan geen commando toevoegen aan de buffer als het identiek is aan het vorige element in de buffer.

De PWM heb ik uitgeschakeld omdat hiervoor te weinig processor tijd overschiet. 

Dit zit toch hardwarematig ingebakken in de 12F683?

Verdoeme miljaarde nonde... 'k had de manual niet helemaal doorgelezen en had niet gedacht dat er in zo ne kleine pruts nog een PWM zou zitten.  Maar je hebt gelijk!  Alleen jammer dat ie maar op één poort zit, de GP2; net de poort waar m'n DCC signaal aanhangt .  Dus in de volgende versie zou ik één uitgang PWM kunnen sturen en zo de leds dimmen indien nodig.

[Geert]

Zo goed als hetzelfde zoals ik dat doe    (zie ISR routine)

ASM code

Geert

[Sattrickske]

Zo goed als hetzelfde zoals ik dat doe    (zie ISR routine)

ASM code

Inderdaad, bijna zo goed als identiek; je houdt -net zoals ik- ook rekening met de 'verloren tijd' in de interrupt routine voor het 'laden' van je timer.
Ik zie dat je nog op zoek bent naar de programmeer modus van DCC... Da's heel simpel: preamble van 20 '1' bitjes ipv. 12, dan is het gegeven commando een programmeer commando.

[dani]

damn, was al een poosje geleden dat ik nog iets tikte hier... maar het lijkt er op dat je er zo goed als aan uit bent ?   
Ik ben benieuwd om het resultaat te zien werken .     Lijkt me iets interessant voor andere dingen dan wagonnen ook.. bvb verlichting in huisjes aansturen via de centrale,  servo'tjes besturen...

[Sattrickske]

Deze is echt wel voor wagons bedoeld, omdat ie zo piepklein is (pakweg 20x10x5mm) en de uitgangen zijn maximaal 300mA per stuk.  Voor huisjes,wissels, verlichting... heb ik een andere die groter is en meer (en krachtigere 2A) uitgangen heeft.
Omdat deze zo klein is, is 't lastiger om 'm te solderen (vooral dat dual MOSFETje is niet om te lachen); daarom raad ik 'm alleen maar aan voor wagons.  De grotere (60x40x8mm als ik me niet vergis) is gemakkelijker te solderen en deze kan je wel ergens kwijt in je huisje of ergens onder je baan.
Maar ja, als je geduldig bent (en niet bang bent om je fikken te verbranden tijdens het solderen) kan je 'm voor eender wat gebruiken.