Hi,

ich muss eine BLE-Schnittstelle mit ProtocolBuffers implementieren. Die Schnittstelle ist hier https://www.makinolo.com/blog/2024/1...iner-protocol/ in dem Kapitel "Trainer Control (0x04)" beschrieben.

// The command code prepending this message is 0x04
message HubCommand {
optional uint32 PowerTarget = 3;
optional SimulationParam Simulation = 4;
optional PhysicalParam Physical = 5;
}

message SimulationParam {
optional sint32 Wind = 1; // Wind in m/s * 100. Zwift fixes to 0. Negative is backwind
optional sint32 InclineX100 = 2; // Incline value * 100
optional uint32 CWa = 3; // Aero coefficient CW * a * 10000. Zwift fixes to 0.51 (5100)
optional uint32 Crr = 4; // Rolling resistance Crr * 100000. Zwift fixes to 0.004 (400)
}

message PhysicalParam {
optional uint32 GearRatioX10000 = 2;
optional uint32 BikeWeightx100 = 4;
optional uint32 RiderWeightx100 = 5;
}

Und das Beispiel
04 2a 08 10 00 20 81 05 28 c4 3b
müsste nun folgendes ergeben:
{
"Physical": {
"BikeWeightx100": 641,
"RiderWeightx100": 7620
}
}

Irgendwie will mir dies aber nicht gelingen, wenn ich es encodiere, kommt
04 2a 0a 25 81 02 00 00 2d c4 1d 00 00
raus.

Kann mir jemand auf die Sprünge helfen, was ich hier falsch mache? Bei Beispielprojekt ist angehängt.

Grüße, Philipp

Es könnte vielleicht an der Umsetzung varint zu FixInteger32 liegen, aber ich glaube das hast Du schon ausprobiert,
wenn ich die Kommentare sehe.

markieren

Code:

  // Alt:
  type TZwiftPhysicalParamTest = record
    [Serialize(4)] BikeWeightx100: FixedUInt32; //uint32
    [Serialize(5)] RiderWeightx100: FixedUInt32; //uint32
  public
    procedure Initialize;
  end;

  // Neu:
  type TZwiftPhysicalParamTest = record
    [Serialize(4)] BikeWeightx100: UInt32; // uint32 als VarInt
    [Serialize(5)] RiderWeightx100: UInt32; // uint32 als VarInt
  public
    procedure Initialize;
  end;

Es wird wohl für die VarInt‑Kodierung eine Bit-Codierung verwendet
https://protobuf.dev/programming-gui...oding/#varints

Prinzip:
Bei VarInt wird der Zahlenwert in 7-Bit‑Blöcke unterteilt. Jedes Byte trägt 7 Bit der Information. Alle Bytes außer dem letzten haben das MSB (Most Significant Bit) auf 1, um anzuzeigen, dass weitere Bytes folgen.

Beispiel (Wert 641):
641 (dezimal) = 0x281 (hex)
Erster 7‑Bit-Block:
641 mod 128 = 1 → wird als 0x01 kodiert, aber da noch mehr Bytes folgen, wird 0x80 dazugerechnet: 0x01 | 0x80 = 0x81
Zweiter Block:
641 >> 7 = 5 → passt in 7 Bit, also ohne MSB: 0x05
Ergebnis: 0x81 0x05

So ungefähr, wenn ich das richtig sehe.

Wird das so umgesetzt im Grijjy-Code? Hab ich jetzt nicht gecheckt.

Und die Protokoll-Buffer Elemente sind optional, das heisst die müssen nicht in dem Übertragungsstream sein,
aber ich glaube das behandelt Grijjy schon.

Grijjy unterstützt glaube ich auch nicht verschiedene Endian, je nachdem wo die Daten herkommen.

Ich habe es jetzt einmal mit der Implementierung von Marat Shaymardanov ausprobiert. Damit komme ich dem ganzen schon viel näher. Ich schätze es hat mit den optionalen Elementen zu tun.
Statt
04 2a 08 10 00 20 81 05 28 c4 3b
kommt nun
04 2a 06 20 81 05 28 c4 3b
raus.

Falls die ProtoBuf Schnittstelle mal komplexer wird, schau doch mal auf meine Weiterentwicklung des ProtoBuf Generators - über 2 Umwege basiert das auf dem Code von Marat Shaymardanov:

https://github.com/modersohn/ProtoBufGenerator

Der Unterschied war jetzt noch, dass ein optionales Element mit 0 trotzdem bei dem dokumentierten Beispiel übertragen wurde. Beide Varianten ergeben https://www.protobufpal.com/ hier das gleiche. Also meine Implementierung stimmt jetzt schon mal, das sie nichts tut, ist nun noch eine andere Sache.

Ok, die Marat Shaymardanov-Implementierung war jetzt unter Windows für mich erfolgreich. Unter Android kachelt sie in
procedure TProtoBufOutput.writeUInt32(fieldNumber: integer; value: cardinal);
leider ab. Ist deine (@msohn) Implementierung Cross-Platform-fähig. Würde ich mir dann später einmal anschauen.

Deine Implementierung geht in die richtige Richtung, du kannst folgendes aber allgemein gültig machen, damit auch Android unterstützt wird und unter Windows tut es auch nicht weh:

procedure TProtoBufOutput.writeRawData(const buf; size: integer);
begin
FBuffer.Add(@buf, size);
//writeRawData(@buf, size); //endless loop for some OS
end;

Das klingt, als ob der Compiler das falsche Overload aufruft und damit eine Endlosschleife und irgendwann einen stack overflow erzeugt.

Das Problem hatte ich mit macOS, s.a. hier https://github.com/modersohn/ProtoBu...ator/issues/38 - und habe es dort etwas hemdsärmlich mit einem IFDEF gelöst.

Welche Compilerversion setzt Du ein?

Ich hab das jetzt konsequenterweise für alle Plattformen und Compiler gelöst, indem ich das overload mit dem const untyped entfernt habe; das war ja nur für die Bequemlichkeit.

Details in https://github.com/modersohn/ProtoBu...ator/issues/42