Guten Tag! Ich bin dabei mein selbst erstelltes Board mit einem STM32F411VET6 in Betrieb zu nehmen. Ich habe schon zuvor das ganze mit dem Discovery Board getestet und in Betrieb genommen dabei hat alles funktioniert. Im Detail wird dabei zu einem SIM800C Modul daten ausgesendet und es sollten Daten zurückgelesen werden. Dazwischen ist auch ein Pegelwandler der zur Sicherheit Die Signale auf die 3,3V für den STM32 umwandelt. Es wurde bereits alles mit dem Oszilloskop gemessen, es wird ein Signal über die TX Leitung zum SIM800C ausgesendet und der SIM800C antwortet auch und sendet diese zurück bis zum STM32F411, dieses Signal kommt auch an bis zum PIN. Die Signale sehen dabei auch komplett schön aus und es gibt kein rauschen oder sonstiges drauf. Jetzt zum eigentlichen Problem: Egal was ich mache der STM32F411 möchte am RX Pin nichts auslesen, ich hab dies schon per Polling, IT und DMA probiert. Ich lasse mir dabei das Buffer an einem Display anzeigen und nie steht was drinnen. Ich habe zurzeit die IT Methode drinnen, d.h. sobald eine Nachricht empfangen wurde, wird wieder auf eine neue Nachricht gewartet usw... Der Programmcode den ich verwende ist hier zu finden: https://controllerstech.com/uart-receive-in-stm32/ unter Interrupt Method Auch der Interrupt is aktiv geschalten usw. ich hab bereits alles mögliche überprüft und komme nicht drauf warum er nichts empfangen möchte obwohl er perfekt aussendet. Kann es sein dass der PIN beschädigt ist oder so? Danke im Voraus!
Wichtig ist, daß die MODER + AFR des RX-Eingangs richtig gesetzt sind und daß bei USARTx->CR der Empfänger aktiviert wurde. Was ist denn der Inhalt dieser Register?
Angehängte Dateien:
m.n. schrieb: > Wichtig ist, daß die MODER + AFR des RX-Eingangs richtig gesetzt sind > und daß bei USARTx->CR der Empfänger aktiviert wurde. > Was ist denn der Inhalt dieser Register? Um die UART zu initialisieren und einzustellen verwende ich die Funktionen des STM32-CubeIDEs, dieser generiert mir folgenden Code für die UART2 (Im angehängten Bild zu sehen).
Stefan M. schrieb: > Um die UART zu initialisieren und einzustellen verwende ich die > Funktionen des STM32-CubeIDEs, dieser generiert mir folgenden Code für > die UART2 Das reicht aber nicht. Du zitierst einen Text ohne ihn offensichtlich verstanden zu haben. Zeige dein komplettes Projekt (als *.zip Datei, vorher cleanen).
uff basse schrieb: > Stefan M. schrieb: >> Um die UART zu initialisieren und einzustellen verwende ich die >> Funktionen des STM32-CubeIDEs, dieser generiert mir folgenden Code für >> die UART2 > > Das reicht aber nicht. Du zitierst einen Text ohne ihn > offensichtlich verstanden zu haben. > > Zeige dein komplettes Projekt (als *.zip Datei, vorher cleanen). Nein die Frage hatte ich sowieso net wirklich verstanden da ich nicht wirklich direkt auf Registerebene arbeite. Anbei ist mein komplettes Projekt mal zu sehen, dabei handelt es sich eben nur um ein Testprojekt mit Delays usw...
Stefan M. schrieb: > SOS_GPS_Tracker_BA2_V1.0.rar (4,6 MB) Was ist an dem folgenden Satz nicht zu verstehen? Zwei einfache Anweisungen und trotzdem geht's nicht? uff basse schrieb: > Zeige dein komplettes Projekt (als *.zip Datei, vorher cleanen).
uff basse schrieb: > Stefan M. schrieb: >> SOS_GPS_Tracker_BA2_V1.0.rar (4,6 MB) > > Was ist an dem folgenden Satz nicht zu verstehen? > Zwei einfache Anweisungen und trotzdem geht's nicht? > > uff basse schrieb: >> Zeige dein komplettes Projekt (als *.zip Datei, vorher cleanen). Wie schon erwähnt, ich arbeite nicht auf der Registerebene und vereinfache mir das Leben mit der CubeIDE und HAL Funktionen usw... Deshalb wusste ich nicht genau, um was es sich dabei handelte
:
Bearbeitet durch User
Stefan M. schrieb: > Deshalb wusste ich nicht genau, um was es sich dabei handelte Deshalb wollen wir auch gerne alle Sourcen sehen damit nichts anbrennt. Um den Kreis zu schliessen: m.n. schrieb: > Wichtig ist, daß die MODER + AFR des RX-Eingangs richtig gesetzt sind > und daß bei USARTx->CR der Empfänger aktiviert wurde. Bedeuted dass eben Pins initialisiert werden müssen, was dein Code aber auch tut. Erst jetzt wissen wir es. Das mit dem Clean von mir war voreilig, das ganze Projekt ist einfach so gross und kann nicht kleiner "gecleant" werden. Stefan M. schrieb: > Wie schon erwähnt, ich arbeite nicht auf der Registerebene Brauchst du auch nicht. Auf solche einfache Dinge kann man sich in CubeMX schon verlassen.
Ich hoffe mal nun das die gesendeten Daten von mir ausreichen, da wie schon von dir erwähnt ich leider da nichts kleiner mehr machen könnte... Danke!
Hast du mal RX und TX miteinander verbunden und die von dir benötigten 8 Bytes geschickt, damit der RX Interrupt ausgelöst wird?
123456 schrieb: > Hast du mal RX und TX miteinander verbunden und die von dir benötigten 8 > Bytes geschickt, damit der RX Interrupt ausgelöst wird? Danke für die gute Idee! Ich habe den Code jetzt nun Analog zu UART6 angepasst und da habe ich 8 Bytes drüber mal versendet und direkt über ein Kabel wieder zurück an die RX Leitung eingespeist. Hab auch wieder beides messen können mit dem Oszilloskop, nur leider Empfängt der Mikrocontroller wieder nichts... Ich habe das Gefühl ich übersehe irgendwie etwas komplett offensichtliches... Muss man etwas beachten bei UART wenn man nicht mehr das Discovery Board verwendet oder?
:
Bearbeitet durch User
Wie testest du, ob der Mikrocontroller etwas empfängt? Hast du einen Breakpoint im entsprechenden Interrupt Handler gesetzt?
123456 schrieb: > Wie testest du, ob der Mikrocontroller etwas empfängt? Hast du einen > Breakpoint im entsprechenden Interrupt Handler gesetzt? Ich habe es auf 3 Arten getestet: Ich lasse mir das Buffer in dem die Daten gelangen sollten, durchgehend an einem Display anzeigen. Zweitens habe ich eine LED realisiert die getoggelt werden sollte, sobald der Interrupt ausgelöst wurde. Und drittens habe ich auch über den Debugger versucht Daten rauszufinden, dabei konnte ich auch nicht fündig werden.
Stefan M. schrieb: > Ich habe das Gefühl ich übersehe irgendwie etwas komplett > offensichtliches... Ich sehe in der (deiner) while(1) Schleife keinen Aufruf Daten zu empfangen..... Stefan M. schrieb: > Muss man etwas beachten bei UART wenn man nicht mehr das Discovery Board > verwendet oder? Wenn du alles (UART Leitungen) so verdrahtet hast wie auf dem Discovery Board dann sollte es passen.
uff basse schrieb: > Stefan M. schrieb: >> Ich habe das Gefühl ich übersehe irgendwie etwas komplett >> offensichtliches... > > Ich sehe in der (deiner) while(1) Schleife keinen Aufruf Daten zu > empfangen..... > > Stefan M. schrieb: >> Muss man etwas beachten bei UART wenn man nicht mehr das Discovery Board >> verwendet oder? > > Wenn du alles (UART Leitungen) so verdrahtet hast wie auf dem > Discovery Board dann sollte es passen. Ich habe den Aufruf zum Datenempfangen vor der While Schleife gehabt. Hintergrundgedanke: Es sollten die Datenpakete empfangen werden und anschließend wird der Interrupt ausgelöstet. In diesem wird wieder ein Aufruf zur Datenabfrage gestartet usw. Ich hab es nun auch sicherheitshalber versucht direkt in der While Schleife zu starten, funktionierte leider auch nicht...
Stefan M. schrieb: > Es sollten die Datenpakete empfangen werden und > anschließend wird der Interrupt ausgelöstet. In diesem wird wieder ein > Aufruf zur Datenabfrage gestartet usw. Nicht erst nach einem Datenpaket, sondern nach jedem Zeichen muß ein Interrupt ausgelöst werden! Sowas:
1 | void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) |
2 | {
|
3 | HAL_UART_Receive_IT(&huart2, Rx_data, 4); |
4 | }
|
ist totaler Murks! Da kommt nach jedem 4. Zeichen ein Interrupt, und sobald du mal aus dem Tritt gerätst, geht nichts mehr. So kann man sowas realisieren:
1 | void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) |
2 | {
|
3 | HAL_UART_Receive_IT(&huart2, Rx_data, 1); |
4 | }
|
:
Bearbeitet durch User
Harry L. schrieb: > Stefan M. schrieb: >> Es sollten die Datenpakete empfangen werden und >> anschließend wird der Interrupt ausgelöstet. In diesem wird wieder ein >> Aufruf zur Datenabfrage gestartet usw. > > Nicht erst nach einem Datenpaket, sondern nach jedem Zeichen muß ein > Interrupt ausgelöst werden! > > Sowas: > >
1 | > void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) |
2 | > { |
3 | > HAL_UART_Receive_IT(&huart2, Rx_data, 4); |
4 | > } |
5 | >
|
> > ist totaler Murks! > Da kommt nach jedem 4. Zeichen ein Interrupt, und sobald du mal aus dem > Tritt gerätst, geht nichts mehr. > > So kann man sowas realisieren: >
1 | > void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) |
2 | > { |
3 | > HAL_UART_Receive_IT(&huart2, Rx_data, 1); |
4 | > } |
5 | >
|
Danke für die Antwort, mir geht es aber leider derzeit noch nicht was ich mit den Daten mache oder wie diese Ankommen. Sondern es besteht das Problem das NIE ein Interrupt ausgelöst wird, da der Mikrocontroller nie was liest. Ich hab es auch auf ein 1 Byte umgeändert, ebenso tut sich leider nichts. Ich hab jetzt Testhalber einfach eine UART Verbindung mit dem Arduino aufgebaut und ich kann damit ohne Probleme die Daten lesen die ich versende. Nur liest wiedermal der Rechner nichts, was ich an ihm versende.... langsam weiß ich echt nicht mehr weiter...
Stefan M. schrieb: > es besteht das > Problem das NIE ein Interrupt ausgelöst wird Hast du den Interrupt auch im CubeMX aktiviert?
Harry L. schrieb: > Stefan M. schrieb: >> es besteht das >> Problem das NIE ein Interrupt ausgelöst wird > Hast du den Interrupt auch im CubeMX aktiviert? Ja beide Interrupts also GLOBAL Interrupt USART2 & USART6 sind beide aktiv Danke!
:
Bearbeitet durch User
Stefan M. schrieb: > Ja beide Interrupts also GLOBAL Interrupt USART2 & USART6 sind beide > aktiv Dann solltest du das Problem zunächst in der Hardware suchen. Stefan M. schrieb: > Ich hab es auch auf ein 1 Byte umgeändert, ebenso tut sich leider > nichts. Hast du das auch beim 1. Aufruf (Initialisierung) geändert?
Harry L. schrieb: > Stefan M. schrieb: >> Ja beide Interrupts also GLOBAL Interrupt USART2 & USART6 sind beide >> aktiv > > Dann solltest du das Problem zunächst in der Hardware suchen. > Ja ich werd mal eine weitere Leiterplatte auflöten und testen! Danke allen hier für die Hilfe! > Stefan M. schrieb: >> Ich hab es auch auf ein 1 Byte umgeändert, ebenso tut sich leider >> nichts. > > Hast du das auch beim 1. Aufruf (Initialisierung) geändert? Ja habe ich gemacht
Stefan M. schrieb: > Ja ich werd mal eine weitere Leiterplatte auflöten und testen! > Danke allen hier für die Hilfe! Zuvor würde ich den betreffenden Pin als Ausgang schalten und "wackeln" lassen. Da sieht man, ob er richtig kontaktiert ist. Man kann ihn auch als Eingang schalten ext. dran wackeln und den Zustand ausgeben lassen. Oder man ließt die betreffenden Register und gibt deren hex-Wert aus. Aber gut, neu löten ist wohl einfacher ;-)
Stefan M. schrieb: > Wie schon erwähnt, ich arbeite nicht auf der Registerebene und > vereinfache mir das Leben mit der CubeIDE und HAL Funktionen usw... Genau DAS kann man hier an diesem Thread sehen. Insbesondere, wie du dir das Leben vereinfachst. Ja, du hast die ganze Zeit über etwas übersehen, nämlich daß du noch immer nicht begriffen hast, wie sowas funktioniert. Folglich kämpfst du die ganze Zeit gegen irgendwelche Funktionen von ST. Und daß du eine LED toggeln willst, um zu merken, daß da ein Interrupt passiert ist, wobei du gar nicht gemerkt hast, daß das, was du für eine ISR hältst, nur eine Callback-Funktion ist und das ganze eigentliche Interruptgeschehen woanders stattfindet. Natürlich kann es sein, daß der Chip, den du auf deine eigene LP gelötet hast, gerade an diesem Pin kaputt ist. Es kann aber noch viel eher sein, daß du mit deinem Firmware-Entwurf irgend etwas falsch gemacht hast. Vielleicht würde es sich auf lange Sicht doch für dich lohnen, etwas mehr von dem Chip zu wissen als du momentan weißt. Und das nicht durch die Brille der HAL und Cube, sondern direkt. Mal ne Frage: wo und wann hast du den Takt für diesen UART und für die GPIO's freigegeben? Oder für andere Peripherie-Cores, die du oder ST beim Initialisieren benutzt? W.S.
Angehängte Dateien:
W.S. schrieb: > Stefan M. schrieb: >> Wie schon erwähnt, ich arbeite nicht auf der Registerebene und >> vereinfache mir das Leben mit der CubeIDE und HAL Funktionen usw... > > Genau DAS kann man hier an diesem Thread sehen. Insbesondere, wie du > dir das Leben vereinfachst. > > Ja, du hast die ganze Zeit über etwas übersehen, nämlich daß du noch > immer nicht begriffen hast, wie sowas funktioniert. Folglich kämpfst du > die ganze Zeit gegen irgendwelche Funktionen von ST. Und daß du eine LED > toggeln willst, um zu merken, daß da ein Interrupt passiert ist, wobei > du gar nicht gemerkt hast, daß das, was du für eine ISR hältst, nur eine > Callback-Funktion ist und das ganze eigentliche Interruptgeschehen > woanders stattfindet. > Mir ist schon bewusst, dass es sich dabei um eine Callback Funktion handelt, die ausgeführt wird, sobald das Datenpaket erhalten wird. Dies ist mir alles klar, nur vereinfach kann ich es auch einfach als Interrupt nennen für mich selbst !:) > Natürlich kann es sein, daß der Chip, den du auf deine eigene LP gelötet > hast, gerade an diesem Pin kaputt ist. Es kann aber noch viel eher sein, > daß du mit deinem Firmware-Entwurf irgend etwas falsch gemacht hast. > Vielleicht würde es sich auf lange Sicht doch für dich lohnen, etwas > mehr von dem Chip zu wissen als du momentan weißt. Und das nicht durch > die Brille der HAL und Cube, sondern direkt. > Wie erwähnt, ich hab die gleichen Einstellungen usw. alles gleich gemacht wie schon zuvor auf einem Discovery Board, es gibt garkein Unterschied. Mir fällt leider nichts weiteres mehr ein, woran es liegen könnte. > Mal ne Frage: wo und wann hast du den Takt für diesen UART und für die > GPIO's freigegeben? Oder für andere Peripherie-Cores, die du oder ST > beim Initialisieren benutzt? > > W.S. Die ganzen Takte wurden ebenso mit der CubeIDE intialisiert, siehe Bild. Und ich habe nun eine weitere Platte verlötet usw, Verbindung mit dem Rechner klappt auch wieder, wie schon zuvor. Und das gleiche Problem wie zuvor ist wieder zu erkennen... Hätte vielleicht noch wer Ideen?
Bist du dir sicher, dass die Pins alle richtig sind und deine Bibliothek für das Custom-Design stimmt? Prüf' doch bitte nochmal Pin-Nummer gegen Datenblatt oder stell' zur Hardware etwas zur Verfügung. Der bereits vorgeschlagene Test über GPIO Input oder Output die Basisfunktionalität des Pins zu prüfen ist auch sinnvoll.
Stefan M. schrieb: > Dies > ist mir alles klar, nur vereinfach kann ich es auch einfach als > Interrupt nennen für mich selbst Bleibe lieber bei der Wahrheit. Das vereinfacht sowohl das eigene Denken als auch die Diskussion mit anderen Leuten. Also, du sagst, daß alles funktioniert, wenn du deine Firmware auf einen baugleichen Chip auf einem Nucleo-Board brennst. Bloß bei deinen eigenen Leiterplatten funktioniert es nicht. Da schätze ich mal, daß dir da keiner wirklich helfen kann, weil so ein Fehler nur erklärt werden kann, wenn eines hiervon zutrifft: - beim Nucleo-Board wird der µC anders verschaltet als auf deinem Board. Kann sein, daß deine Schaltung fehlerhaft ist oder SO nicht zutrifft. z.B. ein anderer Pegel an einem Boot- bzw. Debug-Bein. - der µC auf dem Nucleo-Board ist echt, die von dir gekauften µC sind Fakes oder sind anderweitig kaputt. - in deiner Firmware steckt ein fieser Fehler, an den weder du gedacht hast noch irgendein Leser deines Beitrages kommen würde, weil der sich nur nach den von dir geschilderten Dingen richten kann. W.S.
Marcel B. schrieb: > Bist du dir sicher, dass die Pins alle richtig sind und deine Bibliothek > für das Custom-Design stimmt? > Ja ich bin mir sehr sicher, ich habe gerade nochmal alles überprüft und bin mir zu 100% sicher das es vom Pinning her passt. Ich werd mal paar Bilder von der Schaltung herzeigen... > Prüf' doch bitte nochmal Pin-Nummer gegen Datenblatt oder stell' zur > Hardware etwas zur Verfügung. Der bereits vorgeschlagene Test über GPIO > Input oder Output die Basisfunktionalität des Pins zu prüfen ist auch > sinnvoll. Ich hab den Test gerade eben mal gemacht, ich hab beide UART Pins als OUTPOUT definiert und habe die jeweils alle 500ms Toggeln lassen einfach. Beides konnte ich mit dem Oszi nachmessen und funktioniert auch alles gescheit. Anbei wie erwähnt mal der Pfad vom UART zum SIM Modul...
W.S. schrieb: > Stefan M. schrieb: >> Dies >> ist mir alles klar, nur vereinfach kann ich es auch einfach als >> Interrupt nennen für mich selbst > > Bleibe lieber bei der Wahrheit. Das vereinfacht sowohl das eigene Denken > als auch die Diskussion mit anderen Leuten. > > Also, du sagst, daß alles funktioniert, wenn du deine Firmware auf einen > baugleichen Chip auf einem Nucleo-Board brennst. Bloß bei deinen eigenen > Leiterplatten funktioniert es nicht. Da schätze ich mal, daß dir da > keiner wirklich helfen kann, weil so ein Fehler nur erklärt werden kann, > wenn eines hiervon zutrifft: > - beim Nucleo-Board wird der µC anders verschaltet als auf deinem Board. > Kann sein, daß deine Schaltung fehlerhaft ist oder SO nicht zutrifft. > z.B. ein anderer Pegel an einem Boot- bzw. Debug-Bein. > - der µC auf dem Nucleo-Board ist echt, die von dir gekauften µC sind > Fakes oder sind anderweitig kaputt. > - in deiner Firmware steckt ein fieser Fehler, an den weder du gedacht > hast noch irgendein Leser deines Beitrages kommen würde, weil der sich > nur nach den von dir geschilderten Dingen richten kann. > > W.S. Die Schaltung ist natürlich unterschiedlich als 1:1 von einem Discovery Boards, da viele Funktionen einfach nicht genutzt werden die für meine Anwendung notwendig sind. Ebenso kann es sich nicht um einen "Fake uC" handeln, da dieser auf Mouser bestellt wurde und der Hersteller offensichtlich STM ist. Ich habe bereits mein ganzes STM32-Projekt verteilt und ebenso verteile ich auch gern meine Schaltung, wie auch in der Antwort davor getan. Auch auf den STM32-Discovery Boards gibt es keine extra Beschaltung für die UART-Schnittstelle. Ebenso erklärt es für mich eben nicht, das jede andere Funktionalität gegeben ist vom Rechner her, also Schaltung, Inputs einlesen usw usw., ausser eben das Einlesen einer UART-Schnittstelle per RX Pin. Für mich erklärt sich das alles genauso wenig, wie auch wahrscheinlich für dich, wenn alles schon zuvor auf einem Discovery Board gelaufen ist. Deshalb stelle ich auch die Frage hier...
Ich kann hiermit melden ich hab endlich das Problem nach 2 Tagen gefunden:)! Zur Info beim Problem handelte es sich nicht um Unwahrheiten oder "Fake Chips" oder sonstiges :) Sondern das Problem war das durch den erstellten Code vom CubeIDE, die UARTs zuerst initialisiert wurden bevor es die GPIOs wurden. Dies hatte irgendwie den Effekt das eben die UART Kommunikation nicht gescheit lief und dies hat sich nun endlich behoben! Nun funktioniert auch mein kompletter Code wie schon zuvor bei einem Discovery Board :)! Ich danke allen für die Hilfreichen antworten :)!
Das glaube ich fast nicht. Zumindest in dem von dir geteilten Projekt wird das richtig herum gemacht.
1 | MX_GPIO_Init(); |
2 | MX_I2C1_Init(); |
3 | MX_USART2_UART_Init(); |
4 | MX_USART6_UART_Init(); |
ki? schrieb: > Das glaube ich fast nicht. Zumindest in dem von dir geteilten Projekt > wird das richtig herum gemacht. > >
1 | > MX_GPIO_Init(); |
2 | > MX_I2C1_Init(); |
3 | > MX_USART2_UART_Init(); |
4 | > MX_USART6_UART_Init(); |
5 | >
|
Ja das stimmt, ich merke gerade auch das ich es auch wieder so rum habe nach dem ich wieder was am Programm geändert habe. Nur UART6 wird vor UART2 initialisiert, ich versteh echt nicht warum es davor nicht funktioniert hat. Ich weiß nur jetzt gerade funktioniert es obwohl ich sonst nichts verändert habe...
Stefan M. schrieb: > Sondern das Problem war das durch den erstellten Code vom CubeIDE, die > UARTs zuerst initialisiert wurden bevor es die GPIOs wurden. Fang erst garnicht an, daß auch noch zu glauben oder sogar als Wissen zu verinnerlichen. Ich sehe mir den HAL-Krempel nicht an, aber zu jeder Initialisierung einer USART gehört auch die Initialisierung der Portpins. Andernfalls hätte das Senden ja auch nicht funktionieren dürfen. Stefan M. schrieb: > Ich weiß nur jetzt gerade funktioniert es obwohl ich > sonst nichts verändert habe... Du hättest zwischen den beiden Tagen Fehlersuche einen Tag Pause einlegen sollen.
Stefan M. schrieb: > Dies hatte > irgendwie den Effekt das eben die UART Kommunikation nicht gescheit lief > und dies hat sich nun endlich behoben! Tja, immer wieder das "irgendwie". Bloß nicht wissen wollen, was tatsächlich abgeht. Also, zum Einstellen von Pin-Funktionalitäten muß zuvor der entsprechende Core über einen Takt verfügen, sonst kann man in die zugehörigen Register schreiben "im Himmel ist Jahrmarkt" und den Chip interessiert es nicht. Das ist vom Prinzip her bei allen Peripherie-Cores das gleiche, die Auswirkungen sind bloß von Fall zu Fall unterschiedlich, weil es ab Reset jeweilige Default-Belegungen gibt und die Projekte eben unterschiedlich sind. Das Manual zu lesen, ist da weitaus hilfreicher, als sich nur auf irgendwelche maschinell erzeugten Firmware-Rümpfe zu verlassen und zu sagen "da ich nicht wirklich direkt auf Registerebene arbeite". W.S.
Stefan M. schrieb: > Ebenso kann es sich nicht um einen "Fake uC" handeln, da dieser auf > Mouser bestellt wurde und der Hersteller offensichtlich STM ist. Ist dir eigentlich klar, daß man woanders auf jedes Chip-Gehäuse drauflasern kann, was man will? Was ist dabei offensichtlich? Mir kommt da der Witz vom Kellner im Restaurant in den Sinn: "Welchen Wein wünschen die Herrschaften? Wir haben alle Etiketten da." Ich habe auch einige OpV's von Analog Devices da, die eben keine OpV's sind und schon gar nicht von AD hergestellt worden sind. W.S.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.