Hallo zusammen und schonmal danke das es euch gibt :) Falls es einen ähnlichen Beitrag gibt habe ich ihn entweder nicht gefunden oder nicht verstanden. Falls ihr ein gutes und verständliches Buch kennt das bei mir ein Licht aufgehen lässt wäre ich auch sehr dankbar :) Nun zu meiner Frage es geht generell um Busse bzw Daten Ausgabe in serieller Form. Als Beispiel ws2812 leds. Hierbei kann ich manuell viele high und lows eines Pins mit warte befehlen aneinander reihen. Das gleiche scheema lässt sich (korrigiert mich wenn ich falsch liege) ja auch auf SPI, I2C, RS232, UART usw. Übertragen solange die timings passen. Das manuelle senden von Daten erscheint mir auf den ersten Blick also "relativ simpel". Aber wie ist das nun mit dem empfangen? Spontan würde mir lediglich einfallen die Zeitabstände zwischen bitänderungen zu messen und das ganze dann mit 1000enden if Verknüpfungen zu entfriemeln aber mir scheint das kann nur falsch sein... ein wenig möglichst einfacher Beispiel code und eine Erklärung wie man das alles puffert und wirklich daten gewinnt wäre toll :) habe dazu leider auch kein Buch finden können :/ Konkret würde ich im Moment einen pic18 bedienen wollen falls das relevant ist aber eigentlich gehts ums generelle. Ich würde nur irgendwas seltsames machen und da frag ich lieber gleich :) Neben der verständnis und lern sache möchte ich als Ziel mit einem PIC18f einen BMP280 oder 390 via spi steuern, das Ergebnis als rs485 versenden und am PC in einem JAVA Programm weiterverarbeiten. Vielen lieben Dank vorab fürnjede hilfe und Empfehlung :) Pic sprache wäre vorzugsweise c Programm am ende java wobei man ja nahezu jede methode auch inbhöheren sprachen umsetzen kann es geht wirklich um die basis (noch) Grüße
Richard S. schrieb: > Das manuelle senden von Daten erscheint mir auf den ersten Blick also > "relativ simpel". Du hast aber den simplen Aspekt des korrekten Timings und bestimmter zeitlicher Abhängigkeiten völlig übersehen. Und weil das Timing zumindest bei asynchronen Bussen meist etwas tricky ist, gibt es auf den uC spezielle Hardware dafür. Auch da solltest du dich für deinen uC ein wenig einarbeiten. > es geht wirklich um die basis (noch) Jojo, so sehe ich das auch.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Richard S. schrieb: >> Das manuelle senden von Daten erscheint mir auf den ersten Blick also >> "relativ simpel". > Du hast aber den simplen Aspekt des korrekten Timings und bestimmter > zeitlicher Abhängigkeiten völlig übersehen. > > Und weil das Timing zumindest bei asynchronen Bussen meist etwas tricky > ist, gibt es auf den uC spezielle Hardware dafür. Auch da solltest du > dich für deinen uC ein wenig einarbeiten. > > >> es geht wirklich um die basis (noch) > Jojo, so sehe ich das auch. Naja das mit dem einarbeiten versuche ich ja gerade. Deshalb ja auch die Frage nach einem Buch etc. Ich möchte es erstmal verstehen und wissen was man beachten muss. Auch wenn ich die MSSP Schnittstelle nutze muss ich ja trotzdem wissen wie ich die Daten entgegen nehme etc. Leider finde ich dazu nichts nützliches... und für mein beispiel tatsächlich auch nur "Anleitungen" via I2C. Wobei die einem im grundverständniss auch nicht wirklich helfen. Mit fertigen Bibliotheken bekommt man das sicher irgendwie hin, ich möchte mir jedoch auch helfen können wenn ich mal keine passende Bibliothek finde oder zb. Irgendwelche arduino Funktionen genutzt werfen die der aktuelle poc nicht kann. Dann gehts ans umschreiben. :)
:
Bearbeitet durch User
Richard S. schrieb: > Hierbei kann ich manuell viele high und lows > eines Pins mit warte befehlen aneinander reihen. Richard S. schrieb: > Das manuelle senden von Daten erscheint mir auf den ersten Blick > also "relativ simpel". Das ist es schon deshalb nicht, weil auf diese einfache Art der Prozessor ausschliesslich mit dem Senden beschäftigt ist und sonst nichts tun kann, was i.A. wenig sinnvoll ist - ein System das nur Daten sendet erfüllt ja keinen praktischen Zweck (welche Daten überhaupt?). Es können nicht einmal zur gleichen Zeit Daten empfangen werden. In der Praxis werden daher immer Interrupts verwendet, im einfachsten Fall ein Time Interrupt, der häufig genug aufgerufen wird um sowohl das nächste Bit zu senden als auch den Dateingang zu prüfen, ob ein Bit empfangen wurde. Alle 1 ms ist dabei für den Prozessor garkein Problem und zwischendurch kann er alle möglichen anderen Aufgaben erledigen. Ist für einen Anfänger schon kompliziert, tut mir ja leid, aber so ist die Welt nun mal. Georg
Georg schrieb: > Das ist es schon deshalb nicht, weil auf diese einfache Art der > Prozessor ausschliesslich mit dem Senden beschäftigt ist und sonst > nichts tun kann, was i.A. wenig sinnvoll ist - ein System das nur Daten > sendet erfüllt ja keinen praktischen Zweck (welche Daten überhaupt?). Es > können nicht einmal zur gleichen Zeit Daten empfangen werden Hi Georg danke für deine Antwort. Ja an diesem Punkt war ich auch bereits bzw. Wenn ich alle 0.5A sende ubd dazwischen andere aufgaben mache wäre das ja vertretbar. Zur gleichen Zeit Daten empfangen geht ja streng genommen eh nicht oder? Hier arbeitet der uC doch dann ein senden Kommando und gleich dannach ein empfangen Kommando ab (stelle mir das etwas vor wie bei threads) nur eben Interrupt basiert. Kannst du mir eine gute Quelle empfehlen die den Vorgang mit den Timern erklärt? Sicher ist es kompliziert aber ich möchte ja dabei auch einiges lernen :) Mit einem Raspberry Pi oder sogar Pico fällt dies tatsächlich einfacher (zumindest zum programmieren) allerdings ist der code dann unendlich uneffizient weshalb ich es gern von der pieke verstehen möchte einfach den aufabu. Um Treijer nachzuvollziehen und zu modifizieren Danke für die Rückmeldung:)
Richard S. schrieb: > Aber wie ist das nun mit dem empfangen? Spontan würde mir lediglich > einfallen die Zeitabstände zwischen bitänderungen zu messen und das > ganze dann mit 1000enden if Verknüpfungen zu entfriemeln aber mir > scheint das kann nur falsch sein... Ja, stimmt, ist falsch. Typisch reicht genau ein "if" und einige "for" aus. Man schreibt sich eine Funktion, die ein Bit empfängt. Diese ruft man in einer Schleife 8* auf und setzt daraus ein Byte zusammen. Diese ruft man wiederum in einer Schleife entsprechend der Paketlänge auf und speichert alle Bytes in ein Array. Fertig ist die Nachricht.
Richard S. schrieb: > Zur gleichen Zeit Daten empfangen geht ja streng genommen eh nicht oder? Doch, natürlich geht das. SPI funktioniert sogar nur so, da wird immer gleichzeitig gesendet und empfangen. Wie Dir aber schon gesagt wurde, werden die meisten seriellen Schnittstellen (synchron, asynchron, egal) aus guten Gründen mit spezieller dafür konzipierter Hardware betrieben und nicht im "Bitbanging"-Verfahren durch Wackeln bzw. Auslesen von Portpins nachgebildet. Die entsprechende Hardware übernimmt das Senden und Empfangen mindestens eines Bytes und kann dann mit einem Interrupt sowohl den erfolgreichen Empfang als auch das erfolgreiche Versenden verkünden, auf daß das empfangene Byte abgeholt wird oder das nächste zu sendende Byte der Hardware zur Verfügung gestellt wird. So macht es nicht nur der angeblich "ineffiziente" Raspberry Pi, so macht es auch annähernd jeder Microcontroller, vom AVR über PIC hin zu beliebigen ARMen. Es gibt Situationen, in denen es sinnvoll ist, eine Schnittstelle durch "Bitbanging" nachzubilden, das ist beispielsweise dann der Fall, wenn der verwendete µC keine dedizierte Hardware dafür hat, oder mehr Schnittstellen benötigt werden, als vorhanden sind, oder ein bizarres Protokoll benötigt wird, das sich nicht mit einer der verfügbaren Schnittstellen nachbilden lässt, wie die beliebten ws2812-LEDs. Ein besonders extremes Beispiel für "Bitbanging" ist V-USB, das ist eine reine Softwarenachbildung von Low-Speed-USB (1.5 MBit/sec), was beispielsweise für USB-Eingabegeräte (HID) völlig ausreichend ist und schon mit einem Attiny85 umsetzbar ist. Aber so etwas macht man nicht ohne Not. Sonst verwendet man die UART, USART oder was auch immer der jeweilige µC so im Programm hat.
Zunächst mal vielen Dank! @peter so etwas habe ich zb. Gesucht danke! Also zb. Wäre das ein if cs high dann empfange daten synchron zum clock signal bzw. Eben schnell aufeinanderfolgend. :) @der echte Bernd, mit ineffizient auf dem PI meinte ich "bitbangig" prozesse in python als thread laufen lassen wäre ineffizient :). Wenn die Hardware das senden / empfangen byteweise macht. Wie erkläre dann dem treiber also dem headerfile einer peripherie, was was ist und wie das ganze funktioniert? Also ich fand alles an Informationen super! Ich habe woe gesagt konkret den fall das ich für den BoschBMP280 Keinen SPI treiber für den pic gefunden habe. Ich habe aber nur einen MSSP port und möchte die ergebnisse auf eine SD karte speichern. Später dann mal via RS485 mit anderen geräten teilen. Aber wie beschrieben möchte ich nicht einfach fertige codeschnipsel aus 5 dutzend tutorials zusammenschnipseln sondern es selbst lernen. Gibt es denn Literaten wie ich die Hardware richtig nutze? Kann ich den MSSP im laufenden betrieb wechseln lassen? All dieses wissen das ich brauche suche ich. Danke!
Richard S. schrieb: > Ich habe aber nur einen MSSP port Zeig doch mal mit einem Link, welchen MSSP an welchem IC du da meinst. Dann kann man sich mal ansehen, was dieser MSSP denn überhaupt ist...
Lothar M. schrieb: > Richard S. schrieb: >> Ich habe aber nur einen MSSP port > Zeig doch mal mit einem Link, welchen MSSP an welchem IC du da meinst. > > Dann kann man sich mal ansehen, was dieser MSSP denn überhaupt ist... Ein PIC18F45K40 Er hat eine SPI oder I2C schnittstelle und ausserdem UART. Soweit ich das verstanden habe. Ich habe auch mal gelesen das man spi und i2c "zeitgleich" nutzen kann indem man die leitungen entsprechend high zieht sodass das andere gerät nicht anspricht wenn es nicht gemeint ist aber das erscheint mir recht umständlich. Den i2c treiber des bmp280 auf spi ummünzen wäre mir persönlich lieber :)
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.