selfbus.org

...Details zu dem Spannungs/Stromverhalten der Devices und wie das getestet wird findest du in der Spec Vol8.2.2 Physical Layer and Link Layer Test. Unsere Free/Selfbus Implementierung ist nicht ganz konform (während der Equalisationsphase eines Bits, Überschwinger nach den 35us low), sollte das sendende Devices Strom an den Bus liefern um den Strompuls von ca 300mA während der 35us low und damit den Leistungsverlust am Bus zu kompensieren. Das kann die Drossel nicht - dazu müsste sie z.B. durch einen Trafo ersetzt werden (alte BCU/BIM machen das so) - das ist aber nicht tragisch und stört nicht da der Equalisation Pulse der Bus-Stromversorgung auch Null sein kann. (Da kann dann ein Gyrator als Drossel Ersatz eingesetzt werden).
LG
Horst

...hab mal in bus.cpp da Problem mit der phy. Adr. 0.0.0 und der Kollisionserkennung bei z.B. ACK gepatcht. 0.0.0 ist nur für Router zulässig, Die LIB kann man dazu mit einer Konfiguration mit definierten ROUTER kompilieren.

Für die Kollisionserkennung hab ich den Beginn des Fensters auf letzte 69us nach der steigenden Flanke des letzten Bit Pulses gesetzt:

void Bus::begin()
{
ownAddr = (userEeprom.addrTab[0] << 8) | userEeprom.addrTab[1];
#if BCU_TYPE != BCU1_TYPE
if (userEeprom.loadState[OT_ADDR_TABLE] == LS_LOADING)
{
byte * addrTab = addrTable() + 1;
ownAddr = (*(addrTab) << 8) | *(addrTab + 1);
}
#endif
//check own addr - are we a router then 0 is allowed
//0.0.0 is not allowed for normal devices
//set default addr 15.15.252 in case we have PhyAdr of 0.0.0
#ifndef ROUTER
if (ownAddr == 0) ownAddr =0xfffc;
#endif
telegramLen = 0;

*****************
// Wait for a capture event from bus-in. This should be from us sending a zero bit, but it
// might as well be from somebody else in case of a collision.
// Check for collision during sending of high bits
// start of falling edge of next low bit by cap intr.
case Bus::SEND_BIT_WAIT:
// check if intr is from our pulse
// collision window starts 69us after rising edge of last low bit and ends 69us before last high bit end
if ((timer.capture(captureChannel) < timer.match(pwmChannel) - BIT_WAIT_TIME) &&
(timer.capture(captureChannel) > BIT_WAIT_TIME) )
{
// A collision. Stop sending and ignore the current transmission.
D(digitalWrite(PIO1_4, 1)); // purple
timer.match(pwmChannel, 0xffff); // set PWM bit to low next interrupt is on timeChannel match (value :time)
state = Bus::RECV_BYTE;
collision = true;
break;
}

Hab das mal mit der out8-bcu1 getestet- schein zu laufen. Läßt sich mit knxd und TPUART auf dem Raspi programmieren (Phy Adr, App).

Die Sachen mit den Com-Obj, die auch lokal zu behandeln sind wenn sie der gleichen Gr.Adr. zugeordnet sind schau ich mir noch genauer an.

Christian, ich benutze dein VM SW, wie bekomme ich das denn aus deiner VM in ein neues Repository in GIT?

LG
Horst

Hi Horst,

klingt sehr vielversprechend!
Meinst du wirklich ein neues Repository? Oder eher einen neuen Branch, wie z.B. "dev" unter der sblib?

Du kannst in der VM Gitkraken nutzen oder das Git Plugin aus MCUXpresso.
Allerdings wäre das eine SAche, die wir auch mal synchron besprechen könnten und ggf. mal eine Teamviewersession o.Ä. machen sollten.

Grüße
Christian

hora0816 hat geschrieben: ↑19. Jan 2021, 20:03 Die alte LPC Empfangsstufe wurde 1:1 übernommen. der Ruhepegel (high level für den Eingang) liegt damit im undefinierten Bereich des ARM, denke deshalb wurde auch der C ergänzt. Der high Pegel sollte mind. 0,7VDD betragen, also größer 2,3V. Mit der akt Schaltung sind das nur ca 1,8V. Der low level sollte bei max 0,3VDD liegen, also kleiner von ungefähr 1V.

Aus diesem Grund hatte ich in der Vergangenheit die Schmitt-Trigger Stufe an diesem Eingang aktiviert, ich meine das ist in die sblib eingegangen. Bemerkbar machte sich diese Pegelverletzung durch Programmierprobleme von anderen Geräten am Bus: Der illegale Pegel sorgte für wild erkannte Flanken und ab und zu hat die sblib darauf mit dem Versenden von NACKs reagiert. Das hat dann andere Kommunikation auf dem Bus beeinträchtigt.
Nach Aktivieren des Schmitt-Triggers war bei mir Ruhe, die sblib hat dann in meinem Testsystem keine Geisterflanken mehr erkannt.

Hallo Florian,
ich kenne mich nicht so gut aus mit dem ARM, wo wird denn der Schimtt-Trigger, aktiviert? Ist damit die Hysterese gemeint.
Ich werde mal eine Z-Diode zum begrenzen des positive Eingangssignals an die Basis klemmen und den Widerstand R8 erhöhen (ca 91k). Einige Timings in der LIB kann ich noch nicht nachvollziehen. Denke das werde ich mal genauer analysieren um die Dekodierung stabiler zu machen (Trigger auf Flanke und Level Check nach ein paar us nach trigger, ). Wo wird den die Taktgenerierung initialisiert. Die MCU läuft bei mir mit 48MHz, sieht fast so aus als wäre dass der Default Wert mit dem internen RC Oszilator. Das Konfig Tool ist in der VM nicht aktivierbar- zeigt nur Memory an?

Christian,
ich meine natürlich einen Branch- werde mal GitKraken ausprobieren (kenne ich noch nicht).

LG
Horst

hora0816 hat geschrieben: ↑28. Jan 2021, 10:38 Hallo Florian,
ich kenne mich nicht so gut aus mit dem ARM, wo wird denn der Schimtt-Trigger, aktiviert? Ist damit die Hysterese gemeint.

Genau! In
bus.cpp
void Bus::begin()

pinMode(rxPin, INPUT_CAPTURE | HYSTERESIS); // Configure bus input

...hatte ich mir schon gedacht.
LG
Horst