|
Anzeige
|
Funksignale mit Handy senden
Gast
#5060609
Hallo zusammen Ich muss eine Projektarbeit machen. Ich habe mich dazu entschieden einen Schlüsselanhänger zu machen, welcher, wenn man den Schlüssel nicht findet, mit einer App auf dem Handy zum Piepsen bringen kann. Nun zur Frage: Is es möglich mit einer Handy-App ein Funksignal auszugeben?? Wenn ja wie?? Und ist dies Legal? Gruss Joel P.S. Wenn ich diesen Post im falschen Forumteil Poste -> Sorry....
Gast
#5060613
Bluetooth
Gast
#5060616
Das habe ich auch gedacht. Nur muss der Anhänger nicht 24/7 mit dem Handy verbunden sein?? Joel schrieb: > Is es möglich mit einer Handy-App ein Funksignal auszugeben?? > Wenn ja wie?? Und ist dies Legal? So ein Telefon hat einen Haufen Funkmöglichkeiten, für dich kommen aber nur 2 davon in Frage: WLAN oder Bluetooth. Ein Signal wie z.B. eine Funkklingel oder ein Autoschlüssel senden, kannst du mit 'nem Smartphone nicht.
Gast
#5060618
OK danke für deine Antwort^^. Die gleiche frage wie vorhin. Ich kenn Bluetooth so, dass man zuerst ein Knopf auf dem Empfänger-Gerät drücken muss um sich mit dem Handy verbinden zu können. Dies wäre ja nicht möglich wenn man den Schlüsselbund nicht finden würde. Gibt es also eine Möglichkeit den Schlüsselanhänger ohne einen Knopfdruck oder so mit dem Handy zu verbinden?? einmalig musst du das Pairing durchführen. Danach finden sich die Geräte ohne weitere Aktion.
Gast
#5060630
Danke vielmals für eure Antworten habt mir wirklich weitergeholfen :D
Gast
#5060633
Könnte mir jmd ein Bleutooth empfänger empfehlen?? Ich weis nicht mehr das gleiche Thema wie im Titel aber ein neuer Thread machen bringst auch ned, da dann der Background nicht bekannt ist.
Gast
#5060640
Ein GSM Modul würde auch funktionieren, wäre aber vermutlich zu groß. In den 1980er Jahren wurde der Schlüsselanhänger durch eine Pfeifton mit dem Mund aktiviert, daraufhin hat er im Intervall zurückgepiepst.
Gast
#5060652
> Könnte mir jmd ein Bleutooth empfänger empfehlen??
Nein. Aber da der Schlüsselanhänger mit Batterie lange laufen soll muss
es wohl ein BLE Gerät sein und du brauchst auch ein Smartphoen, daß BLE
unterstützt.
Generell ist die Iddee, verlorene Dinge per Funk wiederzufinden bzw das
Vergessen duch einen Alarm zu verhindern nicht neu. Doch die Menschheit
hat dafür noch keine wirklich praktikable Lösung gefunden.
Das Problem ist die Stromaufnahme des Funkempfängers. Damit der länger
als einen Tag funktioniert, brauchst du einen zu großen Akku.
Kannst ja mal hier gucken: https://www.sparkfun.com/categories/115 Am billigsten und kleinsten wäre aber vermutlich ein BT Headset, das auch klingeln kann. Deine App muss dann nur noch das Headset zum Klingeln bringen. z.B.: https://www.reichelt.de/Freisprecheinrichtungen-Headsets/FONTASTIC-NAT/3/index.html?ACTION=3&LA=446&ARTICLE=161479 Gibts auch sehr kleine als In-Ear Schmalzbohrer: http://www.ebay.de/itm/Mini-Bluetooth-Headset-V-4-1-Stereo-Kabellos-Inear-Kopfhorer-fur-Ein-Ohr-Musik-N-/122538395921 usw. Ob die klingeln, weiss ich aber nicht.
Gast
#5060655
> z.B. https://www.reichelt.de/Freisprecheinrichtungen-Headsets/FONTASTIC-NAT/3/index.html?ACTION=3&LA=446&ARTICLE=161479 Naja, mir würden 4 Stunden Akku-Laufzeit nicht genügen. Und wetten, die Stromaufnahme steigt, wenn man sich außerhalb der Funk-Reichweite bewegt?
Gast
#5060663
Vielen dank für eure Unterstüzung. Da die meisten von euch meinen das der Akku zu klein wäre muss ich wohl ein neues Projekt finden. Aber troztallem vielen dank für die Erweiterung meines Technischen Wissens Gruss Joel
Gast
#5060673
Joel schrieb: > Vielen dank für eure Unterstüzung. Da die meisten von euch meinen das > der Akku zu klein wäre muss ich wohl ein neues Projekt finden. Aber > troztallem vielen dank für die Erweiterung meines Technischen Wissens > > Gruss > Joel In Wikipedia steht das Geräte mit ab Android 4.3 und IOS 5, BLE integriert haben. Falls das stimmt ist die Laufzeit mit einem Tag auch nicht mehr so schlimm da sie gleichlange wie die eines viel gebrauchten Smartphone's ist. Dann kann man mit USB und villeicht, wenn ich noch zeit vor der Abgabe habe, Drahtlos aufladen (z.B. wenn man den Schlüssel normalerweise irgwendwo aufhängt dahinter eine Drahtlos Ladestation -> Natürlich wenn der Schlüssel über Nacht nicht dahingetan wird, um am nächsten Morgen gesucht wird ist der Anhäger für nichts). Troztallem ich habe alle meine Antworten und danke euch Herzlichst dafür^^ Gruss Joel
Gast
#5060676
Gast
#5060709
Matthias S. schrieb: > So ein Telefon hat einen Haufen Funkmöglichkeiten, für dich kommen aber > nur 2 davon in Frage: WLAN oder Bluetooth. Hast du dir mal die Stromaufnahme von WLAN angeguckt? An was für eine Stromversorgung hast du denn gedacht, damit der Schlüssel im WLAN lauschen kann? Da kannst du dir besser gleich angewöhnen, den Schlüssel auf die Docking-Station zu legen und andernfalls sofort piepsen zu lassen. Das spart auch die ganze Funkerei ;-)
Gast
#5060775
Joel schrieb: > Falls das stimmt ist die Laufzeit mit einem Tag auch > nicht mehr so schlimm Vielleicht kommt man besser hin, wenn man es umgekehrt macht und der Schlüssel funkt das Handy an - aber nur alle 2 Minuten für einen Sekundenbruchteil, dazwischen ruht er mit nahezu Null Stromverbrauch. 2 Minuten Wartezeit wenn man den Schlüssel nicht mehr findet ist schon zumutbar. Georg
Gast
#5060795
Die Batterie eines handelsüblichen Schlüsselfinders mit Bluetooth hält etwa ein halbes Jahr. Wolfgang schrieb: > Hast du dir mal die Stromaufnahme von WLAN angeguckt? Darum ging es gar nicht. Die Frage, die beantwortet wurde, war die hier: Joel schrieb: > Is es möglich mit einer Handy-App ein Funksignal auszugeben?? > Wenn ja wie?? Und ist dies Legal? Ob WLAN sinnvoll ist oder nicht, ist eine ganz andere Baustelle. Ton Schall Ultraschall? http://www.connect.de/news/ultraschall-tracking-smartphone-apps-silverpush-spyware-3197186.html
Gast
#5060812
Matthias S. schrieb: > Wolfgang schrieb: >> Hast du dir mal die Stromaufnahme von WLAN angeguckt? > > Darum ging es gar nicht. Doch, mein Kommentar bezog sich auf deinen Beitrag, in dem du WLAN als in Frage kommende Funkmöglichkeit genannt hast. Matthias S. schrieb: > So ein Telefon hat einen Haufen Funkmöglichkeiten, für dich kommen aber > nur 2 davon in Frage: WLAN oder Bluetooth. Wenn das Smartphone einen Accesspoint auf macht und der Schlüssel sich dort ab und zu mal meldet und ansonsten schläft, wäre das eher machbar - aber nicht wenn der Schlüssel dauernd lauscht, ob ihn jemand ruft, wie von Joel zunächst angedacht. Wolfgang schrieb: > An was für eine > Stromversorgung hast du denn gedacht, damit der Schlüssel im WLAN > lauschen kann? Man kann ja einen Autoakku als Schlüsselanhänger verwenden. :-) Es gibt auch ne Menge Leute, die mit dem ESP2866 bzw. dessen Nachfolgern was basteln. Deswegen schliesse ich eine stromsparende Anwendung auch nicht von vorneherein aus. Joel schrieb: > Das habe ich auch gedacht. Nur muss der Anhänger nicht 24/7 mit dem > Handy verbunden sein?? Besser ist das. Sonst klingelt das Handy und der Schlüssel liegt ganz woanders ... Vorteil: Du brauchst nur Deine Telefonnummer und ein weiteres Telefon, wenn Du die Funktion nutzen möchtest. **duck und weg* Gruß Jobst Joel schrieb: > Is es möglich mit einer Handy-App ein Funksignal auszugeben?? > Wenn ja wie?? Und ist dies Legal? NEIN! Mit so wenig Wissen derart Blauäugig ein solches Thema zu wählen ist verboten Dumm. Google mal nach Cypress PSoC BLE, dann solltest du ein development kit für bt low energy finden, für welches die (kostenlose) IDE sogar ein 'keyfinder'-demoprojekt bzw. -modul. Vielleicht hilft dir das weiter.
Gast
#5061218
Vielen Dank an all die netten Antworten. @cyblord: Ich habe ein halbes Jahr dafür Zeit. Ich möchte gerne etwas lernen und dabei ist so ein Kommentar nicht sehr behilflich und Zeitverschwendung. Es geht nicht darum etwas neues zu erfinden, sondern etwas selber zu machen, was man dann vor einem grösserem Publikum vorstellen kann. Das Thema sollte so gewählt sein, dass es was mit deiner Person zu tun hat. Da ich Zuhause viel den Schlüssel verlege (Bin vergesslich wie ne Nuss), wäre das Thema passend. Nun ob ich das Ziel erreiche, einen Funktionierenden Schlüssel finder zu basteln, oder auch nur die Idee theoretisch geblieben ist, ist völlig egal. Ich hoffe mal das du verstehts was ich meine und einen solchen Kommentar nicht mehr Potest. Freundliche Grüsse Joel
Gast
#5061265
Matthias S. schrieb: > Es gibt auch ne Menge Leute, die mit dem ESP2866 bzw. dessen Nachfolgern > was basteln. Deswegen schliesse ich eine stromsparende Anwendung auch > nicht von vorneherein aus. Die Sleep Modi vom ESP8266 kann man im Low Power Solutions Guide von Espressif nachlesen. https://espressif.com/sites/default/files/documentation/9b-esp8266-low_power_solutions_en.pdf Im Modem Sleep Modus (15mA) und im Light Sleep Modus (0.6 .. 2mA je nach DTIM Intervall) bleibt die WiFi Verbindung aktiv und das Modul muss im Takt der WLAN Beacon Signale aufwachen. Aus dem Deep Sleep Modus (20µA) muss die WiFi Verbindung bei jedem Aufwachen neu hergestellt werden. Der sinnvollste Ansatz ist meiner Meinung nach eindeutig Bluetooth 4.x/BTLE. Von den in Frage kommenden Funktechnologien hat nur Bluetooth LE die Eigenschaften, die man von einem möglichst idealen "Schlüsselfinder" erwarten würde - z.B., dass der Stromverbrauch so gering ist, dass der Schlüsselfinder mit einer kleinen Knopfzelle betrieben werden kann (und auch entsprechend klein ist), trotzdem wochenlang hält, und ein Kontaktieren des Schlüsselfinders nicht nur alle paar Minuten möglich ist. BTLE hat auch den kleinen (aber möglicherweise interessanten) Vorteil, dass man auf BTLE-Geräte mittels der "Web Bluetooth API" zugreifen kann (auch wenn diese bislang lediglich von Chrome unterstützt wird); es wäre also theoretisch möglich, die "App" zur Nutzung des Schlüsselfinders nicht als native (Android/iOS/whatever) App, sondern als reine Web-App in HTML/Javascript zu implementieren, die ohne Änderung auf jedem Betriebssystem läuft, für das es einen Web Bluetooth API-fähigen Webbrowser gibt, und die man nicht einmal installieren muss. Wenn ich der Threadstarter wäre, würde ich mir konkret z.B. mal den nRF51822 BTLE SoC anschauen. Dieser wird u.A. z.B. vom "BBC micro:bit" verwendet - für den Anfang würde ich mir also vermutlich einfach mal ein BBC micro:bit-Board holen: http://www.pollin.de/shop/dt/MDA0OTgxOTk-/Bauelemente_Bauteile/Entwicklerboards/Sonstige_Boards/BBC_Micro_bit_Singleboard_MB80.html
Gast
#5061402
http://www.pollin.de/shop/dt/MDA0OTgxOTk-/Bauelemente_Bauteile/Entwicklerboards/Sonstige_Boards/BBC_Micro_bit_Singleboard_MB80.html Oh, cool. Endlich gibt es diese Board zu einem angemessenem Preis.
Gast
#5063611
http://www.pollin.de/shop/dt/MDA0OTgxOTk-/Bauelemente_Bauteile/Entwicklerboards/Sonstige_Boards/BBC_Micro_bit_Singleboard_MB80.html Muss man da auch noch ein weiteres Kit kaufen welches Bluetooth handelt oder reicht dieses Dev Kit?? All diese Kits auf der Nordic webseite verwirren mich ... Hallo Joel, das MircoBit hat noch den "alten" mit M0+ SoC drauf: https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF51822 Der kann auch BLE4 und sollte für deine Zwecke locker reichen. Wenn du jedoch den aktuellen SoC magst, gibt es neben dem Dev.Kit von Nordic auch was mit Arduino-Umgebung: https://www.adafruit.com/product/3406 Für die anderen Boards bräuchtest du in der Regel noch einen JTAG/SWD-Adapter zum Programmieren/Debuggen. Auf dem nRF52-DK wäre schon ein J-Link dafür drauf. Nordic hat auch schon ein fertiges Beispiel für deinen Fall (Link Loss Service): http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v13.0.0/ble_sdk_app_proximity.html?cp=4_0_0_4_1_2_14
Gast
#5063655
Vielen Dank für diese Antwort, hat mir wirklich weitergehofen :)
Gast
#5063660
Ich habe mir mal das dev. Kit gekauft. Da ich nun auf arbeit zeit überbrücken muss, hae ich schon mal mit dem Schema für das fertige Produkt angefangen. Nun ich habe ein Bild gefunden, auf welchem die Beschaltung des nrf51822 für 1.8V zu sehen ist. Nun habe ich gesehen das ich im dev. Kit gleich eine Knopfbatterie mitbekomme welche 3V Spannung hat(ich hoffe mal das ist richtig gesagt, kommt mir nichts anderes in den Sinn). So mit frage ich mich nun geht diese Beschaltung auch für 3V??
Angehängte Dateien:
Gast
#5063684
Na klar, die gilt auch für 3V Ja, für den Zweck ist BLE ideal. Viele moderne Taschentelefone haben BLE onboard und iOS und Android haben APIs für den Zugriff auf BLE GATT/GAP. Die nrf51/nrf52 von Nordic scheinen mir die am besten dokumentierten Lösungen zu sein. Der Schlüssel ist dabei ein GATT-Server, zu dem man Verbindung aufnehmen kann und den Schlüssel zum piepsen bringen kann. Besteht keine Verbindung, sendet der Schüssel periodisch sogeanannte Advertisings. Wenn die Periodenlänge entsprechend lang und die Sendeleistung entsprechend gering ist, kann so ein Sender mit einer Knopfzelle durchaus ein Jahr lang senden. Beim Suchen (scannen) nach so einem Sender liefern die APIs von Android und iOS auch die Empfangsstärke. Diese Information könntest Du nutzen, um zu erkennen, ob Du dich dem Schlüssel näherst, oder weiter entfernst. Für Client Prototypen finde ich Noble ganz praktisch: https://github.com/sandeepmistry/noble BLE ist aber nicht ganz trivial. Ein Eval-Board von Nordic kann man übrigens relativ einfach als BLE Sniffer verwenden, was bei der Entwicklung recht hilfreich ist. @Stefan: Datenblatt lesen, bevor er den SoC zerschießt! 3V geht natürlich auch, aber dann musst du DEC2 von VCC trennen.
Angehängte Dateien:
Gast
#5063712
Nochmal vielen, vielen Dank. :) Und falls Du lieber C++ als C für die Implementierung nehmen möchtest, könnte ich Dir noch meine OpenSource BLE GATT Client library Bluetoe ans Herz legen. Dieses Beispiel hier, würde schon weitgehend machen, was Du brauchst: http://robitzki.de/blog/Getting_Started_with_Bluetoe
Gast
#5063731
Auch wenn es extrem praktisch wäre eine Library benutzen zu können, ist dies nicht möglich da ich null Ahnung von C++. Auch bei C ist mein Wissen recht klein. Wenn du aber denkst das ich nicht viel C++ lernen muss um deine Library, gebrauchen zu können, würde ich sie sofort benutzen. :D
Gast
#5063734
Da ich mit dem nrf51 Dev Kit 5x 51422 mit bekomme wollte ich fragen was der grösste Unterschied zum 51822 ist?? Aber geht bitte nicht für mich in die Datenblätter suchen, diese Frage muss nicht Beantwortet werden. Ich dachte das es villeicht jmd Wissen könnte. Joel schrieb: > Wenn du aber denkst das ich nicht viel C++ lernen > muss um deine Library, gebrauchen zu können, würde ich sie sofort > benutzen. :D Ich denke natürlich, dass es extrem einfach ist, die Lib zu verweden. Ich mache C++ aber auch jeden Tag. Wenn Du nicht ernsthaft vorhast, irgendwann C++ zu lernen, würde ich bei C bleiben und das SDK von Nordic verwenden. Joel schrieb: > Da ich mit dem nrf51 Dev Kit 5x 51422 mit bekomme wollte ich fragen was > der grösste Unterschied zum 51822 ist?? Aber geht bitte nicht für mich > in die Datenblätter suchen, diese Frage muss nicht Beantwortet werden. > Ich dachte das es villeicht jmd Wissen könnte. Der 51422 kann auch ANT (der 51822 nur BLE). Wenn Du nur BLE nutzt, ist da faktisch kein Unterschied.
Gast
#5063740
@torstenrobitzki Vielen Dank für die Antwort^^. Ich leider ein Kind der neuen Generation und beschäftige mich sehr viel mit C#. Ja ich weis C++ und C# ist ned das gleiche, aber ich mag das .Net Framework. Aber wer weis ich mit meinen 17 Jahren hab noch viel Zeit um andere Sachne zu lernen^^ Joel schrieb: > @torstenrobitzki > > Vielen Dank für die Antwort^^. Ich leider ein Kind der neuen Generation > und beschäftige mich sehr viel mit C#. Ja ich weis C++ und C# ist ned > das gleiche, aber ich mag das .Net Framework. Aber wer weis ich mit > meinen 17 Jahren hab noch viel Zeit um andere Sachne zu lernen^^ C# habe ich auch schon vor 10 Jahren gemacht, neu ist diese Misschung aus Delphi und Java jetzt ja auch nicht mehr ;-) Damit kannst Du aber (zumindest z.Z.) eben keine Firmware für Mikrocontroller schreiben.
Gast
#5063749
Joel schrieb: > Vielen Dank für die Antwort^^. Ich leider ein Kind der neuen Generation > und beschäftige mich sehr viel mit C#. Ja ich weis C++ und C# ist ned > das gleiche, aber ich mag das .Net Framework. Aber wer weis ich mit > meinen 17 Jahren hab noch viel Zeit um andere Sachne zu lernen^^ Jetzt beim wiederlesen ist mir aufgefallen das der Text kein Sinn ergibt. Was ich sagen wollte: Ich lerne C# und Unity in meiner Freizeit und möchte auch Software engineering richtung .NET Studieren. Mehrere Sprachen zu kennen ist immer gut, jedoch habe ich im moment keine pläne mit C++. Hallo Torsten, deine Library sieht interessant aus - mit dem SDK von Nordic hat man ja schon immer recht viel Code :) Hast du dein Projekt mal auf einen nRF52 portiert? Mit jedem SDK ändert sich ja immer ein wenig... Oliver h. schrieb: > deine Library sieht interessant aus - mit dem SDK von Nordic hat man ja > schon immer recht viel Code :) Hast du dein Projekt mal auf einen nRF52 > portiert? Mit jedem SDK ändert sich ja immer ein wenig... Ja, z.Z. nutze ich sogar nur den nrf52. Das SDK von Nordic nutzt Bluetoe allerdings auch, um die peripheral definitionen zu haben. Bluetoe nutzt allerdings nicht das softdevice.
Gast
#5064458
Noch ne Frage zu den Nordic Produkten. Mit welcher Programmierumgebung kann ich das DK programmieren. Die einzige die ich kenne ist Visual Studio, aber die programmiert ja keine externen Geräte. Noch was ich möchte in C++ und nicht in C programmieren. Vielen Dank Joel Joel schrieb: > Mit welcher Programmierumgebung kann ich das DK programmieren. Nordic liefert ein tools namens `nrfjprog`, mit dem kannst Du den nrf51 flashen. Das DK verhält sich aber auch, wie ein JLink, der über SWD mit dem nrf51 verbunden ist. Wenn Du eine IDE einsetzt, die Support für den JLink hat, dann wird das sicher funktionieren. Ich persönlich arbeite in allen Projekten mehr oder weniger mit dem selben setup: CMake, GCC, GIT und Sublime (Beispiel: https://github.com/TorstenRobitzki/approximation_alarm) > Noch was ich möchte in C++ und nicht in C programmieren. Glückwunsch, dann könntest Du Bluetoe verwenden. Bluetoe hat aber noch einige Macken. Z.b. hat Bluetoe keinen Security Manager, weshalb sich Windows-Geräte wohl nicht als Gegenstück eignen würden.
Gast
#5064515
Vielen Dank für die Infos. Nun, wäre es möglich einen Security Manager auf eine andere Art und Weise zu implementieren??? Joel schrieb: > Nun, wäre es möglich einen Security Manager auf eine andere Art und > Weise zu implementieren??? Bluetoe ist OpenSource und Pullrequests sind willkommen ;-) Ich denke für einen "Profi" ist das eine überschaubare Aufgabe. Man muss beim Design halt aufpassen, dass man den Support der Hardware irgend wie mit rein nimmt. Hast Du den vor ein Windows-Telefon für die Gegenseite zu verwenden?
Gast
#5064545
Hatte es nicht vorgehabt. Da ihr alle mir das leben so vereinfacht habt muss ich noch extrapunkte zu meiner arbeit hinzufügen um genügen Seiten zu haben. Da ich, nach meiner Meinung, ein kleiner Perfektionist bin, wäre es mir ein Wunsch das Programm für alle Handybetriebssysteme zu schreiben. Somit wäre Windowsphone auch drinn. :D Nun über Security Management habe ich null Erfahrung.... Somit wollte ich nur Wissen ob es möglich wäre dies zu selber zu implementieren. Da ich noch 6 Monate Zeit habe, wäre es möglich das ich es mir beibringen könnte oder is es zu schwierig für einen Anfäger?? P.S. Ich weiss der Post hört sich komisch an, Fragen und Texte schreiben sind nicht meine Stärke
Gast
#5064566
Noch was anderes wegen Bluetoe. Warum brauchts du NRF_GPIO->OUT??? Was ist der Unterschied zu NRF_GPIO->OUTSET und NRF_GPIO->OUTCLR?? Joel schrieb: > Nun über Security Management habe ich null Erfahrung.... > Somit wollte ich nur Wissen ob es möglich wäre dies zu selber zu > implementieren. > Da ich noch 6 Monate Zeit habe, wäre es möglich das ich es mir > beibringen könnte oder is es zu schwierig für einen Anfäger?? Naja, kommt drauf an, wie schnell Du lernst. C++ ist für 6 Monate (Vollzeit?) schon sehr ambitioniert. Für Bluetoe braucht man dann auch noch bestimmtes Wissen, mit dem man in der Regel nicht beginnt (template meta programming). Der Security Manager ist Volume 3, Part H der Core Specification beschrieben. Du kannst mir ja mal eine PM mit EMail-Adresse schicken. Du könntest mit dem Bluetoe Beispiel anfangen, dann hast Du die Firmware quasi schon fertig. Dann könntest Du iOs und Android Clients schreiben. Dann könntest Du entscheiden, ob Du bei Bluetoe bleiben möchtest und den SM schreiben möchtest, oder ob Du die Firmware lieber auf das Nordic SDK portierst. > P.S. Ich weiss der Post hört sich komisch an, Fragen und Texte schreiben > sind nicht meine Stärke Alles gut! ;-) Joel schrieb: > Warum brauchts du NRF_GPIO->OUT??? Um den Zustand des Pins zu definieren. > Was ist der Unterschied zu NRF_GPIO->OUTSET und NRF_GPIO->OUTCLR?? Das sind Register, mit denen man gezielt einzelnde Port-Pins auf 1 bzw. 0 setzen kann. Der Unterschied zur Verwendung von dem Register OUT ist, dass man bei der Verwendung von OUT lesen-modifizieren-schreiben muss und dass kann zu Fehlern führen, wenn es konkurierende Zugriffe auf das Register gibt. Das sind aber Details, für die Du Dir in den 6 Monaten Zeit nehmen solltest um sie aus dem Datenblatt des Chips heraus zu lesen. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
