IR Empfänger mit Attiny85/45 funktioniert nie

[Lukas G. (luke21)]

Guten Abend,

ich plane mithilfe eines Attiny45/85 ein Relais über IR zu steuern.
Zum Einsatz kommt ein 38kHz Empfänger.
Zu Testzwecken habe ich auf einem Arduino Uno bereits ein paar Tests 
durchgeführt. Zum Einsatz kamen dabei die IRremote.h und tiny_IRremote.h 
Library, welche auch einwandfrei funktioniert.
Möchte ich dasselbe auf dem Attiny probieren, funktioniert garnichts 
mehr.
Ich hab dafür alle Methoden probiert, die im Internet standen, sprich 
verschieden Libraries für Attiny installiert, verschiedene 
Taktfrequenzen, verschiedene Pinbelegungen, verschiedene Spannungslevel 
usw.
Haupstächlich habe ich mich auf diese Tutorials konzentriert:
https://www.instructables.com/Attiny-IR-library/
https://www.instructables.com/Attiny-IR-library/

(Test-)Sketches habe ich u.A. folgende verwendet:

#include "IRremote.h"

int receiver = 0; // Signal Pin of IR receiver to Arduino Digital Pin 11

/*-----( Declare objects )-----*/
IRrecv irrecv(receiver);     // create instance of 'irrecv'
decode_results results;      // create instance of 'decode_results'

/*-----( Function )-----*/
void translateIR() // takes action based on IR code received

// describing Remote IR codes 

{

  switch(results.value)

  {
  case 0xFFA25D: digitalWrite(4,HIGH);
  break;
  case 0xFFE21D: digitalWrite(4,LOW);
  break;

  default: 
{
  
}

  }// End Case

  delay(500); // Do not get immediate repeat


} //END translateIR
void setup()   /*----( SETUP: RUNS ONCE )----*/
{
  pinMode(4,OUTPUT);
  pinMode(2,INPUT);

  irrecv.enableIRIn(); // Start the receiver

}/*--(end setup )---*/


void loop()   /*----( LOOP: RUNS CONSTANTLY )----*/
{
  if (irrecv.decode(&results)) // have we received an IR signal?

  {
    translateIR(); 
    irrecv.resume(); // receive the next value
  }  
}/* --(end main loop )-- */

Und

#include <IRremote.h>

int RECV_PIN = 0;
int led1 = 1;   
int led2 = 4;   

int state[] = {0,0,0};

#define code1 0xFFA25D  // Button 1 Code
#define code2 0xFFE21D  // Button 2 Code


IRrecv irrecv(RECV_PIN);

decode_results results;

void setup()
{
irrecv.enableIRIn(); 
pinMode(led1, OUTPUT);
pinMode(led2, OUTPUT);

}

void loop() {
if (irrecv.decode(&results)) {
unsigned int value = results.value;
switch(value) {
case code1:
if(state[1] == 1) {       // if first led is on then
digitalWrite(led1, LOW);  // turn it off when button is pressed
state[1] = 0;             // and set its state as off
} else {                  // else if first led is off
digitalWrite(led1, HIGH); // turn it on when the button is pressed
state[1] = 1;             // and set its state as on
}
break;

}
irrecv.resume(); 
}
}

Ich bin echt schon am verzweifeln und wäre so dankbar, wenn mir da 
jemand weiterhelfen könnte...
[ Weiß nicht ob das relevant ist aber beim IR-Pin messe ich (leider ohne 
Oszilloskop) bei VCC=5V ohne Signal 5V und bei anliegendem Signal ca 
4-4,7V ]

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Lukas G. schrieb:
> int receiver = 0; // Signal Pin of IR receiver to Arduino Digital Pin 11

Ich bin sicher kein Arduino Spezi, aber war das nicht so, das die Ports 
für PortA von 0-7 gingen? Da der Tiny nur PortB hat, könnte für PB0 also 
eine andere (wie z.B. 8) Zahl stehen.

Aber wie dem auch sei, du suchst sicher IRMP:
https://www.mikrocontroller.net/articles/IRMP
IRMP ist eine robuste Lösung, um alle möglichen IR Fernbedienungen zu 
empfangen. Das Gegenstück heisst IRSND und ist genauso zuverlässig.
Um Platz zu sparen, kompilierst du nur das Protokoll, das du brauchst.
Ausserdem läuft es bestens auf einem Tiny45/85, wie ich dir aus eigener 
Erfahrung sagen kann.

[Wolfgang (Gast)]

Lukas G. schrieb:
> [ Weiß nicht ob das relevant ist aber beim IR-Pin messe ich (leider ohne
> Oszilloskop) bei VCC=5V ohne Signal 5V und bei anliegendem Signal ca
> 4-4,7V ]

Das Multimeter misst einen Mittelwert, d.h. das Absinken der Spannung 
bei anliegendem Signal verrät dir wahrscheinlich, dass das Signal 
zeitweise auf L-Pegel liegt.
Für Probleme rein digitaler Natur brauchst du nicht unbedingt ein Oszi. 
Ein Logikanalysator kann gerade bei Datenübertragung und Timingfrage 
fast noch besser helfen. Mit den kleinen 8-Kanal LA für unter 10..15 € 
kommt man oft recht weit.

[Lukas G. (luke21)]

Attiny hat PB ja, aber ich habs jetzt eh überall schon getestet.
Wie hast du das denn zum Laufen gebracht?

[Kuno (Gast)]

Bei so einem Tiny 25..85 halte ich C für Overkill, aber das ist nur 
meine MEINUNG.
Du benutzt eine IR-Library, der man doch bestimmt mitteilen muss,
wo das IR-Signal reinkommt wie die IR-Codes aussehen.

Diese Zeilen könnten dem Compiler sagen, was IN, was OUT sein soll,
obwohl es mich wundert, woher der Compiler wissen soll, ob PortA, PortB, 
oder PortC gemeint sind.
>>  pinMode(4,OUTPUT);   Relais???
>>  pinMode(2,INPUT);    IR-Receiver???
aber weiß das damit auch deine IR-Library??

>> case 0xFFA25D: digitalWrite(4,HIGH);
Soll das die Relais-Ausgabe sein?
Woher kennst du ohne Oszi den IR-Code?

Fang doch mal damit an, der IR-Library den Anschluss des IR-Receivers
mitzuteilen - und lass eine LED z.B. an PortB-0 aufleuchten, wenn grad 
was empfangen wurde.

[Lukas G. (luke21)]

Kuno schrieb:
> aber weiß das damit auch deine IR-Library??

Muss sie wissen, sonst würde es am UNO auch nicht funktionieren

Kuno schrieb:
> Woher kennst du ohne Oszi den IR-Code?

Gibt ja diverse NEC Decoder Sketches, die mir dann den HEX Code 
rausspucken

[Lukas G. (luke21)]

Ich hab mir jetzt die IRMP-Library angeschaut mit dem darin enthaltenen 
Beispielsketch 'MinimalReceiver' der ja speziell für Attinys geeignet zu 
sein scheint.
Ich versteh jetzt nicht ganz wie ich damit umgehen soll. In Zeile 72 
kann ich ja meinen eigenen Code einfügen. Aber was soll der jetzt alles 
beinhalten wenn ich als Beispielcode den erstangeführten Sketch in der 
Fragestellung hernehme?

 /*
 *  MinimalReceiver.cpp
 *
 *  Small memory footprint and no timer usage!
 *
 *  Receives IR protocol data of NEC protocol using pin change interrupts.
 *  On complete received IR command the function handleReceivedIRData(uint16_t aAddress, uint8_t aCommand, bool isRepetition)
 *  is called in Interrupt context but with interrupts being enabled to enable use of delay() etc.
 *  !!!!!!!!!!!!!!!!!!!!!!
 *  Functions called in interrupt context should be running as short as possible,
 *  so if you require longer action, save the data (address + command) and handle it in the main loop.
 *  !!!!!!!!!!!!!!!!!!!!!
 *
 *
 *  Copyright (C) 2020-2021  Armin Joachimsmeyer
 *  [e-mail]
 *
 *  This file is part of IRMP https://github.com/ukw100/IRMP.
 *  This file is part of Arduino-IRremote https://github.com/Arduino-IRremote/Arduino-IRremote.
 *
 *  IRMP is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program.  If not, see <http://www.gnu.org/licenses/gpl.html>.
 *
 */

#include <Arduino.h>

/*
 * Set sensible receive pin for different CPU's
 */
#if defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__) || defined(__AVR_ATtiny87__) || defined(__AVR_ATtiny167__)
#include "ATtinySerialOut.hpp" // Available as Arduino library "ATtinySerialOut"
#  if defined(ARDUINO_AVR_DIGISPARKPRO)
#define IR_INPUT_PIN    9 // PA3 - on Digispark board labeled as pin 9
#  else
#define IR_INPUT_PIN    0 // PCINT0
#  endif

#elif defined(__AVR_ATtiny1616__)  || defined(__AVR_ATtiny3216__) || defined(__AVR_ATtiny3217__)
#define IR_INPUT_PIN    10

#else
#define IR_INPUT_PIN    2
//#define DO_NOT_USE_FEEDBACK_LED // activating saves 12 bytes
#endif

/*
 * Second: include the code and compile it.
 */
#include "TinyIRReceiver.hpp"

/*
 * Helper macro for getting a macro definition as string
 */
#define STR_HELPER(x) #x
#define STR(x) STR_HELPER(x)

void setup() {

}

void loop() {



  
   
}

/*
 * This is the function is called if a complete command was received
 */
#if defined(ESP8266)
void ICACHE_RAM_ATTR handleReceivedTinyIRData(uint16_t aAddress, uint8_t aCommand, bool isRepeat)
#elif defined(ESP32)
void IRAM_ATTR handleReceivedTinyIRData(uint16_t aAddress, uint8_t aCommand, bool isRepeat)
#else
void handleReceivedTinyIRData(uint16_t aAddress, uint8_t aCommand, bool isRepeat)
#endif
{
    /*
     * Print only very short output, since we are in an interrupt context and do not want to miss the next interrupts of the repeats coming soon
     */
    Serial.print(F("A=0x"));
    Serial.print(aAddress, HEX);
    Serial.print(F(" C=0x"));
    Serial.print(aCommand, HEX);
    Serial.print(F(" R="));
    Serial.print(isRepeat);
    Serial.println();
}

[Armin J. (arminj)]

1. Nimm die standard IRremote library und nicht irgendwelche 
abgehangenen Zips aus dubiosen Quellen.
2. Im IRMP Beispiel schalte dein Relay einfach da, wo jetzt die serielle 
Ausgabe steht Zeile 94 ff. und fertig. Und der Loop langweilt sich eben!

[Lukas G. (luke21)]

So jetzt hab ich den SimpleReceiver Sketch von IRMP genommen, die 
Definitionen für die anderen Boards rausgenommen und zuerst über den UNO 
probiert, da hats funktioniert, dann hab ich den exakt gleichen Code auf 
den Attiny geladen, mit den richtigen Pinbelegungen und es funktioniert 
wieder nicht...
Hier mal der Code:

#include <Arduino.h>


#include "PinDefinitionsAndMore.h"
#include <irmpSelectMain15Protocols.h>  // This enables 15 main protocols
#include <irmp.hpp>

IRMP_DATA irmp_data;
int state[] = {0,0};

void setup() {

    pinMode(TONE_PIN ,OUTPUT);
    irmp_init();
}

void loop() {
 
    if (irmp_get_data(&irmp_data)) {
        
        if (!(irmp_data.flags & IRMP_FLAG_REPETITION)) {

            switch (irmp_data.command) {          

            case 0xFD02:
            if(state[1] == 1) {
            digitalWrite(TONE_PIN , LOW); 
            state[1] = 0;            
            } else {                 
            digitalWrite(TONE_PIN , HIGH); 
            state[1] = 1;             
            }
            break;
                   
            default:
            {}
            }
        }
        irmp_result_print(&irmp_data);
    }
}

PinDefinitionsAndMore.h:

 
#if  defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
#include "ATtinySerialOut.hpp" // Available as Arduino library "ATtinySerialOut"
#define IRMP_INPUT_PIN   2
#define TONE_PIN         4

#else
#warning Board / CPU is not detected using pre-processor symbols -> using default values, which may not fit. Please extend PinDefinitionsAndMore.h.
#define IRMP_INPUT_PIN      2
#define TONE_PIN            4
#endif // defined(ESP8266)


#if defined(__AVR_ATmega4809__) // for standard AVR we manage hardware directly in void enablePCIInterrupt()
#define IRMP_USE_ARDUINO_ATTACH_INTERRUPT
#endif

#define STR_HELPER(x) #x
#define STR(x) STR_HELPER(x)

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Wie ich oben schon mal sagte, liegt es mit Sicherheit an den Nummern, 
die Arduino statt anständiger Portbezeichnungen benutzt. Wie z.B. kommt 
man darauf, das Nummer 11 der Port A3 sein soll?
Der Tiny hat nur PortB 0 - 4 (5 nicht benutzen) und darauf muss man die 
Software einstellen. Normalerweise macht man das in der irmpconfig.h, 
aber bei dem Arduino Kram kann ich es dir nicht sagen. Finde das heraus 
und alles wird spielen. Lass dir am besten seriell auch mal die Adresse 
deiner Fernbedienung sagen.

[Stefan F. (Gast)]

Matthias S. schrieb:
> Wie z.B. kommt man darauf, das Nummer 11 der Port A3 sein soll?

Das steht in einer Header Datei vom verwendete Arduino Core. Zum 
Beispiel: 
https://github.com/SpenceKonde/ATTinyCore/blob/master/avr/variants/tinyX5/pins_arduino.h

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Lukas G. schrieb:
> die
> Definitionen für die anderen Boards rausgenommen und zuerst über den UNO
> probiert, da hats funktioniert, dann hab ich den exakt gleichen Code auf
> den Attiny geladen

Rausnehmen ist normalerweise nicht nötig, denn das erkennt IRMP von 
alleine. Für den Tiny45/85 wird bei IRMP Timer 1 benutzt, aber der ist, 
soweit ich weiss beim Arduino Zeug mit dem millis() besetzt. Das wird 
IRMP für Arduino aber wissen. Lass also die Defintionen drin, damit IRMP 
das Setup hinbekommt.

Stefan ⛄ F. schrieb:
> Das steht in einer Header Datei vom verwendete Arduino Core.

Schönen Dank auch. So eine Hürde hätte ich ja nicht erwartet. Was soll 
das wohl?
Denke bitte dran, den Tiny auf 8Mhz zu fusen, also die CKDIV/8 Fuse zu 
löschen. Der IRQ für IRMP feuert pro Sekunde 15000 mal, profitiert also 
von den 8MHz Tiny Takt.

[Lukas G. (luke21)]

Matthias S. schrieb:
> Normalerweise macht man das in der irmpconfig.h

Hab das jetzt gemacht:

 #if defined (ATMEL_AVR) || defined (__AVR_XMEGA__)                      // use PB6 as IR input on AVR
#  define IRMP_PORT_LETTER                      PB4
#  define IRMP_BIT_NUMBER                       6

Und Takt 8MHz eingestellt, hat wieder nichts gebracht

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Lukas G. schrieb:
> #  define IRMP_PORT_LETTER                      PB4
> #  define IRMP_BIT_NUMBER                       6

Du bist ja ein Spassvogel. Als Port Letter sollte da nur ein B stehen 
und Port B6 gibt es beim Tiny gar nicht, denn der hat nur Port B0 bis 
PortB4 (PortB5 ist der Reset pin und ein Sonderfall.
Stell das mal auf die richtigen Sachen um - also z.B. auf 
IRMP_BIT_NUMBER 4.

[Gerald B. (gerald_b)]

Hast du den Tiny richtig gefused und nicht bloß dein Compilat da 
reingespielt? Die Fuse für den berüchtigten 1:8 Teiler gibts auch beim 
Tiny. Wenn der auf Werkseinstellung mit 1 statt 8 MHz läuft, 
funktionieren deine Timings für IR nicht.

[Stefan F. (Gast)]

Matthias S. schrieb:
> So eine Hürde hätte ich ja nicht erwartet. Was soll
> das wohl?

Das ist keine Hürde, sondern gibt dem Hersteller eines Boardes die 
Möglichkeit, die externen Pins fortlaufend durch zu nummerieren. Das ist 
halt Arduino Standard.

[Schlaumaier (Gast)]

Hab ich schon erwähnt das ich Libs hasse, die den Port in der Lib selbst 
haben, und nicht in der INI bzw. den Aufruf.

Würde so nebenbei die Libs besser und den Code viel kürzer machen.

[Lukas G. (luke21)]

Gerald B. schrieb:
> Hast du den Tiny richtig gefused und nicht bloß dein Compilat da
> reingespielt?

Reicht es aus, in der Arduino IDE die Clockspeed auf 8MHz zu setzen oder 
muss man da wieder irgendwo was separat umstellen?

[Gerald B. (gerald_b)]

Diese Einstellung der Arduino IDE ist mir neu, ich habe das über eXtreme 
Burner und einen USBasp gemacht. eXtrme Burner ist wie ein Hex Editor 
aufgebaut und hat einen Reiter für Flash, einen fürs EEPROM und einen 
für die Fuses.
Keine Ahnung, wie man in der IDE die dort eingestellten Werte überträgt. 
Versuch's man mit dem Button "Burn Bootloader". Bei den Megas werden ja 
neben dem Bootloader so auch die Fuses gesetzt.

[Stefan F. (Gast)]

Lukas G. schrieb:
> Reicht es aus, in der Arduino IDE die Clockspeed auf 8MHz zu setzen oder
> muss man da wieder irgendwo was separat umstellen?

Nein, dort musst du einstellen, mit welcher Frequenz dein 
Mikrocontroller wirklich getaktet wird. Es verändert aber nicht dessen 
Taktfrequenz.

[Schlaumaier (Gast)]

Ich habe bei der IDE mit diverses Chips bei 8 Mhz Einstellung Probleme.
Wenn ich den auf 1 mhz stelle rennt der wie eine 1.

@To

Lade dir die Atiny-85 Libs nach. Stelle dann deinen Chip ein, Stelle 
danach dein USBasp als Programmierer ein.

Klicke danach im Menü auf "Hochladen mit Progammer" NICHT Hochladen 
anklicken !!!

Dann sollte das Prg. problemlos auf die Atiny's geladen werden.

Jedenfalls mache ich das so.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Schlaumaier schrieb:
> Ich habe bei der IDE mit diverses Chips bei 8 Mhz Einstellung Probleme.
> Wenn ich den auf 1 mhz stelle rennt der wie eine 1.

und quatscht mal wieder gerührten Blödsinn. Ein Uno läuft sogar mit 
16MHz und kann auch aus der IDE programmiert werden.

[Schlaumaier (Gast)]

Matthias S. schrieb:
> und quatscht mal wieder gerührten Blödsinn. Ein Uno läuft sogar mit
> 16MHz und kann auch aus der IDE programmiert werden.

Ich habe außer Blinki NIE was auf einen UNO aufgespielt.

Meine Lieblinge sind Nanos-Clones aus China für ca. 1.50 Euro das Stück 
mit gelötete Pin-Leisten. Und bei den habe ich halt das Problem.

Da die Hektik aber mehr Strom frisst, reicht mir 1 Mhz völlig aus. Wenn 
man ergo Probleme hat mit den Teil dann einfach mal ein Gang runter 
schalten.

Und damit das auch klar ist. Die Problem fangen schon beim Hochladen an. 
Die IDE bricht nämlich mit einen Fehler ab wenn ich meine Nanos mit 8 
MHZ Einstellung füttere. Bei 1 MHZ klappt das alles prima.

Und das sind Erfahrungswerte. Keine Theoretischer Mist, von "kann er , 
sollte klappen".

Und da ich mit den Nanos keine Bitcoins schürfe, bin ich so zufrieden.

[Stefan F. (Gast)]

Schlaumaier schrieb:
> Und damit das auch klar ist. Die Problem fangen schon beim Hochladen an.
> Die IDE bricht nämlich mit einen Fehler ab wenn ich meine Nanos mit 8
> MHZ Einstellung füttere. Bei 1 MHZ klappt das alles prima.

Irgendwas läuft da bei dir grob falsch. Ich hatte das Problem noch nie 
und ich wüsste auch nicht, welche Probleme dabei auftreten könnten, 
außer zu lange Kabel.

20cm sind üblich, 30cm sind aber noch OK.

[Joachim B. (jar)]

Stefan ⛄ F. schrieb:
> ich wüsste auch nicht, welche Probleme dabei auftreten könnten,
> außer zu lange Kabel.

auch Wusb oder USB/Ethernet Server ohne langes Kabel können Probleme 
machen
Ich musste alle meine nano mit einem modifizierten Optiboot 
programmieren, 115k schaffen alle nicht mit den genannten Verbindungen, 
da muss das Kabel nicht mal lang sein!

38.4/57.6 k war OK

[EAF (Gast)]

Gerald B. schrieb:
> Versuch's man mit dem Button "Burn Bootloader". Bei den Megas werden ja
> neben dem Bootloader so auch die Fuses gesetzt.

Richtig!
So geht es.

[EAF (Gast)]

Joachim B. schrieb:
> Ich musste alle meine nano mit einem modifizierten Optiboot
> programmieren, 115k schaffen alle nicht mit den genannten Verbindungen,
> da muss das Kabel nicht mal lang sein!
Irrational!

Was hat die Baudrate mit der Länge des USB Kabels zu tun?
Antwort: Nichts!

[Stefan F. (Gast)]

Bitte aufwachen! Es geht um die Taktfrequenz des AVR und sein ISP 
Interface.

[EAF (Gast)]

Stefan ⛄ F. schrieb:
> Bitte aufwachen! Es geht um die Taktfrequenz des AVR und sein ISP
> Interface.

Je selbstsicherer du tust, desto weniger hast du kapiert.

[Schlaumaier (Gast)]

Re: IR Empfänger mit Attiny85/45 funktioniert nie
von Lukas G. (luke21)   13.12.2021 17:05
Angehängte Dateien:
    preview image for Screenshot__1_.png


Es geht um die Einstellung auf diesen Foto.  !!!!

DA muss ich immer 1 MHZ einstellen.

Da der serial-Monitor langsam seien soll, habe ich den IM CODE auf 
19.200 eingestellt. Dann kann ich i.d.R. locker mitlesen.

Was die Kabellänge angeht. Es ist ein gutes Kabel und ca. 1 m lang. 
Stromversorgung durch eine externe aktiven HUB.

[W.S. (Gast)]

Lukas G. schrieb:
> Ich hab dafür alle Methoden probiert, die im Internet standen, sprich
> verschieden Libraries für Attiny installiert, verschiedene
> Taktfrequenzen, verschiedene Pinbelegungen, verschiedene Spannungslevel
> usw.

Dies ist mal wieder ein Beitrag, bei dem mir recht unfreundlich zumute 
wird. Anstatt ein wenig zu lesen, dann zu verstehen, wie das IR-Zeugs 
funktioniert und dann sein eigenes Zeugs zu konstruieren, wird hier 
jegliche Sachkenntnis peinlichst vermieden und stattdessen "alle 
Methoden, die im Internet standen" durchprobiert.

Tja, dir kann ich nur sagen, daß du zu allererst versuchen solltest, ein 
Pin deines µC so als Eingang zu konfiurieren, daß du es vom Programm her 
abfragen kannst und obendrein einen Interrupt auf beide Flanken 
bekommst. Dann überlege dir irgend ein sinnvolles Kommandosystem oder 
benutze eines der bekannten Systeme wie das von Philips, NEC oder so und 
schreibe danach deine ISR selber. So wie ich das sehe, benötigst du dazu 
noch einen Timer, mit dem du die Zeit seit dem letzten Zustandswechsel 
deines Empfangssignales messen kannst.

Wenn du das hingekriegt hast, können wir weiter sehen.

W.S.

[Schlaumaier (Gast)]

Kleiner Hinweis am Rande :;)

Ich habe mal wegen einer IR-Diode (Sender) 3 Std. nach den Fehler 
gesucht.
Bis ich festgestellt habe, das die Chinesen die Diode falsch auf die 
Mini-Platinchen gelötet haben und die Pin-Beschriftung nicht mit den 
Beinchen der Diode übereinstimmte.

Da ich sowas immer im 10er Pack bestellt habe, habe ich ne andere Diode 
angeschlossen (vorher geprüft) und die funktionierte 1a. Nach weiterer 
Prüfung habe ich festgestellt das von den 10er Pack 3 falsch angelötet 
waren.

Also es wäre keine schlechte Idee sich mal das Datenblatt der Diode 
anzusehen. Egal ob Sender o. Empfänger ;)

Ach und halte mal dein Handy an die Diode wenn sie SENDEN soll. Dann 
muss da ein roter flackernder Punkt zu sehen sein. !!  Wenn du den Punkt 
siehst, aber nix passiert dann sendest du den falschen Code.

Dann lädst du einfach ein fertiges Prg. IR-Erkennungsprogramm in den 
Chip. Baust die passende EMPFÄNGER-Diode (38 k in den Fall) dran (selber 
PIN) und löst die ECHTE Fernbedienung aus. Dann bekommst du MEIST das 
Protokoll + richtigen Code angezeigt.

Viel Glück.

[Joachim B. (jar)]

EAF schrieb:
> Was hat die Baudrate mit der Länge des USB Kabels zu tun?
> Antwort: Nichts!

du verstehst es nicht, kein Problem.

Baudrate <-> Takt <-> Bootloadereinstellung (Optiboot) <-> Wusb steht 
alles in einer Beziehung

Das darfst du gerne bestreiten!

[EAF (Gast)]

Joachim B. schrieb:
> viel Unsinn

Das Problem des TO hat nicht mit
1. Bootloader
2. WUSB
3. Kabellängen
4. Baudrate
5. Nanos
zu tun.

Da bleibt dann die Frage "Wer?" hier irgendwas nicht versteht schon gar 
nicht mehr offen.

Oder willst du diesen Thread auch wieder mit deinem Sermon kapern?



Lukas G. schrieb:
> Reicht es aus, in der Arduino IDE die Clockspeed auf 8MHz zu setzen oder
> muss man da wieder irgendwo was separat umstellen?
Den Clock Prescaler kann man im Programm umstellen.
Also per Fuse, oder im Programm.

[Joachim B. (jar)]

EAF schrieb:
> Das Problem des TO hat nicht mit

habe ich auch nicht behauptet, nur das dir Leseverständnis fehlt!

Stefan ⛄ F. schrieb:
> ich wüsste auch nicht, welche Probleme dabei auftreten könnten,
> außer zu lange Kabel.

selbst mit kurzen Kabeln kann es Probleme geben, was ich beweisen kann!

Diskutiere nie mit ........