@Bas: Zou je niet veel beter een logisch poortje kunnen nemen, in plaats van iedere 60us een interrupt? Want interrupts zijn behoorlijk kostbaar.
@Karst: Ik ken de precieze structuur van Loconet berichten niet, maar voor zover ik begrijp kan een zender pas een collision vaststellen als hij zelf een HIGH zend (en dus een lijnspanning verwacht van > 4 Volt) terwijl een ander een LOW zend (dus de lijnspanning naar 0V trekt). Een collision kan daarom alleen gedetecteerd worden als de bitpatronen die twee zenders versturen, ergens verschillen. Dat kan dus best een tijdje duren. 500us lijkt me dus inderdaad geen probleem; ik vermoed zelfs dat het kan voorkomen dat de collision pas in het tweede byte gedetecteerd kan worden.
Om heel eerlijk te zijn, verbaast het me wel als nog niemand een Loconet monitor heeft geschreven die ook collissions en transmissiefouten kan tellen.
Geen slecht idee. een XOR poortje op RX en TX. Is er een verschil, geeft die 1, anders 0. Moet nog wel een filtertje van ca. 500nS achter.
Even een stukje terug lezen. Een collision kun je als zodanig niet extern detecteren. ( en dus ook niet loggen )Een benadering zou zijn om Framing errors en Break condities te monitoren. Maar daarvoor heb je direct access naar je UART nodig. Wat nog het eenvoudigst zou zijn is om paketten waarvan de XOR niet klopt te loggen. Dat "zou" een collision indicatie kunnen zijn. Maar evengoed één of andere lijnstoring.
Daarom zijn volgens mij de DxCore processoren juist voor Loconet interessant. Ze hebben dit allemaal hardwarematig aan boord.
Algemeen (=niet Loconet) kan je collissions vaak detecteren door te checken of de gemeten framelengte niet minder is dan de minimale framelengte. Want als een CD-mechanisme het zenden onmiddellijk stopt nadat de collision optreed, worden er minder bits verstuurd dan zou mogen. Als Loconet implementaties dat allemaal ook zouden doen, was mijn oorspronkelijk vermoeden dat je hierdoor misschien collisions zou kunnen detecteren.
Dit break signaal trekt de lijn 15 bittijden (=900us) laag;een toestand die normaal gesproken niet zou mogen voorkomen (of zie ik dit mis?).Zou je daarom niet een heel eenvoudige Loconet collision counter kunnen maken door te meten hoe vaak de lijn 900us (of langer) laag is?
In DxCore (en waarschijnlijk ook moderne PIC) processoren zou dit zeer eenvoudig te programmeren moeten zijn, met nauwelijks CPU belasting. Of zie ik wat over het hoofd?
Voor break-detection heb je die faciliteiten niet nodig. Dat zit in elke UART die ik sinds 1980 "onderhanden" heb gehad
Ik zie dat je de Frame Error (FEn) Flag gebruikt.
Andere vraag, gewoon uit nieuwsgierigheid: gebruik jij bij zenden ook de truc dat je de baudrate generator reset om het versturen zo snel mogelijk te starten nadat de lijn vrij is?
Nope, heb dat ook al eens gelezen. Het effect daarvan is volgens mij niet éénduidig en kan startbit-jitter veroorzaken.Voor het zenden wachten (indien al nodig) totdat de CD afgelopen is, RX checken dat die hoog is, en het byte in de TXD storen. Een ATtiny/ATxmega kan dat makkelijk binnen 2us voor elkaar krijgen ( Clock-cycle is max. 50ns ==> 2000 / 50 = 40 instructies na de test op TX hoog heb je de tijd. Ruim genoeg )
De AVR-DAx is zo in te stellen, dat het teruglezen op bit-level gedaan kan worden door de USART zelf. Dan zit je dus op het niveau van bitbangen, zonder te bitbangen