Hallo Da mein Findungsprozess (welcher BUS und welcher Controller) mich zum LPC11C24 gebracht hat, werde ich mir den mal bestellen zum testen. Mein ziel (unter anderem) ist einen UP Aktor mit 2 Relais, als Rolladen Aktor. Am besten hintern den Schalter, ansonsten in die Dose daneben. Nun habe ich schon einige Threads gesehen die diesen Chips und teilweise schon für den UP geplant haben. Leider sind die Threads teilweise schon sehr alt. Daher würde ich mich freuen, wenn sich der eine oder andere der diesen Chip schon als UP Knoten (oder co) geplant hat, und eventuell die Eagle Datei oder sogar ein bisschen Code zur Verfügung stellen könnte. Ich erwarte kein voll lauffähiges System, nur eben einen guten Start für mein Projekt. Danke für jeden der sich hier meldet :D
Hallo, > oder sogar ein bisschen Code zur Verfügung stellen könnte. Zwar kein Device-Code, aber falls du den integrierten CAN-Bootloader verwenden möchtest, findest du hier ein Bootloader-Tool (Host-GUI) inklusive Quellcodes und nötiger Minimalbeschaltung: http://www.fischl.de/can/bootloader/canflasherutnl/ Gruß Thomas
Super danke, habe zwar schon viel gesucht und gefunden zum LPC ... aber die kannte ich noch nicht und ist auf jeden Fall sehr interessant und brauchbar. Danke
Angehängte Dateien:
-
schaltplan.png
20 KB -
board.png
35 KB
So ich hänge mal meinen ersten Entwurf vom Schaltplan hier rein ... vielleicht kann mal wer drüber schauen. Das Board ist auch dabei, wobei das NUR Autorouter ist, und die Wege noch nicht kontrolliert sind ... kommt vielleicht mal später wenn alles fixiert ist (oder auch nicht)
Der 10uF am Eingang ist vielleicht etwas arg knapp, der CAN-Transceiver kann schon ganz schöne impulsförmige Belastung bringen. Das Widerstandsnetzwerk an RX/TX gegen 24V, da erschließt sich mir der Sinn nicht. Das wäre mir zu riskant, schließlich hat ja jeder Widerstand und jede Leiterbahn auch einen kapazitiven Effekt, da können die 24V gerne mal impulsförmig durchschießen. Und warum Autorouter für ein solches Layout? Der Autorouter ist innAusnahmefällen mal partiell zu gebrauchen, etwa wenn man eine Busstruktur zwischen benachbarten Bausteinen herstellen möchte und dann auch nur für die Signale, nicht für die Power. So wie es sich darstellt, könnte man es beim besten Willen manuell nicht schlechter machen. Das schreit ja geradezu nach Störungen einfangen und aussenden... in der UP-Dose, wo nebenan 230V Verbraucher geschaltet werden, ist das wirklich suboptimal.
Danke für den Input ... 10µF hab ich genommen, da es als beim Recom so angegeben war, werde aber dann einen größeren nehmen. Das mit dem Widerstandasnetzwerk verstehe ich nicht? Was meinste damit - eigentlich habe ich da kein Widerstandsnetzwerk drinnen. Autorouter deswegen, weil sich sicher noch das eine oder andere ändern wird, und ich nur eine schnelle Lösung haben - bevors dann final wird .. werde ich dann noch mal händisch drüberschauen (und dabei auch die Groundflächen auf beiden Seiten mit mehreren Durchkontaktierungen vorsehen)
Andi S. schrieb: > Das mit dem Widerstandasnetzwerk verstehe ich nicht? Was meinste damit - > eigentlich habe ich da kein Widerstandsnetzwerk drinnen. R0,5,6,7
Ich würde alle Bauteile auf eine Seite bringen, das is gute Designpraxis. Jeder Auftragsfertiger, der das sehen würde, würde mit den Augen rollen. Ohne Not macht man das nicht. Wenn Du Teile sparen willst, ersetze die Widerstände und den BSS138 gegen Digitaltransistoren, wie z.B. BCR505 (Reichelt) oder PDTD123YT oder ... Und warum BAS16L über den Spulen? In Vorwärtsrichtung ist jede Diode schnell. Außerdem gibt es keine zu vernichtende Rückwärtsspannung, wenn man der Diode einen Weg anbietet, jede Standarddiode reicht.
Noch etwas: Du solltest PIO0_1 mit auf den RX/TX Stecker legen, wenn dieser Pin beim Reset auf Low gehalten wird, geht der LPC in den eigenen Bootloader und du kannst ganz bequem per serieller Schnittstelle ein Update machen. Du kannst auch via CAN auf diese Weise updaten, dann muss aber PIO0_3 zusätzlich auf Low während des Resets. Wenn man es ganz toll haben möchte, hat man einen Steckverbinder mit 3.3V,GND,RX,TX, Reset und PIO0_1 auf einem Steckverbinder, dann kann man mit so einem USB-Kabel, wo ein USB-to-serial Converter drin ist, ein Update durchführen. (So etwas http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm) Das Programm dazu heißt Flash Magic, auch für CAN-Updates geeignet (wenn man den passenden Adapter hat, z.B. von Peak)
R0+R6 und R5+R7 sollte ein Spannungsteiler sein um aus den 24V die 3.3V für den Eingang zu generieren. Bas16L - keine Ahnung warum ich die hatte, hab die irgendwo gesehen in einer Relais Schaltung - werde dann eine normale 1n4148 nehmen Kann ich den digital Transistor so 1:1 nehmen? oder brauche ich da noch andere Vorwiderstände um mit 3.3V die 24V fürs Relais zu steuern?
Andi S. schrieb: > R0+R6 und R5+R7 sollte ein Spannungsteiler sein um aus den 24V die 3.3V > für den Eingang zu generieren Aber warum nicht einfach Pull-Up gegen 3.3V? Das wäre für mich logisch. > > Bas16L - keine Ahnung warum ich die hatte, hab die irgendwo gesehen in > einer Relais Schaltung - werde dann eine normale 1n4148 nehmen > Bei den kleinen Relais reichen auch LL4148 (1N4148 in SOD80C) > Kann ich den digital Transistor so 1:1 nehmen? oder brauche ich da noch > andere Vorwiderstände um mit 3.3V die 24V fürs Relais zu steuern? Kannst du so nehmen ohne weitere Widerstände. In Eagle findest du auch Symbole für RETs (Resistor-Equipped-Transistor). Ich glaube in der Tranistor-LIB
Ein paar Ideen: - 230V Isolation sieht ungenügend aus, evtl. wird es einfacher wenn du für K2 ein Schließer-Relais nimmst - Snubber? - Die Dioden über den Spulen sind schlecht für die Lebensdauer der Relais, schalte lieber Z-Dioden über die FETs - Die Versorgung könnte robuster sein, je nach Kabellänge würde ich da zumindest eine Transil Diode und PESD1CAN einbauen, gerne auch einen Filter - Was macht der Spannungsteiler am UART? - Spendier 1-2 230V feste Eingänge um vorhandene Taster einlesen zu können - Das Quarz Layout ist murks, sorry - C11 ist in THT kleiner zu bekommen - Status LED würde ich noch einbauen, als Debug/Test Hilfe - ADC Pins für Lichtsensor rausführen?
R5-R8 : ja ist total unlogisch - das kam weil es am Anfang ein Optokoppler war, der mit 24V von den Tastern gespeist wurde. Das ich dann gegen einen einfachen Spannungsteiler getauscht habe, was aber so keinen Sinn mehr macht ... werde das dann vermutlich gleich weglassen. Den von den Störungen sollte ja eigentlich egal sein, ob ich mit dem 3.3V zu den Taster gehen ... den GND ist ja so und so immer die gleiche.
@Bla Quarz Layout: wird umgebaut C11 wird noch größer und kontrolliere die Bauteilgröße Spannungsteiler am UART war Murks Status LED kommt auch 230 V Eingänge wenn gebraucht wäre gedacht per I2C Connector ... aber prinzipiell gehe ich zu den Taster auch mit 24V/3.3V Kannst mir das kurz erklären : Die Dioden über den Spulen sind schlecht für die Lebensdauer der Relais, schalte lieber Z-Dioden über die FETs? Aktuelle würde ich das Relais mit einem BCR505 schalten. PESD1CAN wird eingebaut Welche Transil didoe würdest du vorschlagen?
Andi S. schrieb: > Kannst mir das kurz erklären : Die Dioden über den Spulen sind schlecht > für die Lebensdauer der Relais, schalte lieber Z-Dioden über die FETs? > Aktuelle würde ich das Relais mit einem BCR505 schalten. Siehe hier z.B. Beitrag "Z-Diode für Relais (Freilaufdiode)"
Wenn du externe Taster anschließt: Taster mit vergoldeten Kontakten gehen bei uC Eingängen eigentlich immer - kein Problem. Wenn Du aber mit handelsüblichen Tastern arbeitest, die normalerweise 230V schalten, wirst du vermutlich nach einiger Zeit ein Problem bekommen. Die Kontaktmaterialien in leistungsstarken Schaltern "brauchen" ein wenig Abbrand, damit sich keine Oxidschicht bildet. Bei wenigen Microampere würde es aber zur Oxidbildung kommen. Irgendwann schaltet der Kontakt dann nicht mehr. Man kann zur Vermeidung dieses Problems per Lastwiderstand einen Mindeststrom fließen lassen, wobei 20..50mA in den meisten Fällen schon reichen sollte.
Harald A. schrieb: > Siehe hier z.B. > Beitrag "Z-Diode für Relais (Freilaufdiode)" Ja, dieser Beitrag enthält eine Menge Müll und Fehlaussagen. Insbesondere den der beschreibt dass mit Freilaufdiode die Abschaltung 6mal länger dauert und dadurch die Kontakte abbrennen... Hier wird aber leider der mechanische Aufbau des Relais außer acht gelassen. Klar dauert es mit Freilaufdiode länger bis der Haltestrom des Relais unterschritten wird. Danach wird aber der magnetische Fluss unterbrochen und damit auch die Kraft die der noch fließende Strom erzeugt schlagartig dramatisch kleiner. Die Abfallgeschwindigkeit wird dann nur noch von den Federn im Relais bestimmt. Die Kontakte fangen auch erst an zu öffnen wenn der Anker des Relais schon eine "Weile" in Bewegung ist. Für konkrete Zahlen muss man die Abfallgeschwindigkeit des Ankers im Arbeitspunkt (Kontakt öffnet gerade) messen und nicht die Zeit die vergeht bis sich der Anker in Bewegung setzt.
Ich selbst habe auch noch nie etwas anderes als normale Dioden eingesetzt und auch noch nie Probleme gehabt, auch nicht nach ewiger Betriebszeit. Aber der Andi fragte danach und daher die Verlinkung! Interessante Betrachtungsweise übrigens, vermutlich hast du damit Recht! Als ich den verlinkten Thread las, war ich doch nach all den Jahren doch glatt wieder ins Grübeln gekommen. Aber dann können wir ja so weitermachen! @Andi: dann nimm doch eine BAT54C, das ist eine Doppeldiode in passender Konfiguration für beide(!) Relais im winzigen (naja, sagen wir kleinem) SOT23 Gehäuse.
Der Quarz benötigt 100nF Kondensatoren? Ungewöhnlich. Das Layout wurde ja schon erwähnt.
@Harald: Du meinst eine Bat54C für beide Relais (und das mit der Z-Diode lassen)?
Ach, was soll der Geiz, bleib einfach bei zwei stinknormalen 1N4148 in SMD. Aber ja, sonst hätte man auch eine Doppeldiode nehmen können, wobei man dann allerdings etwas auf die max. Belastung schauen müsste.
Angehängte Dateien:
-
schaltplan.png
21 KB
So das ist nun die aktuelle Version vom Schaltplan ... muss nun mal Die Bauteile im Board richten und den Autorouter mal testen lassen (wird irgendwann dann eh noch von Hand gemacht)
An K1 fehlt jetzt die Freilaufdiode. Vorschlag: Den 1. Elko C11 evtl noch etwas größer falls die Versorgungsspannung schwankt und eine Eingangsdiode gegen Verpolung davor.
Freilaufdiode ist da, eine BAT54C für beide Relais. Das ist im Moment der größte 63V Elko, den ich in dieser Bauform gefunden habe.... eventuell könnte ich auf 50V runter gehen? (bei 50V gäbe es einen 220µF)
Andi S. schrieb: > Freilaufdiode ist da, eine BAT54C für beide Relais. Stimmt, die Art der Darstellung auf ein anderes Versorgungssymbol hat mich verwirrt.
Die 1µF an der 5V Schiene wären mir noch etwas wenig. Mir erscheint hier eine Verzehnfachung auf 10µ Kerko oder mehr angebrachter als beim Elko am Eingang um jedes µF zu kämpfen. Den MCP1700 als Spannungsregler hätte ich auch nicht verwendet. Allein schon weil das Pinout nicht den gängigen Spannungsreglern entspricht. Man liest auch das der etwas zickig sein kann, allerdings habe ich mit den keine eigenen Erfahrungen. Alternativen wären LP2950 oder LM2936. Oder wenn der Preis wichtiger als der Querstrom ist auch TS1117. Den Eingängen die an X3 liegen hätte ich persönlich auch ein universelleres und sichereres Eingangsnetzwerk verpasst. So bleibt als einzige Möglichkeit der Taster gegen GND. Selbst dann ist ein Serienwiderstand + kleines C vor dem Eingang das mindeste damit die internen Schutzdioden nicht bei jedem Spike abrauchen. Ich hätte mir beim PCB jedenfalls nicht die Möglichkeit verbaut auch 24V verträgliche Eingänge realisieren zu können. Oben wurde die These aufgestellt, man solle nur von einer Seite bestücken. Dem würde ich dahingehend widersprechen, dass man den Platz für ein universelles R-C-D(ZD) Netzwerk für die beiden Haupteingänge nutzen sollte. Was davon am Ende und wie bestückt wird entscheidet dann der Einsatzort.
temp schrieb: > Oben wurde die These aufgestellt, man > solle nur von einer Seite bestücken. Dem würde ich dahingehend > widersprechen, dass man den Platz für ein universelles R-C-D(ZD) > Netzwerk für die beiden Haupteingänge nutzen sollte Die "These" besagte, dass man nicht ohne Not(!) doppelseitig bestücken sollte(!). Wenn es die Umstände erfordern, ist nichts gegen doppelseitige Bestückung einzuwenden, sei es aus Platzmangel oder aus EMV Gründen. Bzgl. der 1uF an der 5V Schiene: Hast Du gesehen, dass da ein Schaltregler eingesetzt wurde? Also am besten an die Dimensionierung halten, sonst kann es bei der impulsförmigen Belastung durch den CAN instabil werden. In den übrigen Ausführungen gebe ich Dir Recht!
... was ich mir gerade überlege (hab auch das Can@home projekt gelesen) Ob ich einen zusätzlichen I2CEEprom (24C32) dazubauen sollte? Da der LPC11C24 nur flash hat, und wenn ich zB.: Die anzahl der Schaltzustände und die Betriebsdauer der Relais als Status mitspeichern will, ist eventuell der Flash nicht so geeignet?
sn00py schrieb: > ... was ich mir gerade überlege (hab auch das Can@home projekt > gelesen) > Ob ich einen zusätzlichen I2CEEprom (24C32) dazubauen sollte? > > Da der LPC11C24 nur flash hat, und wenn ich zB.: Die anzahl der > Schaltzustände und die Betriebsdauer der Relais als Status mitspeichern > will, ist eventuell der Flash nicht so geeignet? Gelegentlich zu ändernde Konfigurationsdaten gehen sehr gut im Flash abzuspeichern, für sich ständig ändernde Werte ist das aber nichts. Durch die ROM-Funktionen sind die Flashzugriffe auch sehr einfach handzuhaben. Aber was willst du mit der Betriebsdauer der Relais oder der Anzahl der Schaltzustände? Wenn es nen Euro mehr kosten darf dann nehme kein EEPROM sondern FRAM. Da kann man bis zum Abwinken drauf herumschreiben und muss sich nicht um Write- und Erase-Timings kümmern. Z.B. FM24C64 oder auch ne kleinere Version
Übrigens erscheint die Beschaltung der Relais-Ausgänge an X1 nicht ganz logisch. So wie es jetzt ist, kann man einen Rolladenaktor davon bauen aber keine zwei unabhängige Schaltkontakte, z.B. für normale Beleuchtung oder z.B. zum Auslösen der Programmierung bei elektronischen Rolladenmotoren (typischerweise beide Eingänge gleichzeitig bestromt). Lege doch den Umschalterkontakt beider Relais noch an X1-L4 Und vielleicht noch ne P6SMB36CA als Überspannungskiller an den 24V Eingang. Oder besser noch ne leistungsstärkere SMC36CA, die ist allerdings auch sehr "fett".
Harald A. schrieb: > Bzgl. der 1uF an der 5V Schiene: Hast Du gesehen, dass da ein > Schaltregler eingesetzt wurde? Also am besten an die Dimensionierung > halten, sonst kann es bei der impulsförmigen Belastung durch den CAN > instabil werden. Hab ich gesehen. Der Recom kann 220µF am Ausgang treiben laut Datenblatt bzw. 6800µF mit Schutzdiode. Die eingebaute Kapazität im Schaltregler am Ausgang ist ein Kompromiss bezüglich der mechanischen Größe. Deshalb würde ich hier nicht zu knapp dimensionieren. Weiter Dimensionierungsvorgaben für die Ausgangskapazität enthät das Datenblatt des Recom nicht. Die MCP1700 (aus dessen Datenblatt stammen die 1µF) sind vorranging für batteriebetriebene Kleingeräte entwickelt, da gelten andere Spielregeln als im vorliegenden Einsatzfall.
Angehängte Dateien:
-
schaltplan.png
24 KB
So hab nun mal einiges geändert - übrigens GROßEN DANK an alle die hier so tollen Input geben!!!!!!! Das mit den Schaltzuständen (bzw Schaltspiele) und Betriebsdauer habe ich im can@home gelesen die speichern das im EEPROM ab ... und ist einfach ein interessantes Feature (muss ich ja dann nicht bestücken) * SMC36CA * 2*47µF (5V + 3.3V) * Quarz nu 18p * MCP1700 ersetzt durch den LM2936 * FM24C16 * X1-L4 bedrahtet Frage1: Suppresor Didoe so richtig? Frage2: "Ich hätte mir beim PCB jedenfalls nicht die Möglichkeit verbaut auch 24V verträgliche Eingänge realisieren zu können" Wie würde so eine generelle Lösung aussehen, wo ich so wie gehabt aber auch mit 24V direkt beschalten könnte?
Andi S. schrieb: > Wie würde so eine generelle Lösung > aussehen, wo ich so wie gehabt aber auch mit 24V direkt beschalten > könnte? Im einfachsten Fall einfach eine 3.1V Z-Diode parallel mit einem 100nF und einem Pull-Down an den entsprechenden Eingang gegen Masse. Davor ein passender Längswiderstand, dimensioniert passend für die Z-Diode (Achtung: Leistung des Widerstands beachten, bei z.B. einer Z-Diode mit 0,35W ein Vorwiderstand 3,3kOhm hätte dann ca. 170mW Verlustleistung bei 27V Eingangspannung, muss also ein 1206 Package sein)
hallo, warum hast du eigentlich den Abschlusswiderstand auf zwei Widerstände R10 und R11 aufgeteilt? Gruß Thomas
weil normalerweise dann zwischen den beiden widerstände noch ein kondi gegen masse gehören würde ...
Angehängte Dateien:
-
schaltplan.png
24 KB -
board.png
68 KB
So, nach kurzer Pause mein Schaltplan und Board ... werde mal paar Prototypen bei seeedstudio bestellen (wenn es keine groben Einwände mehr gibt) GND Flächen kommt noch auf beide Seiten drauf
Der C4 1n ist ja immer an CANL, würde den also nur bei gestecktem Abschlussjumper Sinn haben. Funktioniert trotzdem, keine Frage, aber bei z.B. 30 Modulen am Bus hätte man CANL schon einseitig mit 30nF belastet, CANH nicht. Und zeige nochmal die finale Version mit Masselayer. Kleiner Tip: mache Ripup all und trenne dich komplett von dem Autorouter-Murks, fange mit einem Bottom Masselayer an, Massevias passend legen und dann möglichst alles auf dem Top-Layer routen (manuell!). Wo es nicht geht, so kurz wie möglich auf dem Masselayer ausweichen, sprich diesen nicht komplett zerteilen.
Angehängte Dateien:
-
board.png
86 KB -
schema.png
63 KB
Danke der sollte eigentlich schon weg sein, samt den zwei 60 Ohm (die zwei Abschlusswiderstände kommen dann zentral dort hin wo sie gebraucht werden) Das mit dem nicht Autorouter funktioniert nicht, hab paar mal angefangen und dann wieder alles verworfen, ich werde das Ergebnis vom Autorouter akzeptieren.
Der Masselayer hängt offenbar nicht an Masse. Zumindest haben die Massepins keine Anbindung. Du musst den Masselayer an der Seite mit Name anklicken und GND benennen. So wie es jetzt ist hast du eher eine Antenne im Sinne von Anti-EMV Edit: evtl. ist es doch richtig, ist schwer zu erkennen. Bringen tut es natürlich nur etwas, wenn die Massepads der SMDs mit einem Via auf kurzem Wege mit GND verbunden ist. So sind ja nur die Stiftleisten verbunden, was soll da der Masselayer bringen?
Mit diesen Abständen zwischen der 230V Seite der Relais und dem Rest bist du noch dreister als diverse chinesische Netzteilhersteller. Tu dir einen Gefallen, übe das Layouten. So kann man das niemanden zu Fertigen geben. Oder willst du ernsthaft sowas als Bestückungsdruck?
Andi S. schrieb: > ich werde das Ergebnis vom Autorouter akzeptieren. Übrigens schade, dass das schöne Projekt so endet.
Angehängte Dateien:
-
board_top.png
68 KB -
board_bottom.png
65 KB
Doch die Flächen auf Bottom und Top sind beides GND Layer Ich habe vor dem Router bei jedem SMD Pad das auf dem Top Layer liegt und GND ist, einen Via gesetzt. Und danach noch ein paar einzelne Gnd Vias
Den Quarz bekommt man schnuckelig klein in 3,2 mm x 2,5 mm, sowas hier: https://www.conrad.de/de/quarzkristall-euroquartz-12000mhz-mt3030-40-8512pf-smd-4-12000-mhz-12-pf-32-mm-25-mm-07-mm-1009302.html Damit würdest du einigen Platz sparen.
Angehängte Dateien:
-
board_bottom.png
70 KB -
board_top.png
75 KB
Danke Quarz ist getauscht und die Abstände von den 230V Relais sind nun auch etwas großzügiger.
Andi S. schrieb: > die Abstände von den 230V Relais sind nun > auch etwas großzügiger. mit ca 3mm aber trotzdem so klein, dass die komplette Verkabelung incl. CAN-Bus 230V tauglich erfolgen muss. Netzwerkkabel o.ä. geht da nicht mehr.
temp schrieb: > Andi S. schrieb: >> die Abstände von den 230V Relais sind nun >> auch etwas großzügiger. > > mit ca 3mm aber trotzdem so klein, dass die komplette Verkabelung incl. > CAN-Bus 230V tauglich erfolgen muss. Netzwerkkabel o.ä. geht da nicht > mehr. Hast du Infos wie weit die 230V von der digitalen Seite entfernt sein muss, damit ich dann normale CAT-5 Kabel verwenden darf?
https://de.wikipedia.org/wiki/Kleinspannung Wenn deine Kleinspannung die Bedingungen für SELV oder PELV nicht erfüllt weil die Kriechstrecken zu klein sind musst du mit den Regeln für FELV leben. Geh mal von 8mm aus. Optokoppler mit 7,5mm Abstand reichen nicht aus wie man in den meisten Netzteilen sehen kann. Entweder man fräst die Platine zwischen den Beinen großzügig aus oder nimmt Optokoppler mit 10mm Abstand. Viel Glück dabei das dem Autorouter beizubringen.
Angehängte Dateien:
-
board.png
88 KB
So, habs noch mal drübergearbeitet ... Abstand vergrößert und die Platine auffräsen. Und die eine oder andere Leiterbahn händisch verlegt ;)
Ok, aber die Fräser sind rund und benötigen einen Radius (mit 1mm ist man auf der sicheren Seite). Ist die Kontur im Milling-Layer? PCB Bude darauf hinweisen oder eindeutige Gerberdaten erzeugen
Sind die Relais denn geeignet, einen Rollladenmotor direkt zu betreiben? So ein Rollladenmotor ist schon etwas anderes, da gibt es spezielle Legierungen für die Kontakte der Relais. Außerdem sind da dann Spannung an den Kontakten, welche weit über der Netzspannung liegen. Eventuell wäre es auch besser, mit einem Relais die Richtung auf/ab zu steuern und in Reihe ein Relais für ein/aus. Grüße Thomas
Ich hoffe das die geeignet sind ... sind halt "normale" 230V Relais :O Ja da ist eh eines für Auf/ab und das andere für ein/aus designed. Wobei man es auch für 1*Um und 1*Ein/Aus umspezifizieren kann.
Also ich habe mal Prototyping bei www.smart-prototyping.com bestellt ... ist es für andere interessant - der Verlauf und co von solch billigst China PCB Produzenten?
hmmmm, wollte gerade die Bauteile bestellen und draufgekommen, das der LM2936MP-3.3 eventeull doch nicht so geeignet ist, ich hab den ja an der 5V Versorgung dran hängen, aber laut Datenblatt, hat der VIn erst ab 5.5V. Mit den 50mA sollte der LPC + FRAM ja auskommen ... Soll ich einen anderen nehmen, oder soll ichs austesten ob der mit 5V auch zurecht kommt, oder lieber auf die 30V Seite hängen?
Andi S. schrieb: > Soll ich einen anderen nehmen, oder soll ichs austesten Laut Datenblatt wird das schon arg eng. Besser LM 1117?
Danke, der scheint viel besser zu passen, werde es mit dem probieren. Andere Frage, gibt es eigentlich einen günstigeren Ersatz was ich für den Recom R7850-10 nehmen kann??? der kostet fast so viel wie die restlichen Bauteile zusammen.
Achtung, der LM1117 hat ein anderes Pinning, Output in der Mitte! Geht vielleicht anstelle R7850-10 auch der R78E50-05?
Oh total drüber geschaut das der ein ganz anders Layout hat ... Und ja, der R78E50-05 passt auch besser von der Eingangsspannung her (28V im Gegensatz zu den 18V) Kennt wer einen Pinkompatiblen Ersatz für den LM2936MP-3.3 den ich mit 5 V betreiben kann im SOT223? Was ich mir überlegt habe, wäre den LM2936MP-3.3 direkt mit den 24V zu Betreiben, also die 5V zu trennen un fliegend zur Eingangsspannung verbinden?
Du kannst den LM2936 direkt an 5V betreiben. Es reicht, wenn die Eingangspannung 1V über der Ausgangsspannung ist. Nur die HV Version benötigt 5,5V. Die HV Version benötigst du aber gar nicht.(höhere maximale Eingangsspannung möglich) Gruß Thomas
Laut Datenblatt : LM2936 Operating VIN range of 5.5 V to 40 V LM2936HV Operating VIN range of 5.5 V to 60 V der MCP 1703-3302 schaut gut aus, preislich gleich, baulich gleich danke nochmal an alle!
LP2950 sollte auch passen. Eventuell passt die D-Pack Version direkt auf deine Pads. Für meine privaten Sachen löte ich auch die TO92 Version auf ansonsten mit SMD bestückte Platinen. Einfach nur weil ich die immer ausreichend vorrätig habe und die auch oft genug auf Lochrasterplatinen wandern.
Andi S. schrieb: > Laut Datenblatt : > LM2936 Operating VIN range of 5.5 V to 40 V > LM2936HV Operating VIN range of 5.5 V to 60 V > > der MCP 1703-3302 schaut gut aus, preislich gleich, baulich gleich > > danke nochmal an alle! Nicht nur die erste Seite vom Datenblatt lesen :-) Kapitel 6.6 , Dropout ist maximal 0,4V. Selbst mit 4V funktioniert der 3,3V Regler. Ansonsten wäre die Bezeichnung als LDO auch unangebracht. Gruß Thomas
Hallo Den Quarz kannst Du auch ganz weg lassen und mit dem internen Oszillator arbeiten. Gruß Ulf
Ulf schrieb: > Hallo > > Den Quarz kannst Du auch ganz weg lassen und mit dem internen Oszillator > arbeiten. > > Gruß Ulf Bei CAN würde ich das auf jeden Fall mit Quarz machen. Man kann zwar über die Synchronisation Jumpwidth SJW eines wett machen, aber mit Quarz funktioniert es zuverlässiger.
so, mein erster versuch ging mal schief :( hab mal 5V angelegt, und der LPC wird mal extremst heiss ... ich hoffe ich habe noch rechtzeitig die Verbindung gekappt bevor er nun ganz den geist aufgibt .... wie gehe ich da nun am besten vor damit ich rausfinde obs am schaltplan/layout oder doch am löten liegt?
Andi S. schrieb: > hab mal 5V angelegt, und der LPC wird mal extremst heiss Mit dem Durchgangsprüfer jeden Pin gegen seinen Nachbarpin prüfen ob da nicht eine versehentliche Lötbrücke besteht. Selbiges Pin gegen Masse.
So bin erst heute dazugekommen zum messen (musste mir noch dünne Messspitzen besorgen) Gegen Masse habe ich alles erfolgreich geprüft, da ist nix einzig einen "Kurzschluss" habe ich der meiner Meinung nach aber nicht das Ergebnis haben dürfte. Und zwar ist der PIO1_5 mit der 3.3V Leitung kurzgeschlossen (leider schon alles etwas verbaut und etwas scher zum beheben muss ich dann mal gucken) Aber da der PIO1_5 als Eingang verwendet wird, sollte das nicht das Problem verursachen oder? Ich habe die Angst das ich noch was anderes (Fehler im Schematic) übersehe??
Also ich baue nun einen zweiten Versuch auf, der LPC ist mal eingelötet und geprüft. Im Moment nur der LPC, wenn ich nun 3.3V anlege dann braucht der mal 0.66mA Ich hätte nun auch SWCLK und SWDIO angeschlossen, aber per LPC kann ich den noch nicht programmieren. Sonst ist noch nichts angelötet ... Was brauche ich mindestens um den per SWD zu programmieren zu können? Quarz? Reset Leitung?
die Reset Leitung sollte dran, der Quarz ist soweit ich weiß nicht unbedingt nötig.
Das Problem ist im LPC bekomme ich eben einen Fehler das er es nicht programmieren kann. Aber es tut sich etwas, der Chip braucht wenn ich versuche zu programmieren dann statt den 0.66mA nur mehr 0.46mA Diese SWO Leitung brauche ich (hoffentlich) eh nicht dafür? die habe ich leider nicht nach aussen gelegt, habe überall nur gelesen das ich SWDIO und SWCLK brauche.
siehe User Manual UM10398, S. 453. SWO brauchst du nicht, PIO0_1 eventuell (wenn die clock settings so verstellt sind das er nach Reset nicht mehr auf die Füsse kommt). Mit welchem Adapter programmierst du den denn? VTarget wollen die meisten Adapter auch haben.
Also ich verwende den LPC Link 2, hab da den J6 eingelötet und vorsorge nun meinen LPC direkt mit GND, +3.3V, SWDIO, SWCLK und RESET mit einem Board von Olimex (mit dem 20 poligen Stecker + Adapeter) kann ich den programmieren. Auf was sollte ich den PIO0_1 setzen? Oder als nächstest mal den Quarz einlöten?
Der Quarz ist nicht nötig, der LPC11C24 läuft auch mit dem internen 12 MHz RC Oszillator. Aber der J6 am LPCLink2 ist ein Problem, ich habe den auch modifiziert. Entweder du setzt noch den Jumper JP2, dann wird der µC über den Pin1 vom J6 mit Strom versorgt. Das habe ich bei meinem durch Trennen von SJ1 1-2 geändert, der µC soll seine eigene Versorgung haben. Der JP2 muss dann trotzdem rein, der sorgt dafür das die IO Buffer mit der Targetspannung betrieben werden. PIO0_1 kann normal offen bleiben, nur um den LPC in den Bootloader zu bringen muss der beim Reset auf Low liegen.
Hast du bei deinem letzten Layout mal einen drc Check laufen lassen in Eagle? manche Abstände erscheinen mir schon grenzwertig klein, kann aber auch am Bild liegen. An P0_1, P0_3 und Reset solltest du ca. 3.3V messen da die PullUp-Widerstände nach den Reset an sind. Sonst stimmt was nicht. Ich denke die 0.46 bzw. 0.66mA sind zu wenig wenn ich mich recht erinnere. Wenn du die Versorgung über den lpc-link 2 machst sollte JP2 gesteckt sein wenn mich nicht alles täuscht.
Ah okey habe nun den JP2 geschlossen, nun kommt er weiter Der Falshvorgang geht durch, und im LPCExpresso zeigt er mir den Thread als laufend an. Was noch komisch ist, beim Olimex Board bleibt mir der Debugger sofort im main stehen (ist ja irgendwo eingestellt) das macht er bei meinem aber noch nicht?
Das liegt jetzt eher an der SW. Jetzt hängst du vermutlich in einem Hardfault, siehst du im Disassembly View. Eventuell weil die SW auf den Quarztakt umschaltet.
JojoS schrieb: > Jetzt hängst du vermutlich in einem Hardfault Hab es noch nie geschafft bei den LPC einen Hardfault zu produzieren, trotz der Cortex M0 Unzulänglichkeiten. Aber läßt sich ja einfach prüfen: im Hardfault Handler zum Test eine LED anschalten.
Andi S. schrieb: > Was noch komisch ist, beim Olimex Board bleibt mir der Debugger sofort > im main stehen (ist ja irgendwo eingestellt) Das kann man über die 'Debug Configurations' einstellen, in der Symbolleiste an dem Käfer den Pfeil anklicken. Dann im Tab 'Debugger' das 'Stop on startup at:' auf den Reset Handler stellen, wie der heisst steht im startup code, bei LPC/MCUXpresso und generiertem Linkerfile 'ResetISR' oder beim gcc 'Reset_Handler'. Damit fängt das Debuggen beim Reset an durchläuft den startup code und das SystemInit wo der Takt eingestellt wird. Im Debug Fenster ist dann noch ein Symbol i->, damit aktiviert man das instruction stepping und kann im Disassembly durchsteppen.
Wenn die gleiche Konfiguration mit dem Olimex-Board geht, kann's ja an den Einstellungen in der IDE nicht liegen. Wir kennen aber auch deinen Testcode nicht. Eventuell versucht ja dein Code in SystemInit() den Quarz einzuschalten der noch nicht draufgelötet ist?
so zuerstmal danke an alle, ist jetzt mal so lauffähig das ich mal weitertesten kann. Es war der fehlende Quarz nun (nach dem Hauptproblem mit dem JP2) nun verhält er sich mal gleich wie das Olimex Board, und bleibt im main stehen. der Verbrauch ist nun mit dem Quarz auch auf fast 2mA gestiegen ... Aber noch mal eine Frage zu meinem ersten Versuch, kann es sein, das "nur" durch die Verbindung PIO1_5 zu +3.3V ich den LPC geschrottet habe? Die Brücke habe ich nun rausbekommen, beim Verbinden braucht der nun 55mA, aber das kann sein, da der (fast) ganz bestückt ist.
Andi S. schrieb: > der Verbrauch ist nun mit dem Quarz auch auf fast 2mA gestiegen ... normal weil jetzt ja der Oszi schwingt. Ohne Quarz sollte es auch gehen, dann muss aber im SystemInit SYSPLLCLKSEL_Val=0 gesetzt werden. > (nach dem Hauptproblem mit dem JP2) damit versorgt der Adapter dann aber auch die Schaltung über D4. Oder man lässt die Leitung von Pin1 zum Target weg, dann muss man aber aufpassen das das Target auch immer mit der gleichen Spannung wie das Target betrieben wird. Um es genauso zu machen wie über die JTAG Stecker ist es besser die Diode D4 zu entfernen (SJ1 öffnen war glaube ich schwieriger). > Aber noch mal eine Frage zu meinem ersten Versuch, kann es sein, das > "nur" durch die Verbindung PIO1_5 zu +3.3V ich den LPC geschrottet habe? wenn der nicht als Ausgang geschalter war dann eher nicht. Am Spannungsregler gehen Leiterbahnen sehr eng vorbei, war das alles ok?
Muss noch mal genauer schauen, wegen der alten Platine, auf jeden Fall bin ich draufgekommen das ich den Falschen Schaltregel bestellt hab (und beim einlöten nicht noch mal kontrolliert habe) haben den Pin INkompatiblen LM1117 MP-3.3 bestellt. (Werd dann mal schauen obs ohne dem LowDrop Regler geht) Aber zusätzlich noch einen LM2936MP-3.3 Was mich gerade etwas verwundert, der LM2936MP-3.3 bekommt 4.7V vom Board, und gibt aber 2.8V aus??? Kann das sein weil ich die Kondis noch nicht drinnen habe? den Strom zieht er (auf der 4.7V Schiene in normalen Bereich)
So nur mal kurz zwischendurch getestet, mit den 2*47µF Kondi, liefert der DropDown nun auch korrekt 3.3v. Und im ersten Board, habe ich den falschen DropDown ausgebaut, der funkt nun auch mal so wie der zweite.
Andi S. schrieb: > Kann das sein weil ich die Kondis noch nicht drinnen habe? Ohne Kondensatoren kann jeder Regler schwingen. Könnte durchaus sein, wenn Du 2.8V gemessen hast. Auf einem Scope könnte man es belegen.
So möchte nun den FRAM mal durchtesten ... welche Library sollte ich da am besten verwenden dafür?
hmmmm, hat zufällig wer ein funktioniernede Besipiel mit dem LPC11C24 und I2C ? Ich habe versucht das Demo I2C zu adaptieren, aber das schlug fehl. Wollte das i2c_probe_slaves starten, aber das bleibt im Chip_I2C_MasterRead hängen. Und der I2C_IRQHandler wird auch nie aufgerufen ...
Okey, einen schritt bin ich weiter .... Er läuft mir nun durch (hatte vergessen die zwei PullUps bei SDA und SCLK einzulöten, auf der Platine) Allerdings liefert mir Chip_I2C_MasterRead auf allen Addressen 0 zurück Müsste mir der FM24C16 da schon was zurückliefern oder? (Speed habe ich auf 100kHz gestellt) Was ich auch nicht gefunden habe die addresse von dem Teil, ist die 80 (0x50) ?
Adresse FM24C16 steht doch im Datenblatt Bit 7..0 = 1 0 1 0 A2 A1 A0 RW Ansonsten: Logic Analyzer (ab 7€) ist dein Freund!
Logic analyser ist bestellt. Das mit den Bits verstehe ich nicht ganz, so wie das aussieht wäre da ja das Bit7 auf 1 - das würde eine Adresse von über 0x80 dachte die gehen nur bis 0x7F ?
Ja, das ist eines der beliebtesten Missverständnisse im Bereich I2C. Man spricht bei der ADRESSE über die Bits 1..7. Im Bit 0 wird Read/Write übergeben. Beide Informationen sind zusammen in ein Byte gepackt. Da die Adresse um ein Bit geshiftet ist, erscheint sie im Programmcode und ggf. im Analysewerkzeug verdoppelt. So wird aus der eigentlichen Adresse 0x50 das Byte 0xA0 bzw. 0xA1 je nach R/W Bit.
Andi S. schrieb: > So möchte nun den FRAM mal durchtesten ... welche Library sollte ich da > am besten verwenden dafür? Habe gerade mal geschaut, zwischen dem 24C16 und dem FM24C16 gibt es kaum Unterschiede - gleiche Adresse, gleiche Prozedur. Einziger Unterschied: Wenn man beim normalen EEP mehrere Bytes nacheinander schreiben möchte, muss man sich zwischen zwei verschiedenen Pages-Write Methoden entscheiden, das wird mit dem Mode-Pin festgelegt. Nach 8 bzw. 16 Bytes muss man eine Pause einlegen, damit das Zeug geschrieben werden kann. Nicht so beim FRAM: Dan kann man einzelne Bytes schreiben oder auch den ganzen Speicher am Stück durchschreiben, es gibt eben keine Programmierzeiten, die man abwarten müsste. So schnell wie man auf I2C schreibt wird auch gespeichert.
Harald schrieb: > Ja, das ist eines der beliebtesten Missverständnisse im Bereich I2C. > > Man spricht bei der ADRESSE über die Bits 1..7. Im Bit 0 wird Read/Write > übergeben. Beide Informationen sind zusammen in ein Byte gepackt. Da die > Adresse um ein Bit geshiftet ist, erscheint sie im Programmcode und ggf. > im Analysewerkzeug verdoppelt. > So wird aus der eigentlichen Adresse 0x50 das Byte 0xA0 bzw. 0xA1 je > nach R/W Bit. Das bedeutet ich muss dann beim Chip_I2C_MasterRead(i2c, i, ch, 1 + (i == 0x48)) > 0 in der i2c_probe_slave statt dem for (i=0;i<0x7f;i++) auf for (i=0;i<0xff;i++) abändern? Also habe folgenden Code getestet
1 | /* Function that probes all available slaves connected to an I2C bus */ |
2 | void i2c_probe_slaves(I2C_ID_T i2c) {
|
3 | int i; |
4 | uint8_t ch[2]; |
5 | |
6 | DEBUGOUT("Probing available I2C devices...\r\n");
|
7 | DEBUGOUT("\r\n 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F");
|
8 | DEBUGOUT("\r\n====================================================");
|
9 | for (i = 0; i <= 0xfF; i++) {
|
10 | if (!(i & 0x0F)) {
|
11 | DEBUGOUT("\r\n%02X ", i >> 4);
|
12 | } |
13 | if ((i <= 7) || (i > 0xf8)) {
|
14 | DEBUGOUT(" ");
|
15 | continue; |
16 | } |
17 | /* Address 0x48 points to LM75AIM device which needs 2 bytes be read */ |
18 | if (Chip_I2C_MasterRead(i2c, i, ch, 1 + (i == 0x48)) > 0) {
|
19 | DEBUGOUT(" %02X", i);
|
20 | } |
21 | else {
|
22 | DEBUGOUT(" --");
|
23 | } |
24 | } |
25 | DEBUGOUT("\r\n");
|
26 | } |
leider kam er niemals in den code rein wo Chip_I2C_MasterRead > 0 wäre
So habe nun (da ich ja SDA, SCLK, 3.3V und GND) nach aussen geführt habe, so eine PCF8574 Modul angeschlossen. Und die obrige Routine findet wiederum nichts ... hier mal mein Init Code
1 | static void Init_I2C_PinMux(void) {
|
2 | Chip_SYSCTL_PeriphReset(RESET_I2C0); |
3 | Chip_IOCON_PinMuxSet(LPC_IOCON, IOCON_PIO0_4, IOCON_FUNC1); |
4 | Chip_IOCON_PinMuxSet(LPC_IOCON, IOCON_PIO0_5, IOCON_FUNC1); |
5 | } |
6 | |
7 | static void i2c_set_mode(I2C_ID_T id) |
8 | {
|
9 | Chip_I2C_SetMasterEventHandler(id, Chip_I2C_EventHandler); |
10 | NVIC_EnableIRQ(I2C0_IRQn); |
11 | } |
12 | |
13 | void I2C_IRQHandler(void) {
|
14 | i2c_state_handling(I2C0); |
15 | } |
16 | |
17 | |
18 | /* Initialize the I2C bus */ |
19 | void i2c_app_init(I2C_ID_T id, int speed) {
|
20 | Init_I2C_PinMux(); |
21 | |
22 | /* Initialize I2C */ |
23 | Chip_I2C_Init(id); |
24 | Chip_I2C_SetClockRate(id, speed); |
25 | |
26 | /* Set default mode to interrupt */ |
27 | i2c_set_mode(id); |
28 | } |
29 | |
30 | main .... |
31 | i2c_app_init(I2C0, SPEED_100KHZ); |
32 | i2c_probe_slaves(I2C0); |
Leider fehlt der Code im Gesamtüberblick. Keiner kann erraten was sonst noch so passiert. Ich hänge mal i2c.h und i2c.c an wie ich sie hier auf dem LPC11C24 laufen habe. Auch mit FRAMs. Ganz am Ende gibt es auch die Funktionen: int i2c_rd_eeprom(uint32_t Addr, void *pOut, uint32_t len); int i2c_wr_eeprom(uint32_t Addr, const void *pIn, uint32_t len); Vielleicht hilft es dir. Ansonsten warte auf den LA. Alles andere ist Kaffeesatzleserei.
Also code ist das alles was ich verwende an I2C ... werde aber mal schaun was ich mit deinem Code anfangen kann, leider ist der irgendwie zu meinem LPX Entwicklungsumgebung nicht so richtig kompatible, da findet er die includes und sonstiges alles nicht, bekomme nur ne Menge an Fehler - hatte ich glaub ich mit dem CAN damals auch.
Muss nun noch mal blöd fragen : Was ist der Grund warum in meinem LPX Expresso die variablen und konstanten alle anders heissen als bei "euch"? Statt LPC_SYSCON muss ich LPC_SYSCTL schreiben und LPC_IOCON hat bei mir auch keine PIO0_4 das sind nur mal die ersten "Probleme" Hab ich da vom falschen Beispiel weggearbeitet? Ich ahbe da das nxp_lpcxpresso_11c24_periph_blinky verwendet und eben so weit angepasst was ich gebraucht habe ... sollte ich ein anderes nehmen, das ich nicht jedesmal alles für mich umarbeiten muss?
1 | /* Set default mode to interrupt */
|
2 | i2c_set_mode(id); |
laut LPC_Open Beispiel sollte das
1 | i2c_set_mode(id, 0); |
sein. Meckert der Compiler da nicht oder ist das nur unvollständig hier rein kopiert? Du verwendest die LPC_Open, die ist neuer und hat ein anderes API und damit auch andere Headerfiles. Ich könnte dir bei Interesse ein mbed Projekt generieren, damit haben meine I2C Komponenten immer auf Anhieb funktioniert.
nein meckert nicht da ich die funktion umgeändert habe und das polling entfernt habe ... siehe obigen code
1 | static void i2c_set_mode(I2C_ID_T id) |
2 | {
|
3 | Chip_I2C_SetMasterEventHandler(id, Chip_I2C_EventHandler); |
4 | NVIC_EnableIRQ(I2C0_IRQn); |
5 | } |
Kann ich dieses mbed Projekt, dann auch im LPC Expresso gleich verwenden? Sprich mir ist wichtig das das Flashen und Debuggen gleich funktioniert, der Rest ist mir egal. wenn ja - würde ich mich sehr freuen :D - und danke vorab :D
Die geänderte Funktion hatte ich übersehen. Das Debuggen funktioniert genauso, mbed + Xpresso ist plug and play. Nur der Export von der mbed Website klappt nicht immer, deshalb habe ich mich da selber eingearbeitet. Ich würde erst noch das Update auf MCUXpresso empfehlen, ist der Nachfolger von LPCX und es sieht erstmal alles gleich aus. MCUX kennt zusätzlich die von NXP zugekauften Kinetis µCs. Dann habe ich gerade noch ein LPCXpresso 11C24 Board rausgekramt und teste das erstmal kurz damit. Die 11C24 sind zwar nicht auf den offiziellen mbed Boards zu finden aber trotzdem in der Lib. Diese werden nicht alle mitgetestet und können der Entwicklung etwas hinterher hinken. Ein Blinky kompilieren ging aber schonmal. Nochmal zu deinem Board: hast du die I2C Pins mal gegen die Nachbarn, + und GND gemessen? Denn auch die mitgelieferten LPC_Open Beispiele sollten ja funktionieren.
achso, das mbed ist im web? - hmmm ich mag diese cloud sachen nicht so gerne, ich hab da immer gerne ein VMWare wo ich die Teile drinnen habe, und samit dann eine halbe Ewigkeit laufen da drinnen. Eigentlich schon alles getestet (und als ich die pullups vergessen hatte, hing sich das system auf - nach dem einlöten der pullups lief der code durch, aber liefert eben immer 0 zurück) Am Dienstag kommt mein Logik Analyzer .. vielleicht sehe ich dann mehr, und werde auf jedenfall dann noch die zweite Platine testen ... sicher ist sicher
man kann den mbed online compiler benutzen, muss man aber nicht. Die Projekte kann man exportieren nach makefile oder verschiednen IDEs. Im Anhang ist so ein exportiertes Projekt für LPCXpresso (für MCUX muss eine Zeile in der .cproject Datei geändert werden falls du das installiert hast). Ich habe da einen FRAM Code mit reingepackt. Der ist für einen anderen Baustein, aber die Sequenzen sind ja meist gleich, am besten mal Debugger durchsteppen. Die Ausgaben habe ich allerdings noch nicht mit semihosting hinbekommen. mbed biegt das printf standardmässig auf die serielle Schnittstelle um, Pin P1_7 und P1_6 wären das hier. Ich versuche das noch hinzubekommen, es ist nur etwas anders weil kein managed linker script verwendet wird und damit die Automatiken von NXP nicht wirken. Wenn das managed eingeschaltet wird gibt es viele Linkerfehler weil mbed das Standard GCC Linkerfile nutzt. CAN Support ist auch in der Lib drin. Der Charme an der Lib ist das man ein einheitliches API für die Hardware hat das es für viele Cortex-M gibt. Am Ende bleibt das Programm in einer Endlosschleife, die LED1 müsstest du durch einen Portpin deiner HW ersetzen.
Sooo ich hab nun mal den (gerade bekommen logik analyzer dran hängen) Die Signale sehen soweit mal gut aus - ich bekomme niemals einen ACK sondern immer ein NACK Was ich nun vermute ist, ich habe den FRAM ja an 3.3V dran hängen, aber laut Datenblatt will der minimum 4.5V ... oder lese ich hier das Datenblatt falsch? http://www.farnell.com/datasheets/1855451.pdf?_ga=2.106843843.1922693626.1503311988-1553270278.1488354609 VDD Power supply 4.5 5.0 5.5 V Kann es das sein? Und wenn ja, bekomme ich probleme, wenn ich da nun die 3.3 V Leitung kappe und auf 5V hänge? (meine mit SDA - das mit der FRAM dann den LPC zerschiesst mit den 5V dann) [edit] Ich hätte ja den FM24CL16 benötigt und nicht den FM24C16 Die Frage ist nun eben ob das der Grund ist, und wenn ja (was ich vermute) ob ich mal zum testen das umhängen kann, bevor ich dann für die neuen einen CL bestelle
Andi S. schrieb: > nun die 3.3 V Leitung kappe und auf 5V hänge? Der RAM hat V_IN_High 0,7xVdd, also 0,7*5V=3,5V Wird also nicht klappen.
Die IO Pins am LPC können max. 5V ab, sollte also gehen wenn das FRAM mit 5V versorgt wird.
ich warte mal die zwei tage bis der FM24CL16 da ist, hatte zwar kurz überlegt mit ner Diode den FM24C16 mit 4.5 V sowas zu versorgen, dann müsste der innerhalb der spezifikation liegen ... aber wenns dann trotzdem nicht funktioniert, dann kann ich wider nicht sicher sagen, obs nicht doch an dem liegt.
Andi S. schrieb: > mit ner Diode den FM24C16 mit 4.5 V sowas zu versorgen, dann > müsste der innerhalb der spezifikation liegen Ist mir auch noch eingefallen. Du kannst ja mal prüfen ob dann das ACK am Bus kommt.
So nun gehts mal weiter .... dank der schnellen lieferung (gestern bestellt heute geliefert) habe ich ein ACK zurückbekomme! jetzt kann ich dann weitertesten Also lag es am FRAM .. falls jemand 2 ausgelötet und 8 nagelneue brauchen kann ... dann melden :D
So bischen was bekomme ich schon zum lesen, nur glaube ich das das Protokoll bei dem hier "ganz" anders ist da werden nicht 2 Bytes für die Adresse verwendet sondern nur ein Byte und 3 Bits werden von der Slave Adresse verwendet also der horcht auf 7 unterschiedlichen Slave Adresse je nach Page
Andi S. schrieb: > da werden nicht 2 Bytes für die Adresse verwendet sondern nur ein Byte > und 3 Bits werden von der Slave Adresse verwendet also der horcht auf 7 > unterschiedlichen Slave Adresse je nach Page Aber genau so ist es doch im Datenblatt beschrieben - sowohl bei artverwandten EEPROM als auch bei diesem FRAM. Woher hast du die Info mit den 2 Bytes?
die funktion von oben macht das meiner Meinung nach oder????
1 | #define MC24LC64_ADDR 0xa0 // I2C address of the 24LC64 EEPROM |
2 | |
3 | int i2c_wr_eeprom(uint32_t Addr, const void *pIn, uint32_t len) |
4 | {
|
5 | uint32_t l; |
6 | if (!pIn || len>0x0ffff) |
7 | return -1; |
8 | |
9 | while (len>0) |
10 | {
|
11 | if ( I2CInit( (uint32_t)I2CMASTER ) == 0 ) // initialize I2c |
12 | return 1; // Fatal error |
13 | l=(len>32) ? 32 : len; |
14 | memcpy((void*)I2CMasterBuffer+3, pIn, l); |
15 | I2CWriteLength = l+3 ; |
16 | I2CReadLength = 0; |
17 | I2CMasterBuffer[0] = MC24LC64_ADDR; |
18 | I2CMasterBuffer[1] = (Addr & 0xff00)>>8; // address MSB |
19 | I2CMasterBuffer[2] = (Addr & 0xFF); // address LSB |
20 | //uint32_t fin_state = I2CEngine(); |
21 | I2CEngine(); |
22 | Addr+=l; |
23 | pIn+=l; |
24 | len-=l; |
25 | } |
26 | return 0; |
27 | } |
28 | |
29 | int i2c_rd_eeprom(uint32_t Addr, void *pOut, uint32_t len) |
30 | {
|
31 | uint32_t i,l; |
32 | if (!pOut || len>0xffff) |
33 | return -1; |
34 | |
35 | while (len>0) |
36 | {
|
37 | if ( I2CInit( (uint32_t)I2CMASTER ) == 0 ) // initialize I2c |
38 | return 1; // Fatal error |
39 | |
40 | //for ( i = 0; i < Slave_Buffer_BUFSIZE; i++ ) |
41 | // I2CSlaveBuffer[i] = 0x00; |
42 | |
43 | l=(len>32) ? 32 : len; |
44 | // Write SLA(W), address, SLA(R), and read 4 bytes back. */ |
45 | I2CWriteLength = 3; |
46 | I2CReadLength = l; |
47 | I2CMasterBuffer[0] = MC24LC64_ADDR; |
48 | I2CMasterBuffer[1] = (Addr & 0xff00)>>8; // address MSB |
49 | I2CMasterBuffer[2] = (Addr & 0xFF); // address LSB |
50 | I2CMasterBuffer[3] = MC24LC64_ADDR | RD_BIT; |
51 | |
52 | i=0; |
53 | while (I2CEngine() == I2CSTATE_SLA_NACK) |
54 | i++; |
55 | memcpy(pOut, (void*)I2CSlaveBuffer, l); |
56 | len-=l; |
57 | pOut+=l; |
58 | Addr+=l; |
59 | } |
60 | return 0; |
61 | } |
und auch die größeren Typen der 24c64 zB. der verwendet auch eine WordAddress aber egal bei mir funkt das umgebaute jetzt eh
Andi S. schrieb: > die funktion von oben macht das meiner Meinung nach oder???? Ja, aber ein xx24xx64 ist etwas anderes als ein xx24xx64. Der 64er hat das zusätzliche Adressbyte, der 16er nicht. Siehe Datenblätter.
täglich grüßt der LPC ;) Habe schon wieder eine Frage, kann es sein, das die I2C im CAN nicht funktionieren? Also ich sende meinem LPC eine CAN Nachricht (die kommt an) aber die I2C Operation bleibt hängen, da wartet er irgendwo endlos auf irgendein Signal. Am Logik Analyser sehe ich keinen Takt oder sonst was er startet einfach nicht. Die gleiche I2C Operation im main beim starten funktioniert aber (laut dem was ausgegeben wird und Logik Analyser) nur eben callback vom CAN dem CAN_RX nicht. Muss ich das ganze umbauen, das alle I2C dann im main gemacht werden, oder habe ich da noch wo was falsch eingestellt?
Die CAN Callback-Funktionen werden direkt aus dem CAN-Interrupt gerufen. Damit wird dann dein I2C-Code nicht funktionieren, der ebenfalls Interrupts benutzt. Jedenfalls nicht ohne die Prioritäten anzupassen. Allerdings ist diese Art zu Programmieren ziemlich bescheuert. Im CAN Interrupt sichert man die Messages, setzt ein paar Flags u.s.w. Alles andere dann im Hauptprogramm.
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.