Guten Abend zusammen, ich bin neu hier und habe direkt ein sehr großes Problem. Ich will einen Drehzahlmesser für ein Motorrad bauen und diesen nun programmieren. Meines Erachtens nach müsste es mit diesem Code funktionieren, allerdings tut sich nichts und nun bin ich mit meinem Latein am Ende. Verwendet habe ich einen ATMega328 auf dem Mainboard und einen ATtiny26 auf dem LED_Board. Die Messung der Drehzahl soll über das Zündsignal erfolgen. Dafür habe ich mir einen Interrupt genommen, der durch dieses Zündsignal ausgelöst wird. (steigende Flanke) Anschließend soll mit diesem Interrupt der Timerwert eines 16 Bit Timers ausgelesen werden und der Timerwert auf 0 gesetzt werden. Darüber hinaus habe ich nun über switch case eine Zuordnung der Anzahl an leuchtenden LEDs vorgenommen. Diese Anzahl möchte ich nun über einen I2C_Bus an das LEDBoard weiterleiten. Dort soll dieser Wert über ein Schieberegister ausgegeben werden. Leider funktioniert dieses Vorhaben momentan nicht. Es wäre also super, wenn sich jemand den Code anschauen könnte und mir sagen kann woran es scheitert. Ich habe einmal beide Codes angehängt, sollte noch etwas fehlen bitte einfach schreien. ;D PS: der Interrupt wird über den PIN PD3 geschalten. PSS: ich habe das erste Mal in C programmiert, also falls lustige Fehler drin sind, bitte verzeiht mir dies. Vielen Dank schon einmal im Voraus.
:
Bearbeitet durch User
Normaler Weise schreibt man erstmal ein hello world Programm und erweitert es dann mit Zwischentests solange bis man hat was man will. Du schreinst einfach mal drauf los programmiert zu haben, hast nun eine gewisse Menge Code die beim ersten Ausführen nix tut. Um ehrlich zu sein wundert mich, dass das überhaupt kompilieren soll.
Du definierst die Funktion init timer 1 in der Main Funktion. Du kannst keine Funktion in einer Funktion definieren. Und was ist x in deiner ISR? Wo wird x deklariert?
Vielen Dank für die schnelle Rückmeldung. Zu deiner ersten Antwort, ich habe begonnen mit der Programmierung des LEDBoards und habe hinbekommen, dass ich die Anzahl auch an die LEDs ausgeben kann. Somit kann ich zu 99% sagen, dass das Schieberegister funktioniert. Da ich allerdings auf dem Mainboard keine Möglichkeit habe etwas zu testen und auszugeben, konnte ich dort leider nur darauf losprogrammieren. Das init timer habe ich nach deiner Aussage auch verstanden und habe mich selbst gefragt warum ich das so gemacht habe. (Weis ich eigentlich, dass das nicht geht) Und die Variable x ist nur der Übergabewert für den switch case in der TWI.h, wo dieser auch als uint16_t definiert wurde.
Also x wird in der Mainboard_TWI.h deklariert. Aber die bindest du ja in deiner Mainboard_main.c überhaupt nicht ein? Bei mir kompiliert das nicht..
Tobias B. schrieb: > ich mit meinem Latein am Ende ... ich denke, du kannst nicht programmieren und auch kein Latein. der code ist copy paste und du talentfrei! was soll das ohne break, äh?! switch (x) { case 0 ... 1579: anzahl = 52; case 1580 ... 1611: anzahl = 51; ... wer so wie du hier - mit viel rumlabern und wenig ahnung ein projekt angeht, will nur, dass die arbeit ein anderer macht. ich hoffe, du fährst nicht auf einer öffentlichen strasse motorrad. wenn doch, wirst du sicher nicht alt bei dem niveau. mt
Tobias B. schrieb: > Da ich allerdings auf dem Mainboard keine Möglichkeit habe > etwas zu testen und auszugeben, konnte ich dort leider nur darauf > losprogrammieren. Die Möglichkeit hättest du schaffen sollen. Das Mindeste wäre eine serielle Schnittstelle zur Ausgabe von Debug Meldungen. Dazu ist nur ein I/O Pin nötig. Notfalls kann man das Protokoll per Soft-Serial umsetzen. Du hast vergessen, das Problem zu beschrieben. "Funktioniert nicht", genügt nicht, damit kann man gar nichts anfangen. Reduziere dein Programm schrittweise auf weniger, um den Fehler einzukreisen. Am Ende sollten maximal 30 Zeilen Code übrige bleiben, in denen der Fehler noch auftritt. Mit Hilfe eines Debuggers oder einer seriellen Leitung soll das Programm die Werte der relevanten Variablen ausgeben. Dazu schreibst du eine Doku, die für jede einzelne Zeile Code erklärt, wozu sie gedacht ist und warum da genau die Zahlen bzw. Bits verwendet wurden, die man da sieht. Und natürlich brauchen wir auch den Schaltplan! Das können wir uns dann anschauen - falls du darin den Fehler nicht selbst erkennst. Bist du denn 100% sicher, dass der Fehler im Code liegt? Hast du die Hardware überprüft? Wenn ja, wie? Ich frage deswegen, weil hier regelmäßig Leute melden, dass ihre Basteleien auf den Tisch noch funktionierten, aber am Fahrzeug nicht mehr.
Peter Petersson schrieb: > Also x wird in der Mainboard_TWI.h deklariert. Aber die bindest du ja in > deiner Mainboard_main.c überhaupt nicht ein? Bei mir kompiliert das > nicht.. Entschuldigung habe die Dateien immer noch mit dem Namen_ ergänzt bevor ich es hochgeladen habe, damit ihr das zuordnen könnt. Deswegen müsste man das da noch mit #include "Mainboard_TWI.h" inkludieren. Dann wäre es das selbe wie bei mir. Hab ich aber vergessen zu erwähnen mein Fehler.
:
Bearbeitet durch User
Apollo M. schrieb: > ... ich denke, du kannst nicht programmieren und auch kein Latein. Völlig richtig kann ich beides nicht... ich verstehe nur das Problem daran nicht ;P Und natürlich habe ich mich an anderen Codes bedient und diese dann dementsprechend an meinen Code angepasst. Wüsste auch nicht wie man das sonst mit meinem Wissen hinbekommen soll. Aber danke für die hilfreichen Informationen woran es liegt. Apollo M. schrieb: > ich hoffe, du fährst nicht auf einer öffentlichen strasse motorrad. > wenn doch, wirst du sicher nicht alt bei dem niveau. Und was meine Programmierkünste mit meinem Können beim Motorrad fahren zu tun haben sollen versteh ich auch nicht so ganz, dass müsstest mir noch einmal erklären.
Stefanus F. schrieb: > Die Möglichkeit hättest du schaffen sollen. Das Mindeste wäre eine > serielle Schnittstelle zur Ausgabe von Debug Meldungen. Dazu ist nur ein > I/O Pin nötig. Notfalls kann man das Protokoll per Soft-Serial umsetzen. Den Fehler habe ich schon erkannt. Im Nachhinein ist man leider immer schlauer. Nur leider kann ich es jetzt nicht mehr kurz ändern. Stefanus F. schrieb: > Du hast vergessen, das Problem zu beschrieben. "Funktioniert nicht", > genügt nicht, damit kann man gar nichts anfangen. Reduziere dein > Programm schrittweise auf weniger, um den Fehler einzukreisen. Am Ende > sollten maximal 30 Zeilen Code übrige bleiben, in denen der Fehler noch > auftritt. Mit Hilfe eines Debuggers oder einer seriellen Leitung soll > das Programm die Werte der relevanten Variablen ausgeben. Ok das genaue Problem liegt darin, dass wenn ich beides am Motorrad anschließe, nichts leuchtet und gemessen wird. Da ich ja bereits die (void) init_timer1 (void) in der int main hatte konnte es auch nicht funktionieren. Somit habe ich versucht mir nur über den I2C-Bus einen einfachen Wert zu transferieren. Dies habe ich gemacht indem ich in der Funktion void TWI_MT_DATA_ACK(void) anstatt der Variablen anzahl eine 14 hingeschrieben habe. Also sollten bei funktionierender Übertragung 14 LEDs leuchten. Es leuchten also immer noch keine, was mir den Schluss nahe legt, dass mit dem I2C etwas nicht funktioniert. Denke das ist momentan auch der Hauptpunkt warum nichts tut (das der I2C ohne Funktion ist). Stefanus F. schrieb: > Bist du denn 100% sicher, dass der Fehler im Code liegt? Hast du die > Hardware überprüft? Wenn ja, wie? Ich frage deswegen, weil hier > regelmäßig Leute melden, dass ihre Basteleien auf den Tisch noch > funktionierten, aber am Fahrzeug nicht mehr. Von der Hardware bin ich mir absolut sicher das diese funktioniert. Und wie gesagt die Ausgabe über die Schieberegister funktioniert bereits komplett. Also muss dies auch hardwaretechnisch funktionieren. Alle anderen Schaltungen sind ebenfalls durchsimuliert und müssten in der Theorie funktionieren. Davon habe ich allerdings einiges an Verständnis und habe auch mit zwei Kumpels darüber geschaut die jeden Tag mit so etwas zu tuen haben. Nur bei der Programmierung kann mir niemand helfen. Vielleicht reicht das einmal zu Beginn.
Tobias B. schrieb: > Wüsste auch nicht wie man das > sonst mit meinem Wissen hinbekommen soll ... wenn man nichts weiss, dann sollte es doch wenigstens dazu reichen zu kapieren klein anzufangen entsprechend stefan's ansage, aber neh man will ja gross hinaus als ahnungsloser. als "bergbegeher" würde dich kein bergsteiger mitnehmen und allein überlebst du die erste tour nicht. das die signalankopplung im kfz-umfeld auch nicht wie im bilderbuch abläuft wird auch noch viel leid und silicon kosten. mt
Apollo M. schrieb: > ... wenn man nichts weiss, dann sollte es doch wenigstens dazu reichen > zu kapieren klein anzufangen entsprechend stefan's ansage, aber neh man > will ja gross hinaus als ahnungsloser. > als "bergbegeher" würde dich kein bergsteiger mitnehmen und allein > überlebst du die erste tour nicht. > > das die signalankopplung im kfz-umfeld auch nicht wie im bilderbuch > abläuft wird auch noch viel leid und silicon kosten. Noch einmal vielen Dank für den Kommentar. Über das KFZ-Thema brauchst dir überhaupt keine Sorgen machen. In dem Thema und was alles darum herum anbelangt bin ich absolut fit und bekomme das auf jeden Fall hin. Es scheitert lediglich an der Programmierung. Also entweder du kannst mir dort weiterhelfen oder ich verstehe nicht wieso du deine Zeit verschwendest und Kommentare schreibst die eh keinen Inhalt haben. MFG und einen schönen Tag noch ;D
:
Bearbeitet durch User
So etwas
1 | ( 0 << USICS0 ) |
oder gar
1 | ( 0x0 << USICNT0) |
"verodert" ist sinnlos. Ich denke auch, Du solltest eine Nummer kleiner anfangen und Dich ein wenig mit den Grundlagen beschäftigen. Alternativ kannst Du Dir das natürlich auch von einem selbstlosen Helfer (oder gegen Bezahlung - hier im Forum machen einige so etwas) korrigieren / fertigen lassen.
Tobias B. schrieb: > Und was meine Programmierkünste mit meinem Können beim Motorrad fahren > zu tun haben sollen versteh ich auch nicht so ganz, dass müsstest mir > noch einmal erklären. das thema ist selbsteinschätzung/überschätzung und fremdeinschätzung UND vorausschauen/-denken, oder was glaubst du warum jedes wochenende mindestens ein toter biker irgendwo rumliegt?! es nutzt wenig, wenn eigentlich die links abbiegende oma/opa/hühnchen schuld sind , weil tot bleibt tot. also, du überholst gerade mit deiner tollen/uns unbekannten drehzahl hw, die aber jetzt gerade leider abraucht und auch noch die zündung mit in den abgrund reißt ... leider kommt von vorne auch ein auto/trekker und dein überholvorgang bricht unvorbereitet ab ... kannst du dir dein problem dann vorstellen? mt
:
Bearbeitet durch User
Ich fürchte auch du hast dir einfach zu viel vorgenommen für den Anfang. Bei so einem Projekt reicht es nicht mit 0 Ahnung von der Sprache sich einfach Codeschnipsel zusammen zu kopieren und fertig. Klar kann man sich fertige Sachen von anderen nehmen aber eben nur wenn man trotzdem weiß was man da tut. Wenn man dann Code zur Fehlersuche hier hochlädt sollte es exakt der sein den man auch benutzt. Das was du hier abgeliefert hast kompiliert nicht mal. Wie soll man dir da helfen? Ich würde sagen, lerne erstmal c und beschäftige dich mit 2-3 kleinen AVR Projekten. Dann versuchst du mal eine funktionierende i2c Verbindung herzustellen. Und das alles indem du selbst den Code schreibst. Es ist essentiell dass du verstehst was warum in deinem Code steht. Wenn du das machst und dabei auf Probleme stößt wie z. B. 'meine Switch Anweisung verhält sich nicht wie sie soll' dann wird die hier im Forum auch schnell und gerne geholfen. Wenn du aber jemals eine Switch selbst programmiert hättest wüsstest du auch, dass da einfach ein paar breaks fehlen. Und wie schon gesagt Schaltpläne sind immer gut. Ich dachte auch schon oft ich kann hier was weglassen, da liegt der Fehler bestimmt nicht. Aber genau da lag dann oft der Fehler. Wenn du das alles erfolgreich getan hast, dann setz dich mit mehr Know How nochmal an deinen Drehzahlmesser.
Tobias B. schrieb: > Über das KFZ-Thema brauchst > dir überhaupt keine Sorgen machen. In dem Thema und was alles darum > herum anbelangt bin ich absolut fit und bekomme das auf jeden Fall hin. glaube ich erst, wenn ich deine sinnige hw sehe und absolut fit bedeutet eher du bist supermann. aber der kann auch fliegen ... dann lade doch mal die schaltung hoch zum fitness test!
Apollo M. schrieb: > das die signalankopplung im kfz-umfeld auch nicht wie im bilderbuch > abläuft wird auch noch viel leid und silicon kosten. ... wenn man es überhaupt hinbekommt. Das Umfeld in Fahrzeugen (egal ob Motorrad oder KFZ) ist so derart übel von Störungen verseucht, was eine besondere Herausforderung an die Spannungsversorgung darstellt. Hier will er jetzt nur mit digitalen Impulsen (Zündung) etwas anfangen, wären noch analoge Dinge im Spiel wäre es noch eins besser. Allein die Anzahl fehlausgelöster Interrupts wird hier für graue Haare sorgen bis etwas überhaupt mal funktioniert (wenn es an der Bordspannung des Fahrzeugs hängt). Dann, als Anfänger, einen I2C Slave auf einem Tiny in Betrieb zu nehmen ist nicht so wirklich einfach. Vielleicht wäre es eine super Idee, sich eine eigene (okay, sehr viel langsamere) proprietäre Lösung auszudenken, mit der man Daten übertragen könnte (der Lerneffekt bei so etwas ist enorm). Für deine Anwendung könnte man auch einen Datentransfer zum Tiny mittels Software UART machen (und da das LED-Board nichts zurück liefert würde sogar eine einzige Singalleitung anstelle von zweien wie beim I2C reichen). An den TO jetzt, auch wenn es mühselig ist: Lerne vom Code anderer Leute (auch von dem was du da zusammenkopiert hast), aber schreibe dein eigenes Ding (also deinen eigenen Code). Die Erfahrung hat mir gezeigt, dass der meiste Fremdcode den ich einsetze (oder einsetzen wollte) einer satten Überarbeitung bedurfte und in den meisten Fällen (nicht immer) es schneller gewesen wäre, ich hätte es selbst geschrieben. Mach dir erst einmal Gedanken wie alles funktionieren könnte. Implementiere auf dem Tiny eine Software die etwas anzeigt und auf deren Anzeige du etwas vom anderen Board senden kannst. Dann kannst du an das "Mainboard" gehen. Glaub mir: TWI-Slave auf dem Tiny... das willst du nicht wirklich machen ! Du wirst noch ganz andere Probleme mit Interrupts auf dem "Mainboard" und Fehlauslösungen bekommen. Teste das ganze außerhalb des Einsatzortes. An das Motorrad brauchst du eine ganze Weile nicht zu denken. Die linke Hand zum Gruße, Ralph PS: Für welche Maschine möchtest du etwas basteln ? (Immer schön dran denken 1 Zündimpuls sind 2 Umdrehungen per Zylinder => 4 Zylindermaschine und 4 Impulse = 2 Umdrehungen)
Tobias B. schrieb: > Somit habe ich versucht mir nur über den I2C-Bus einen einfachen Wert zu > transferieren. Das bringt mich auf eine Idee: Du könntest Debug Meldungen auf dem I²C Bus ausgeben. Müsstest dabei allerdings das fehlende ACK ignorieren. Mit einem billigen Logic Analysator kannst du die Meldungen empfangen und mit dem Programm dazu (Salae Logic oder PulseView) anzeigen. > Denke das ist momentan auch der Hauptpunkt warum nichts > tut (das der I2C ohne Funktion ist). Das würdest du dann bei der Gelegenheit gleich mit klären.
Ok das mit dem "noch nie in C programmiert" war eventuell ein wenig zu hoch angesetzt. Ich hatte bereits Mikrocontrollerprogrammierung in der Uni. Allerdings haben wir dort mit einem ARM Controller programmiert und da ist die Syntax doch ein wenig anders. Hierbei haben wir auch angefangen mit "Hello World" Programmen etc. Auch habe ich schon eine I2C Schnittstelle für diesen Controller programmiert und das hat auch funktioniert. Allerdings musste ich feststellen, dass eine I2C Schnittstelle zwischen einem ATmega328 und ATtiny26 doch deutlich komplizierter ist als angenommen. Das mit der Funktionsdeklarierung in der int main hab ich auch sofort verstanden warum das falsch ist, ebenso das ein Break nach jedem Case fehlt (habe ich einfach vergessen). Auch verstehe ich was ich in dem gesamten restlichen Code mache. Lediglich wie die Kommunikation über einen I2C funktioniert (in dieser Baureihe) habe ich noch nicht exakt verstanden (von der Syntax her). Die allgemeine Funktionsweise eine I2C weis ich wie sie abläuft. Da der ATtiny allerdings keine I2C Schnittstelle hat sondern nur eine USI Schnittstelle war ich an diesem Punkt raus und habe mir ein Beispielprojekt dafür zur Hand genommen. Den Rest habe ich bereits selber programmiert. Vielleicht kann mir da dann einer sagen, wie ich an die Programmierung der I2C Schnittstelle zwischen den beiden Controllern herangehen muss bzw. eventuell warum die Kommunikation nicht funktioniert. Habe mir einen Code für den ATtiny als Slave aus dem Internet genommen und daraus die Funktionen gezogen, welche ich meiner Meinung nach für die Kommunikation benötige. Anschließend habe ich die Adressen abgeglichen und das ganze kompiliert. Vlt macht das meine Vorgehensweise ein wenig klarer.
Apollo M. schrieb: > kannst du dir dein problem dann vorstellen? Deinen Beitrag finde ich ziemlich absurd. So einen Tacho darf man ohnehin nur als Zusatzgerät einbauen. Selbst wenn es das Hauptgerät ist, brauche ich keinen Tacho um zu merken, ob ich angemessen schnell/langsam fahre.
>> Dazu ist nur ein I/O Pin nötig. >> Notfalls kann man das Protokoll per Soft-Serial umsetzen. > Den Fehler habe ich schon erkannt. Im Nachhinein ist man leider immer > schlauer. Nur leider kann ich es jetzt nicht mehr kurz ändern. Also wenn ich mir deine MainBoard_main.c anschaue, sind da mit Sicherheit noch viele I/O Pins frei. Es kann nicht so schwer sein, einen einzelnen Draht notfalls direkt an den Chip zu löten.
Tobias B. schrieb: > Ich hatte bereits Mikrocontrollerprogrammierung in der > Uni. Auch boolesche Algebra? Tobias B. schrieb: > Auch verstehe ich was ich in dem gesamten restlichen Code mache. Da bezweifle ich etwas. Tobias B. schrieb: > Habe mir einen Code für den ATtiny als Slave aus dem Internet genommen > und daraus die Funktionen gezogen Das glaube ich Dir :-)
Tobias B. schrieb: > Das mit der Funktionsdeklarierung in der int main hab ich > auch sofort verstanden warum das falsch ist, ebenso das ein Break nach > jedem Case fehlt (habe ich einfach vergessen). Und warum hast du diese Fehler dann nicht selbst entdeckt?
Hannes J. schrieb: > Und warum hast du diese Fehler dann nicht selbst entdeckt? Dieter F. schrieb: > C&p ? Da ich der Meinung war bzw. bin, dass das Hauptproblem der I2C-Bus ist. Und ich versucht habe dort einen Fehler zu finden. Den Rest habe ich nur kurz überflogen und dabei leider nicht festgestellt das dort auch noch Fehler vorhanden sind. Dieter F. schrieb: > Auch boolesche Algebra? Ja klar auch das hatte ich komplett. Dieter F. schrieb: > "verodert" ist sinnlos. Falls du mit der Booleschen Algebra drauf hinaus möchtest verstehe ich sehr wohl das ich hier veroder, allerdings ist mir nicht bewusst warum das an der Stelle sinnlos sein soll.
@Tobias Vorsicht, dieser Quakfrosch ist der diensthabende Provokateur. Geh nicht auf ihn ein, sonst ist das Gemetzel hier perfekt.
Tobias B. schrieb: > allerdings ist mir nicht bewusst warum > das an der Stelle sinnlos sein soll. 1 oder 0 ist immer 1 - damit kannst Du kein Bit "löschen" Ratgeber schrieb: > @Tobias > Vorsicht, dieser Quakfrosch ist der diensthabende Provokateur. Geh nicht > auf ihn ein, sonst ist das Gemetzel hier perfekt. Ein schlechter "Ratgeber"
Also ich versuche Fehler immer erstmal selbst zu finden und wenigstens einzugrenzen, bevor ich im Forum nach Hilfe frage. Und dann poste ich auch die Quelldateien die ich tatsächlich verwendet habe. Jedenfalls legen deine Quellen nahe dass du nicht die geringste Ahnung davon hast, was du machst. Also tu dir selbst einen Gefallen und nimm dir was kleineres vor. Schau dir nochmal Grundlagen von C an. Schau dir nochmal bool'sche Algebra an. Und versuche es mal mit systematischer Fehlersuche bevor du uns hier irgendwelche Quelltexte vorlegst in denen man in jeder 2. Zeile auf den ersten Blick einen Fehler entdeckt und die so vom Compiler nie und nimmer verarbeitet worden sein können. Ist ja logisch dass dein Programm nix tut wenn es vom Compiler gar nicht erst übersetzt werden konnte. Denk doch mal mit..
Tobias B. schrieb: > Stefanus F. schrieb: >> Die Möglichkeit hättest du schaffen sollen. Das Mindeste wäre eine >> serielle Schnittstelle zur Ausgabe von Debug Meldungen. Dazu ist nur ein >> I/O Pin nötig. Notfalls kann man das Protokoll per Soft-Serial umsetzen. > > Den Fehler habe ich schon erkannt. Im Nachhinein ist man leider immer > schlauer. Nur leider kann ich es jetzt nicht mehr kurz ändern. Wieso nicht? Egal wieviel Zeit Du für diese Änderung brauchst, es wird nur kurz dauern im Vergleich zu der Ewigkeit, die Dein Projekt zwangsläufig dauern wird, ohne eine Möglichkeit solche Debug Ausgabemöglichkeit einzubauen. Tobias B. schrieb: > Alle anderen Schaltungen sind ebenfalls durchsimuliert und müssten in der > Theorie funktionieren. Davon habe ich allerdings einiges an Verständnis … Offenbar reicht Dein Verständnis bzgl. der Hardware aber nicht aus zu erkennen, daß eine erfolgreiche Simulation der Schaltungen für das tatsächliche Funktionieren bestenfalls eine notwendige, aber niemals eine hinreichende Bedingung ist?
Übrigens hat Programm-Code nichts in einer .h Datei verloren. Da kommen nur Deklarationen rein.
Interessant wäre auch die Frage, warum du ein Register mal mit 0x00 und mal mit 0 beschreibst. Könntest du kurz den Unterschied erklären? Und warum überhaupt? Hast du die mal die Standardwerte des Registers angeschaut?
Tobias B. schrieb: > Ich hatte bereits Mikrocontrollerprogrammierung in der > Uni ... lass mich raten, die uni war früher eine fh und hält das niveau tapfer weiter schön niedrig, damit die absolventenstatistik gut aussieht. in elektrotechnik oder formale logik waren die fensterplätze immer begehrt und du hast auch gekämpft wie ein löwe um einen zu erhaschen. weil das rumgesülze hier tut weh, aber ich bin ja auch eine mimose und nicht abgehärtet genug. wenn das hier ein praktikum wäre, dann hättest du schon einen platzverweis für dieses ping-pong spiel - sprich frage-antwort spiel verdient. das es hier so viele gutmenschen gibt wird mal wieder ausgenutzt. auch deine hw hältst du natürlich weiterhin geheim, weil die wird sicher auch auf einen ähnlichen soliden niveau sein. mt
Apollo M. schrieb: > ... lass mich raten, die uni war früher eine fh und hält das niveau > tapfer weiter schön niedrig, damit die absolventenstatistik gut > aussieht. Wovon träumst Du eigentlich nachts? (Außer das Du Groß- / Kleinschreibung nicht beherrscht :-) )
0 ist eine Oktalzahl. 0x00 ist hexadezimal. Wie schreibt man denn die 0 in dezimal? :-)
Dieter F. schrieb: > Wovon träumst Du eigentlich nachts? die haarfarbe ist egal, nur gut riechen muss sie. nachts ist halt kälter als durch'n wald!
... warum eigentlich möchtest du mit einem ATtiny26 einen I2C-Slave aufsetzen, der dann seinerseits ein Schieberegister bedient für eine LED-Anzeige? Warum wird ein Schieberegister nicht direkt an den "Hauptcontroller" angeschlossen? Geht es um eine Kabelstrecke die überbrückt werden muss? Wenn ja, warum nimmst du dir hierfür nicht einen PCF8574 I2C-Expander (hier mußt du dann auch keinen I2C-Slave aufsetzen). Wenn du mit ARM Controller gelernt hast, warum verwendest du dann nicht einen solchigen (hier gibt es auch satte Unterschiede, LPC unterscheidet sich von STM32 satt ... und selbst innerhalb der STM32-Familie gibts Unterschiede). Ich denke, du hast unter ARM einfach ein fertige Bibliothek und/oder einen Hardware-Abstraction-Layer verwendet der nun so auf der AVR Schiene nicht vorhanden ist (und es für einen ATtiny gar nicht geben kann). Soll es also unbedingt eine I2C Kommunikation sein und du ARM "kannst" (was ich nicht so wirklich glauben kann), warum hast du dann nicht bspw. einen STM32F030 als einen I2C-Empfänger gewählt (und die Ausgabe direkt an diesen Controller gehängt anstelle dass du noch einmal ein Schieberegister ansprechen möchtest? Hier wäre der Punkt, dein komplettes Konzept noch einmal zu überdenken. Wenn du das nicht machen möchtest, setze auf dem ATmega328 ein I2C-Master auf, sende ein Bitmuster darüber an den ATtiny und lass diesen anzeigen bevor du irgendetwas anderes machst.
Hallo, hast du bereits versucht, das Gerät aus- und wieder anzuschalten? Gruß Roland
Hallo Tobias, ich frage mich, wozu der Aufwand? 2 µC für einen Drehzahlmesser. Nach meiner Meinung wäre es einfacher, den 328 die Auswertung und die Anzeige machen zu lassen. Die Primärspannung der Zündspule kann man gut auf einen Widerstand legen und von dort weiter hoch zur Anzeige führen. 12V sind eh oben. Der Widerstand verhindert, dass das Motorrad stehen bleibt, wenn ein Kabel durchscheuert. Wie sieht es aus mit der Ablesbarkeit der LED-Anzeige, auch bei Sonnenlicht? Man will ja nicht nur im Regen fahren ;-). Ach ja, eines meiner Motorräder hat auch noch keinen Drehzahlmesser. Wenn alles funktioniert, hätte ich Interesse an deiner Lösung. Um was für ein Motorrad geht es bei dir?
Wolfgang H. schrieb: > Ach ja, eines meiner Motorräder hat auch noch keinen Drehzahlmesser. > Wenn alles funktioniert, hätte ich Interesse an deiner Lösung. > Um was für ein Motorrad geht es bei dir? Es soll eine modulare Bauweise werden. Das bedeutet, dass das Mainboard nur zur Datenverarbeitung fungieren soll und daran die Ausgabemodule angeschlossen werden. Das hat den Vorteil, dass später noch weitere Sensoren ergänzt werden können. Und bei dem Motorrad handelt es sich um eine KTM LC4 640.
Tobias B. schrieb: > Es soll eine modulare Bauweise werden. Das bedeutet, dass das Mainboard > nur zur Datenverarbeitung fungieren soll und daran die Ausgabemodule > angeschlossen werden. Das hat den Vorteil, dass später noch weitere > Sensoren ergänzt werden können. Wenn du das modular haben möchtest und weitere Dinge (wie bspw. Sensoren) anschließen möchtest würde ich hier aber eher einen Controller mit CAN verwenden wollen. Prinzipiell solltest du aber (egal welchen Bus du verwendest) sattelfest im Umgang mit Kommunikation zwischen den Bausteinen sein (egal welchen Controller du wählst). Tobias B. schrieb: > Und bei dem Motorrad handelt es sich um eine KTM LC4 640. Schönes Teil
Bitte 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.