Flir Lepton + STM32 = OwO? Firmware Friemeln

[Chefbastler]

So hab mir mal ein Flir Lepton 3.0 an nen STM32F407 angeflanscht.
Welches ich aus ner Flir One recycled hab:

So, zum Problem:

Das Viech hat eine SPI Schnittstelle für Video und Telemetriedaten(Die ist für mich auch soweit klar) und eine 16Bit I²C für Controll(Da hab ich so meine Probleme).

So das Ding will mit exotischen 16Bit Datenstrings mit 7Bit Adresse am I²C gefüttert werden. Das macht die Hardware vom STM32 so jetzt nicht nativ.
Bevor ich da jetzt mit Bitbanding anfange, hat da wer von Euch ne Idee wie ich das am blödesten mit dem Hardware I2C hingemurkst bekomme? Als Problem sehe ich da die ACK die bei der Hardware alle Byte daherkommen und bei 16Bit dann störend wird.

Datenblätter:

Allgemeines Datenblatt:
https://lepton.flir.com/wp-content/uplo ... et-203.pdf

Software side Datenblatt:
https://www.flir.com/globalassets/impor ... cument.pdf

[Fritzler]

Is mir jetz aus dem stehgreif nicht bekannt.
Welcher Prozessor war denn da vorher drauf?
Kann die Beschriftung nicht lesen.
Wenn der auch kein 16Bit I2c hat, dann bleibt nur Bitbongo.

Steht aber auch dort, dass es nur I2C similar ist:

two-wire interface similar to I2C (the only difference relative to the true I2C standard is that all Lepton registers are 16 bits wide and consequently, only 16-bit transfers are allowed).

Was auch immer die da geraucht haben, dass das nicht auch nen SPI ist.

[Chefbastler]

Der hier.

Edit:

Ah, ich Interpretier hier raus das das schon normal I2C ist mit nur 16bit Register dann zu bedienen über jeweils zwei Byte.

[Fritzler]

Hättst auch einfach schreiben können, dann hättste dir den Aufwand zum knipsen erspart.
Ja, die AVR Datenblätter (die alten in SW!) sind super, aber was Atmel da bei den ARM DBs verzapft ist einfach nur pervers.
Bei nem ATSAM A5 steht drinne, dass der DMA Prioritäten hat.
SCHREIBEN DANN ABER NICHT HIN WELCHER DMA KANAL DIE HÖCHSTE PRIO HAT!
Musste ich dann ausprobieren...
Mal abgesehen von sehr kranken Fehlern im SDIO Teil des DB.
Aus dem Grund werden wir wohl keine Neueuntwicklungen mit Atmel ARMs mehr machen.

Zum Thema:
Der kann auch keine 16Bit Daten.
Selbst den 3 Byte Adressingmode kannste nicht missbrauchen, der will auch nach jedem Byte nen ack.

Wie oft musste denn dem I2C was reinschieben?
BitBongo tut vllt garnicht mal so weh.
Wenn du auf die acks vom Sensor eiskalt verzichtest, kannste auch per STM32 DMA direkt auf den GPIO Pins trommeln.

auch edith:
Dann gehts ja.
Woher hasten das Bild?
In dem engineer pdf gabs ja nur Prosa und kein Diagramm.

[Chefbastler]

uch edith:
Dann gehts ja.
Woher hasten das Bild?
In dem engineer pdf gabs ja nur Prosa und kein Diagramm.

In der "Software IDD" Seite 17

Hättst auch einfach schreiben können, dann hättste dir den Aufwand zum knipsen erspart.

Foto hatte ich hier noch auf dem Rechner

[Fritzler]

Dann wär I2C ja geklärt.

Was mich jetz aber interessiert ist wie du das Bild anzeigen willst.
Son 240x240px IPS ChinaLCD?

[Chefbastler]

Naja oft schreiben muss ich nicht, aber ich will den Videomode von RAW14 auf RGB888 umstellen, Farbpalette einstellen und Telemtriedaten einschalten

[Chefbastler]

Dann wär I2C ja geklärt.

Was mich jetz aber interessiert ist wie du das Bild anzeigen willst.
Son 240x240px IPS ChinaLCD?

Ja, so ein ST7735 128x160 Pixel Display.

[Fritzler]

Da bin ich ja mal gespannt, das würd sich ja echt lohnen das nachzufrickeln.

LAN wäre noch nett um Bilder Remote und automatisiert abzurufen.
zB um zu gucken wie warm ein DCDC Wandler beim durchgrillen wird

[Kenakapheus]

Ich habe gerade mal etwas im Reference Manual gewühlt:
16Bit Empfangen ließe sich vermutlich mit etwas gefrickel per Clockstretching implementieren,
aber 16 Bit Senden ohne ACK in der Mitte nicht wirklich.

Eventuell kann man die I2C Statemachine ausreichend manipulieren um das irgendwie mit der Hardware hinzubekommen,
aber den Code wird dann definitiv niemand mehr verstehen.

Also wird Bit Bang das Sinnvollste sein.