Seite 292 von 670

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mi 3. Jan 2018, 23:37
von Sir_Death
Ja, da bin ich grundsätzlich bei dir.
Aber: Was ist richtig?
Das ist bei Hilfsorganisationen und hier im Forum genau das selbe Problem. Was ist der Wissensstand des zu Unterweisenden?

Jeder versteht sehr genau eine exakte Anweisung: z.B.: Nur ein Kabel am Moppel, nur ein Gerät an dem Kabel.
Sowohl der Laie als auch der Profi werden eventuell fragen: Warum?
Und hier liegt die meiner Meinung nach größte Verantwortung des Antwortenden! - Auf dem passenden Verständnis-Niveau zu Antworten.
Eine technisch perfekte Erklärung ist für den Profi sonnenklar. Der Laie ist nach dem ersten Halbsatz ausgestiegen, und macht wie er will (und damit potentiell falsch).
Eine für den Laien vereinfachte Erklärung schüttelt der Profi nur den Kopf und macht wie er will (und damit potentiell falsch).

Nachdem hier wie dort extrem unterschiedliche Wissensstände zu verschiedenen technischen Dingen vorhanden sind - und vor allem auch viele die Postings lesen, ohne dass der Verfasser des Postings den Wissensstand kennt, wäre eigentlich (und da muss ich mich selbst genauso an der Nase nehmen) die perfekte Antwort so aufgebaut:
-) Vereinfachte Antwort - als Einleitung (und für den Laien), danach
-) technisch korrekte Begründung warum.

Problematisch ist das halt dann, wenn jemand helfen will, der nur die vereinfachte Erklärung kennt - DIE ABER PERFEKT SEIN KÖNNTE!
Derjenige kann dann natürlich keine Nachfolgende technisch korrekte Begründung abgeben. Da wäre es aber von uns allen nett, wenn wir denjenigen, der das dann zu erklären versucht (und vielleicht auch nur 80% Verstanden hat) nicht in der Luft zerreißen, sondern Fehler im freundlichen Ton korrigieren.

Auf weiteres gutes Miteinander! - Danke.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Do 4. Jan 2018, 02:16
von ferdimh
Da wäre es aber von uns allen nett, wenn wir denjenigen, der das dann zu erklären versucht (und vielleicht auch nur 80% Verstanden hat) nicht in der Luft zerreißen, sondern Fehler im freundlichen Ton korrigieren.
<rant intensity=200%>
Ich habe kein Problem damit, im freundlichen Ton zu korrigieren, wenn ich nicht im ersten Satz als Idiot beschimpft und im zweiten Satz auf die höhere Stellung des Schimpfenden mir gegenüber hingewiesen werde. Dann is halt vorbei. Und das kommt leider gerade bei offensichtlich schwachsinnigen Erklärungen ("Wenn die Kabeltrommel aufgerollt ist, hat sie einen hohen induktiven Widerstand und dann entsteht da ein Blindstrom und der macht dass die Trommel abbrennt").
Man darf keine Ahnung haben. Man darf auch falsch liegen. Aber man sollte zumindest bereit sein, seinem Gegenüber zuzuhören und Argumente zu betrachten ("die VDE0815 sagt aber" und "ich habe zwei Balken mehr als du" sind im Übrigen keine Argumente). Selbst wenn man am Ende Recht hat, hat man zumindest Wissen vermittelt, das vielleicht hängen bleibt.
</rant>
Sowohl der Laie als auch der Profi werden eventuell fragen: Warum?
Und hier liegt die meiner Meinung nach größte Verantwortung des Antwortenden! - Auf dem passenden Verständnis-Niveau zu Antworten.
Eine technisch perfekte Erklärung ist für den Profi sonnenklar. Der Laie ist nach dem ersten Halbsatz ausgestiegen, und macht wie er will (und damit potentiell falsch).
Der Trick ist hier, die Erklärung durch eine Demonstration zu ersetzen. Eine "einfache Erklärung" für den Laien darf halt nicht hoffensichtlich falsch sein, sie kann nur verkürzt oder vereinfacht sein. Sonst kommt der nächste, weist auf den fachlichen Fehler hin und die Erklärung ist zerstört.
Wenn du das tust dann RUMS oder FRITZEL merkt man sich, auch wenn man es nicht verstanden hat.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Do 4. Jan 2018, 08:15
von duese
Spinoff-Frage: ist Induktivität einer Kabeltrommel im aufgerollten Zustand größer als im abgewickelten?
Aufgewickelt haben wir eine Spule aber mit zwei Leitern in gegensätzlichem Wickelsinn.
Zusätzlich gibt es vielleicht noch einen metallischem Spulenkern (wenn die Trommel nicht aus Kunststoff ist).

Ich steh da irgendwie auf dem Schlauch.
Die Frage hat nichts mit dem Grund für das Abbrennen aufgerollter Trommeln unter Belastung zu tun, brachte mich nur wieder drauf.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Do 4. Jan 2018, 08:35
von xoexlepox
Aufgewickelt haben wir eine Spule aber mit zwei Leitern in gegensätzlichem Wickelsinn.
Das müsste m.E. so etwas wie eine stromkompensierte Drossel ergeben -> Bei gegenphasigem Strom ist so gut wie keine Induktivität vorhanden, wohl aber für Strom, der gleichphasig da durch möchte. Nur sonderlich groß wird die Induktivität ohne Eisenkern wohl kaum werden.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Do 4. Jan 2018, 10:42
von ange12lo
Zur Info. Die Matratze war jetzt drei Tage in einem kleinen Raum mit einem Starken Entfeuchter (Krüger Secomat). Nun ist sie schon einiges leichter aber noch nicht 100% trocken. Habe sie jetzt senkrecht stehend in den trockenen und belüfteten Keller gestellt. Hoffe die wird jetzt die nächsten Wochen ganz trocknen.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Do 4. Jan 2018, 11:09
von ferdimh
Für gegenphasigen Strom (also im Normalbetrieb) wird da nicht viel passieren. Aber 50-100 Windungen auf so einem Spulenkörper kommen auch schon ohne Eisenkern nahe an 1mH ran, würde ich schätzen - das wären bei 50Hz immerhin 0,3jΩ.
Zur Entstörung ließe sich so ein Gebilde wahrscheinlich sogar einsetzen.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Fr 5. Jan 2018, 11:06
von Desinfector
ange12lo hat geschrieben:Zur Info. Die Matratze war jetzt drei Tage in einem kleinen Raum mit einem Starken Entfeuchter (Krüger Secomat). Nun ist sie schon einiges leichter aber noch nicht 100% trocken. Habe sie jetzt senkrecht stehend in den trockenen und belüfteten Keller gestellt. Hoffe die wird jetzt die nächsten Wochen ganz trocknen.
zumindest im Sommer kann man solche Trocknungsgeschichten auch ins Auto verlagern.
links und rechts die Scheiben nen Schlitz offen stehen lassen.

natürlich nur wenn das Auto einigermassen sicher steht
und da nicht sofort nach verlassen einer am selbigen herumspökelt

Re: Kurze Frage -> schnelle Antwort

Verfasst: Sa 6. Jan 2018, 00:34
von teff
sysconsol hat geschrieben:
gibts Erfahrungen, wie haltbar normale USB-Platten im Dauerbetrieb sind? Wäre da evtl. eine "normale" Platte im USB-Gehäuse besser?
Eine USB-Platte ist eine "normale" (= IDE oder SATA)-Platte mit einem Umsetzer USB zu IDE oder SATA in einem Gehäuse.
Wichtiger wäre die Temperatur (manche Platten kommen recht schnell über 40°C).
Und eventuell der Plattentyp.
Es gibt Festplatten, die sind darauf ausgelegt, dauerhaft zu laufen (der Plattenstapel dreht immer).
Und es gibt Platten, die kann man durchaus oft ein- und ausschalten.
Ich würde mir da weniger Gedanken drum machen.
Schau nach, was sein Server oder NAS kann.
Und sichere deine Daten!
Prima, das muss ich dann mal falsch aufgeschnappt haben. Habe hier zwei USB2-Platten die momentan "über" sind (hab ich mal für kaputt gehalten. Ich guck mir die nochmal genauer an und messe mal die Temperaturen. Eine hat sogar ein Alugehäuse. Erstmal kopier ich nur Musik drauf, aber ne Art Backup-über-Netzwerk-Funktion wär natürlich auch irgendwie praktisch;)

Re: Kurze Frage -> schnelle Antwort

Verfasst: Sa 6. Jan 2018, 02:39
von ferdimh
Eine USB-Platte ist eine "normale" (= IDE oder SATA)-Platte mit einem Umsetzer USB zu IDE oder SATA in einem Gehäuse.
Ich habe mittlerweile eine Instanz 2,5"-Festplatte gesehen, die tatsächlich den USB-SATA-Wandler mit auf der Festplattenplatine hatte. Dort war ebendieser gegrillt, nach Lötarbeiten ließ sich die Platte noch per SATA auslesen. Eine gewisse Defektwahrscheinlichkeit besteht also schon, irgendwie sagen die Todesraten dieser USB-SATA-Wandler (und sonstiger USB-Geräte), dass es offensichtlich im Wesentlichen ein generelles USB-Haltbarkeitsproblem gibt.
Wenn du dir also nicht zutraust, eine solche Platte nachträglich zu SATAnisieren, wäre Platte+USB-Gehäuse wohl doch besser.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Sa 6. Jan 2018, 08:14
von radixdelta
Ich bekomme immer mal wieder USB-Platten auf den Tisch die nicht mehr wollen. Selten liegt es am Gehäuse, sondern meistens ist die Platte selbst hinüber und lässt sich mit etwas Glück häufig noch mit einem Rettungstool auslesen. Man Munkelt in den günstigen USB-Platten laufen B-Sortierungen die für Systemplatten nicht taugen würden. Da ich selbst noch nie eine USB-Platte defekt hatte nehme ich aber an das liegt auch einfach an der Handhabung, ich habe die niemals im Dauerlauf (Kühlung?) und nie bewegt geschweige denn herunter fallen lassen.

Wenn es sicherer sein soll besorgt man sich ein vernünftiges Gehäuse das entweder raid1 in der Hardware hat (mit 2 Platten verschiedener Hersteller) oder drei bis vier Platten aufnehmen kann die man per Software-Raid5 oder Raid1 verbindet. Hardware raid5 bedeutet bei Controller-Defekt leider große Probleme. Diese Gehäuse sind vernünftig Kühlbar, das halte ich für einen wichtigen Punkt.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Sa 6. Jan 2018, 12:16
von Bastelbruder
Ich habe hier zwei solcher Platten "Zinc" von Maxens, die sind aus der Serie wo irgendein Zähler das Teil unbeabsichtigt gebrickt hat wenn man nicht vorher die Firmware upgedatet hat. Die waren beim Hersteller zwecks Erneuerung des Fells, haben einen entsprechenden Aufkleber und hatten den steilen ersten Teil der Badewannenkurve bereits hinter sich. Das war für mich die Unbedenklichkeitsbescheinigung.

Die Gehäuse habe ich allerdings mit Polierleinen noch etwas geglättet, im Ursprungszustand war die Oberfläche mit der einer Diamant-Nagelfeile vergleichbar.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Sa 6. Jan 2018, 12:31
von zauberkopf
ALso wegen den USB-Platten :
Was ganz wichtig ist, für Dauerbetrieb, und das gilt für jede Festplatte : DAS SIE GUT GEKÜHLT IST !
Je wärmer sie im Betrieb wird, desto höher die Ausfallrate.

Das USB-Platten, eine höhere Ausfallwahrscheinlichkeit , als Systemplatten haben, konnte ich noch vor 2 Jahren, als ich u.A. auch noch als Systemadmin nebenbei gearbeitet habe, nicht feststellen.
Okay, die Platten hatte alle ein Alu-Gehäuse.
Hier arbeitet eine USB-Platte 24h 365t seit ca 5 Jahren ohne murren. Sie steht aber auch hochkant.

Kleiner Tip : Einen 12V Lüfter mit 5V betrieben, und ein Gehäuse geklatscht, senkt die Betriebstemperatur merklich. Und man hört nix !
Oder anders gesagt, eine Passive Kühlung ein ganz klein wenig aktiv gemacht.. und es ist viel gewonnen !

Re: Kurze Frage -> schnelle Antwort

Verfasst: Sa 6. Jan 2018, 14:23
von video6
Bei uns im Aldi gib’s grad 2,5 Zoll Thosiba 1TB für 40€ USB3.0

Re: Kurze Frage -> schnelle Antwort

Verfasst: Sa 6. Jan 2018, 19:38
von Sir_Death
wegen der USB-Festplattenkühlung:

Wer von WD "MyBooks" zuhause hat, klebe einfach vier Gerätefüßchen unten drunter.

Die Gehäuse sind unten, hinten und oben gelocht, aber mangels Füße stehen sie direkt auf dem Tisch und der eigentlich vorhandenen Kamin tut nix.

Ohne Füße im Dauerschreiben (Storage-Backup, ca. 5 Stunden) laut Festplattentool 63°C
Mit Füßen: 39°C

Re: Kurze Frage -> schnelle Antwort

Verfasst: Sa 6. Jan 2018, 20:39
von andreas6
Nochmal Thema AA-Akkus und mechanische Abmessungen: Bei Ikea habe ich heute AA-Akkus namens Ladda gefunden, die es vorgeladen in zwei Kapazitäten gibt, 1000 und 2500mAh. Beide schienen bei der Vermessung im Laden mit dem Spielzeugzollstock aus der Hosentasche recht geringe Durchmesser zu haben. Also wurden kurzerhand drei 4er Packs der kleineren Kapazität mitgenommen und zu Hause vermessen. Der Schein trügte nicht, der Messschieber zeigte um 14,1mm Durchmesser an. Praxistest im uralten HF12/5, was zehn dieser Zellen nebeneinander in 142mm braucht: Passt und hat noch etwas Luft! Wenn es also eng zugeht, ist diese Zelle in jedem Fall einsetzbar. Auf der Verpackung ist Japan als Herstellungsland ausgewiesen.

MfG. Andreas

Re: Kurze Frage -> schnelle Antwort

Verfasst: Sa 6. Jan 2018, 23:33
von nox
die ladda-Zellen sind auch reell beschriftet, mein BC700 gibt etwa 2400 für die grossen AA an, die kleinen AA liegen so bei 1300mAh

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 01:58
von Andreas_P
Ich brauche mal eure Hilfe.
Für ein kleines Projekt möchte ich auf einen Attiny85 eine Datei brennen.
Dazu muss erst aus einen Marke File eine HEX Datei erstellt werden.
Bei mir erscheint dann folgende Fehlermeldung.

Bild->zoom

Ich habe es mit AVR GCC versucht, was mache ich falsch?

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 02:27
von Chefbastler
Da scheint eine Haeder Datei zu Fehlen oder Flasch benannt zu sein.

Ist die Header Datei wird in den Souce Files entsprechend eingebunden. #include "io.h"

Ansonnsten kast du dafür auch AVR Studio mit AVR GCC benutzen. Ist evtl. übersichtlicher als Comandline und man kann mit Doppleklick auf die Fehlermeldung auch gelich in die Entsprechnde Zeile geschikt werden. ;)

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 10:11
von Fritzler
Flash brennt man nicht...

Wies aussieht haste nur den avrgcc selber installiert und nicht die passenden libs/header.
Aso: sudo apt-get install avr-libc
Die binutils-avr haste vllt auch vergessen.

@Chefbastler:
Header aus der lib includiert man immer mit <...>

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 16:40
von Andreas_P
Ich habe mal das fehlende Paket nachinstalliert.
Und dann noch mal versucht mit Make HEX die Datei erstellen zu lassen.

Als Fehlermeldung sagt er dies.

Bild->zoom

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 16:46
von Chefbastler
Fritzler hat geschrieben:
@Chefbastler:
Header aus der lib includiert man immer mit <...>
Jo, war etwas späht geworden zum klar Denken... :oops:

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 17:13
von Fritzler
Also das ist jetzt _wirklich_ merkwürdig.
Die page.h gehört ja zum selben Paket.

Wobei meine uralte avr libc Version in der io.h Diese Datei nicht includiert und diese auch nicht hat.

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 17:25
von Bauteiltöter
Ja jetzt wird es komisch.

Welches Projekt versuchst du denn da gerade zu bauen? Kannst du uns einen Link darauf setzen?

Auch in meiner avr-libc kommt ein asm/page.h nicht vor, es gibt gar keinen asm-Ordner.
Allerdings finde ich includes von <asm/page.h> in Teilen des Linux-Headers, z.B. in include/asm-generic/io.h das in Zeile 14 ein Include mit exakt dem gleichen Kommentar macht.
Dein Screenshot zeigt aber auch, dass dein Compiler die io.h schon aus einem ./avr -Ordner holt... hast du da vielleicht aus versehen etwas kopiert oder so?

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 17:55
von Andreas_P

Was Schwimmt denn da im Farbeimer ?

Verfasst: So 7. Jan 2018, 18:01
von Wurstblinker
Habe hier nen Eimer Wandfarbe die sich scheinbar abgesetzt hat.

Unten ein (block) weiße Farbe, oben ca 2 cm...... Wasser?

In der klaren Flüssigkeit schwimmt eine ca 5 mm dicke Schicht grau brauner Glibber
(Sieht irgendwie biologisch aus)

Foto kann ich leider nicht mehr machen ,
da durch das Rumstochern in dem noch weichen (Farbblock) das Wasser oben milchig wurde
und man nurnoch weiße Flüssigkeit sieht.

Mein erster Impuls war unterrühren, der
2. den Glibber abkippen und mit Wasser verdünnen

Was tun ?

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 18:07
von Chemnitzsurfer
Hatte schon mehrmals Alpina Wandfarbe die nach einen halben Jahr offener Eimer schimmlig war...
(Seltsamerweise nicht bei der Wandfarbe für 5,99€ aus dem Baumarkt :roll: )

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 18:08
von Bauteiltöter
Hm baut bei mir ohne Probleme.

Poste mal bitte den Inhalt von /usr/lib/avr/include/avr/io.h hier als Anhang.

Ich hab dir das hexfile mal angehängt (umbenennen main.pdf -> main.hex) , trotzdem sollte man das ja bei dir hinbekommen.

Re: Was Schwimmt denn da im Farbeimer ?

Verfasst: So 7. Jan 2018, 18:19
von RMK
Wurstblinker hat geschrieben:Habe hier nen Eimer Wandfarbe die sich scheinbar abgesetzt hat.
Was tun ?
ich hab den Glibber untergerührt und dann einen Raum damit gestrichen.
keine gute Idee. das hat zwei Wochen gedauert bis es nicht mehr modrig gerochen hat,
da war die Farbe schon längst trocken. :-(

schmeiss es weg....

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 18:20
von Wurstblinker
Chemnitzsurfer hat geschrieben:Hatte schon mehrmals Alpina Wandfarbe die nach einen halben Jahr offener Eimer schimmlig war...
(Seltsamerweise nicht bei der Wandfarbe für 5,99€ aus dem Baumarkt :roll: )
Schimmel hatte ich auch schon , war aber klar Erkennbar.

Nur hier bin ich nicht sicher ob das zur Farbe gehört, oder sich gebildet hat.
Ist ein Eimer von Feinkost Albrecht der heute zum ersten mal geöffnet wurde.

Die Frage ist halt , heute noch an die Wand oder morgen zum Farbhändler

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 18:29
von Chemnitzsurfer
Wie lange stand die Farbe schon herum?
Meist geben die Hersteller 2 Jahre Lagerfähigkeit an. Wenn man Pech hat, steht die Plörrer halt schonmal 1 jahr im Hochregallager
https://alpina-farben.de/artikel/wandfa ... en-lagern/
Farbeimer müssen nicht sofort nach dem Streichen entsorgt werden. Lagern Sie die Farbreste der Wandfarbe immer kühl und frostfrei. Ungeöffnete Farbeimer halten so mindestens 24 Monate. Ist die Farbe bereits angebrochen, sollte diese luftdicht im Farbeimer verschlossen bzw. zeitnah verbraucht werden. Gut verschlossene Innenfarbe hält angebrochen noch ca. 12 Monate.

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 18:56
von Andreas_P
Bauteiltöter hier der Inhalt meiner io.h.

Code: Alles auswählen

/* Copyright (c) 2002,2003,2005,2006,2007 Marek Michalkiewicz, Joerg Wunsch
   Copyright (c) 2007 Eric B. Weddington
   All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions are met:

   * Redistributions of source code must retain the above copyright
     notice, this list of conditions and the following disclaimer.

   * Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in
     the documentation and/or other materials provided with the
     distribution.

   * Neither the name of the copyright holders nor the names of
     contributors may be used to endorse or promote products derived
     from this software without specific prior written permission.

  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
  LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
  INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
  CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  POSSIBILITY OF SUCH DAMAGE. */

/* $Id$ */

/** \file */
/** \defgroup avr_io <avr/io.h>: AVR device-specific IO definitions
    \code #include <avr/io.h> \endcode

    This header file includes the apropriate IO definitions for the
    device that has been specified by the <tt>-mmcu=</tt> compiler
    command-line switch.  This is done by diverting to the appropriate
    file <tt><avr/io</tt><em>XXXX</em><tt>.h></tt> which should
    never be included directly.  Some register names common to all
    AVR devices are defined directly within <tt><avr/common.h></tt>,
    which is included in <tt><avr/io.h></tt>,
    but most of the details come from the respective include file.

    Note that this file always includes the following files:
    \code 
    #include <avr/sfr_defs.h>
    #include <avr/portpins.h>
    #include <avr/common.h>
    #include <avr/version.h>
    \endcode
    See \ref avr_sfr for more details about that header file.

    Included are definitions of the IO register set and their
    respective bit values as specified in the Atmel documentation.
    Note that inconsistencies in naming conventions,
    so even identical functions sometimes get different names on
    different devices.

    Also included are the specific names useable for interrupt
    function definitions as documented
    \ref avr_signames "here".

    Finally, the following macros are defined:

    - \b RAMEND
    <br>
    The last on-chip RAM address.
    <br>
    - \b XRAMEND
    <br>
    The last possible RAM location that is addressable. This is equal to 
    RAMEND for devices that do not allow for external RAM. For devices 
    that allow external RAM, this will be larger than RAMEND.
    <br>
    - \b E2END
    <br>
    The last EEPROM address.
    <br>
    - \b FLASHEND
    <br>
    The last byte address in the Flash program space.
    <br>
    - \b SPM_PAGESIZE
    <br>
    For devices with bootloader support, the flash pagesize
    (in bytes) to be used for the \c SPM instruction. 
    - \b E2PAGESIZE
    <br>
    The size of the EEPROM page.
    
*/

#ifndef _AVR_IO_H_
#define _AVR_IO_H_

#include <avr/sfr_defs.h>

#if defined (__AVR_AT94K__)
#  include <avr/ioat94k.h>
#elif defined (__AVR_AT43USB320__)
#  include <avr/io43u32x.h>
#elif defined (__AVR_AT43USB355__)
#  include <avr/io43u35x.h>
#elif defined (__AVR_AT76C711__)
#  include <avr/io76c711.h>
#elif defined (__AVR_AT86RF401__)
#  include <avr/io86r401.h>
#elif defined (__AVR_AT90PWM1__)
#  include <avr/io90pwm1.h>
#elif defined (__AVR_AT90PWM2__)
#  include <avr/io90pwmx.h>
#elif defined (__AVR_AT90PWM2B__)
#  include <avr/io90pwm2b.h>
#elif defined (__AVR_AT90PWM3__)
#  include <avr/io90pwmx.h>
#elif defined (__AVR_AT90PWM3B__)
#  include <avr/io90pwm3b.h>
#elif defined (__AVR_AT90PWM216__)
#  include <avr/io90pwm216.h>
#elif defined (__AVR_AT90PWM316__)
#  include <avr/io90pwm316.h>
#elif defined (__AVR_AT90PWM161__)
#  include <avr/io90pwm161.h>
#elif defined (__AVR_AT90PWM81__)
#  include <avr/io90pwm81.h>
#elif defined (__AVR_ATmega8U2__)
#  include <avr/iom8u2.h>
#elif defined (__AVR_ATmega16M1__)
#  include <avr/iom16m1.h>
#elif defined (__AVR_ATmega16U2__)
#  include <avr/iom16u2.h>
#elif defined (__AVR_ATmega16U4__)
#  include <avr/iom16u4.h>
#elif defined (__AVR_ATmega32C1__)
#  include <avr/iom32c1.h>
#elif defined (__AVR_ATmega32M1__)
#  include <avr/iom32m1.h>
#elif defined (__AVR_ATmega32U2__)
#  include <avr/iom32u2.h>
#elif defined (__AVR_ATmega32U4__)
#  include <avr/iom32u4.h>
#elif defined (__AVR_ATmega32U6__)
#  include <avr/iom32u6.h>
#elif defined (__AVR_ATmega64C1__)
#  include <avr/iom64c1.h>
#elif defined (__AVR_ATmega64M1__)
#  include <avr/iom64m1.h>
#elif defined (__AVR_ATmega128__)
#  include <avr/iom128.h>
#elif defined (__AVR_ATmega128A__)
#  include <avr/iom128a.h>
#elif defined (__AVR_ATmega1280__)
#  include <avr/iom1280.h>
#elif defined (__AVR_ATmega1281__)
#  include <avr/iom1281.h>
#elif defined (__AVR_ATmega1284__)
#  include <avr/iom1284.h>
#elif defined (__AVR_ATmega1284P__)
#  include <avr/iom1284p.h>
#elif defined (__AVR_ATmega128RFA1__)
#  include <avr/iom128rfa1.h>
#elif defined (__AVR_ATmega128RFR2__)
#  include <avr/iom128rfr2.h>
#elif defined (__AVR_ATmega1284RFR2__)
#  include <avr/iom1284rfr2.h>
#elif defined (__AVR_ATmega256RFR2__)
#  include <avr/iom256rfr2.h>
#elif defined (__AVR_ATmega2564RFR2__)
#  include <avr/iom2564rfr2.h>
#elif defined (__AVR_ATmega2560__)
#  include <avr/iom2560.h>
#elif defined (__AVR_ATmega2561__)
#  include <avr/iom2561.h>
#elif defined (__AVR_AT90CAN32__)
#  include <avr/iocan32.h>
#elif defined (__AVR_AT90CAN64__)
#  include <avr/iocan64.h>
#elif defined (__AVR_AT90CAN128__)
#  include <avr/iocan128.h>
#elif defined (__AVR_AT90USB82__)
#  include <avr/iousb82.h>
#elif defined (__AVR_AT90USB162__)
#  include <avr/iousb162.h>
#elif defined (__AVR_AT90USB646__)
#  include <avr/iousb646.h>
#elif defined (__AVR_AT90USB647__)
#  include <avr/iousb647.h>
#elif defined (__AVR_AT90USB1286__)
#  include <avr/iousb1286.h>
#elif defined (__AVR_AT90USB1287__)
#  include <avr/iousb1287.h>
#elif defined (__AVR_ATmega64RFR2__)
#  include <avr/iom64rfr2.h>
#elif defined (__AVR_ATmega644RFR2__)
#  include <avr/iom644rfr2.h>
#elif defined (__AVR_ATmega64__)
#  include <avr/iom64.h>
#elif defined (__AVR_ATmega64A__)
#  include <avr/iom64a.h>
#elif defined (__AVR_ATmega640__)
#  include <avr/iom640.h>
#elif defined (__AVR_ATmega644__) 
#  include <avr/iom644.h>
#elif (defined __AVR_ATmega644A__)
#include <avr/iom644a.h>
#elif defined (__AVR_ATmega644P__)
#  include <avr/iom644p.h>
#elif defined (__AVR_ATmega644PA__)
#  include <avr/iom644pa.h>
#elif defined (__AVR_ATmega645__)
#  include <avr/iom645.h>
#elif (defined __AVR_ATmega645A__)
#include <avr/iom645a.h>
#elif (defined __AVR_ATmega645P__)
#include <avr/iom645p.h>
#elif defined (__AVR_ATmega6450__)
#  include <avr/iom6450.h>
#elif (defined __AVR_ATmega6450A__)
#include <avr/iom6450a.h>
#elif (defined __AVR_ATmega6450P__)
#include <avr/iom6450p.h>
#elif defined (__AVR_ATmega649__)
#  include <avr/iom649.h>
#elif (defined __AVR_ATmega649A__)
#include <avr/iom649a.h>
#elif defined (__AVR_ATmega6490__)
#  include <avr/iom6490.h>
#elif (defined __AVR_ATmega6490A__)
#include <avr/iom6490a.h>
#elif (defined __AVR_ATmega6490P__)
#include <avr/iom6490p.h>
#elif defined (__AVR_ATmega649P__)
#  include <avr/iom649p.h>
#elif defined (__AVR_ATmega64HVE__)
#  include <avr/iom64hve.h>
#elif defined (__AVR_ATmega64HVE2__)
#  include <avr/iom64hve2.h>
#elif defined (__AVR_ATmega103__)
#  include <avr/iom103.h>
#elif defined (__AVR_ATmega32__)
#  include <avr/iom32.h>
#elif defined (__AVR_ATmega32A__)
#  include <avr/iom32a.h>
#elif defined (__AVR_ATmega323__)
#  include <avr/iom323.h>
#elif defined (__AVR_ATmega324P__)
#  include <avr/iom324p.h>
#elif (defined __AVR_ATmega324A__)
#include <avr/iom324a.h>
#elif defined (__AVR_ATmega324PA__)
#  include <avr/iom324pa.h>
#elif defined (__AVR_ATmega325__)
#  include <avr/iom325.h>
#elif (defined __AVR_ATmega325A__)
#include <avr/iom325a.h>
#elif defined (__AVR_ATmega325P__)
#  include <avr/iom325p.h>
#elif defined (__AVR_ATmega325PA__)
#  include <avr/iom325pa.h>  
#elif defined (__AVR_ATmega3250__) 
#  include <avr/iom3250.h>
#elif (defined __AVR_ATmega3250A__)
#include <avr/iom3250a.h>
#elif defined (__AVR_ATmega3250P__)
#  include <avr/iom3250p.h>
#elif defined (__AVR_ATmega3250PA__)
#  include <avr/iom3250pa.h>  
#elif defined (__AVR_ATmega328P__)
#  include <avr/iom328p.h>
#elif (defined __AVR_ATmega328__)
#include <avr/iom328.h>
#elif defined (__AVR_ATmega329__)
#  include <avr/iom329.h>
#elif (defined __AVR_ATmega329A__)
#include <avr/iom329a.h>
#elif defined (__AVR_ATmega329P__) 
#  include <avr/iom329p.h>
#elif (defined __AVR_ATmega329PA__)
#include <avr/iom329pa.h>
#elif (defined __AVR_ATmega3290PA__)
#include <avr/iom3290pa.h>
#elif defined (__AVR_ATmega3290__)
#  include <avr/iom3290.h>
#elif (defined __AVR_ATmega3290A__)
#include <avr/iom3290a.h>
#elif defined (__AVR_ATmega3290P__)
#  include <avr/iom3290.h>
#elif defined (__AVR_ATmega32HVB__)
#  include <avr/iom32hvb.h>
#elif defined (__AVR_ATmega32HVBREVB__)
#  include <avr/iom32hvbrevb.h>
#elif defined (__AVR_ATmega406__)
#  include <avr/iom406.h>
#elif defined (__AVR_ATmega16__)
#  include <avr/iom16.h>
#elif defined (__AVR_ATmega16A__)
#  include <avr/iom16a.h>
#elif defined (__AVR_ATmega161__)
#  include <avr/iom161.h>
#elif defined (__AVR_ATmega162__)
#  include <avr/iom162.h>
#elif defined (__AVR_ATmega163__)
#  include <avr/iom163.h>
#elif defined (__AVR_ATmega164P__)
#  include <avr/iom164p.h>
#elif (defined __AVR_ATmega164A__)
#include <avr/iom164a.h>
#elif defined (__AVR_ATmega164PA__)
#  include <avr/iom164pa.h>
#elif defined (__AVR_ATmega165__)
#  include <avr/iom165.h>
#elif (defined __AVR_ATmega165A__)
#include <avr/iom165a.h>
#elif defined (__AVR_ATmega165P__)
#  include <avr/iom165p.h>
#elif defined (__AVR_ATmega165PA__)
#  include <avr/iom165pa.h>
#elif defined (__AVR_ATmega168__)
#  include <avr/iom168.h>
#elif (defined __AVR_ATmega168A__)
#include <avr/iom168a.h>
#elif defined (__AVR_ATmega168P__)
#  include <avr/iom168p.h>
#elif defined (__AVR_ATmega168PA__)
#  include <avr/iom168pa.h>
#elif defined (__AVR_ATmega168PB__)
#  include <avr/iom168pb.h>
#elif defined (__AVR_ATmega169__)
#  include <avr/iom169.h>
#elif (defined __AVR_ATmega169A__)
#include <avr/iom169a.h>
#elif defined (__AVR_ATmega169P__)
#  include <avr/iom169p.h>
#elif defined (__AVR_ATmega169PA__)
#  include <avr/iom169pa.h>
#elif defined (__AVR_ATmega8HVA__)
#  include <avr/iom8hva.h>
#elif defined (__AVR_ATmega16HVA__)
#  include <avr/iom16hva.h>
#elif defined (__AVR_ATmega16HVA2__)
#  include <avr/iom16hva2.h>
#elif defined (__AVR_ATmega16HVB__)
#  include <avr/iom16hvb.h>
#elif defined (__AVR_ATmega16HVBREVB__)
#  include <avr/iom16hvbrevb.h>
#elif defined (__AVR_ATmega8__)
#  include <avr/iom8.h>
#elif defined (__AVR_ATmega8A__)
#  include <avr/iom8a.h>
#elif (defined __AVR_ATmega48A__)
#  include <avr/iom48a.h>
#elif defined (__AVR_ATmega48__)
#  include <avr/iom48.h>
#elif defined (__AVR_ATmega48PA__)
#  include <avr/iom48pa.h>
#elif defined (__AVR_ATmega48PB__)
#  include <avr/iom48pb.h>
#elif defined (__AVR_ATmega48P__)
#  include <avr/iom48p.h>
#elif defined (__AVR_ATmega88__)
#  include <avr/iom88.h>
#elif (defined __AVR_ATmega88A__)
#  include <avr/iom88a.h>
#elif defined (__AVR_ATmega88P__)
#  include <avr/iom88p.h>
#elif defined (__AVR_ATmega88PA__)
#  include <avr/iom88pa.h>
#elif defined (__AVR_ATmega88PB__)
#  include <avr/iom88pb.h>
#elif defined (__AVR_ATmega8515__)
#  include <avr/iom8515.h>
#elif defined (__AVR_ATmega8535__)
#  include <avr/iom8535.h>
#elif defined (__AVR_AT90S8535__)
#  include <avr/io8535.h>
#elif defined (__AVR_AT90C8534__)
#  include <avr/io8534.h>
#elif defined (__AVR_AT90S8515__)
#  include <avr/io8515.h>
#elif defined (__AVR_AT90S4434__)
#  include <avr/io4434.h>
#elif defined (__AVR_AT90S4433__)
#  include <avr/io4433.h>
#elif defined (__AVR_AT90S4414__)
#  include <avr/io4414.h>
#elif defined (__AVR_ATtiny22__)
#  include <avr/iotn22.h>
#elif defined (__AVR_ATtiny26__)
#  include <avr/iotn26.h>
#elif defined (__AVR_AT90S2343__)
#  include <avr/io2343.h>
#elif defined (__AVR_AT90S2333__)
#  include <avr/io2333.h>
#elif defined (__AVR_AT90S2323__)
#  include <avr/io2323.h>
#elif defined (__AVR_AT90S2313__)
#  include <avr/io2313.h>
#elif defined (__AVR_ATtiny4__)
#  include <avr/iotn4.h>
#elif defined (__AVR_ATtiny5__)
#  include <avr/iotn5.h>
#elif defined (__AVR_ATtiny9__)
#  include <avr/iotn9.h>
#elif defined (__AVR_ATtiny10__)
#  include <avr/iotn10.h>
#elif defined (__AVR_ATtiny20__)
#  include <avr/iotn20.h>
#elif defined (__AVR_ATtiny40__)
#  include <avr/iotn40.h>
#elif defined (__AVR_ATtiny2313__)
#  include <avr/iotn2313.h>
#elif defined (__AVR_ATtiny2313A__)
#  include <avr/iotn2313a.h>
#elif defined (__AVR_ATtiny13__)
#  include <avr/iotn13.h>
#elif defined (__AVR_ATtiny13A__)
#  include <avr/iotn13a.h>
#elif defined (__AVR_ATtiny25__)
#  include <avr/iotn25.h>
#elif defined (__AVR_ATtiny4313__)
#  include <avr/iotn4313.h>
#elif defined (__AVR_ATtiny45__)
#  include <avr/iotn45.h>
#elif defined (__AVR_ATtiny85__)
#  include <avr/iotn85.h>
#elif defined (__AVR_ATtiny24__)
#  include <avr/iotn24.h>
#elif defined (__AVR_ATtiny24A__)
#  include <avr/iotn24a.h>
#elif defined (__AVR_ATtiny44__)
#  include <avr/iotn44.h>
#elif defined (__AVR_ATtiny44A__)
#  include <avr/iotn44a.h>
#elif defined (__AVR_ATtiny441__)
#  include <avr/iotn441.h>
#elif defined (__AVR_ATtiny84__)
#  include <avr/iotn84.h>
#elif defined (__AVR_ATtiny84A__)
#  include <avr/iotn84a.h>  
#elif defined (__AVR_ATtiny841__)
#  include <avr/iotn841.h>
#elif defined (__AVR_ATtiny261__)
#  include <avr/iotn261.h>
#elif defined (__AVR_ATtiny261A__)
#  include <avr/iotn261a.h>
#elif defined (__AVR_ATtiny461__)
#  include <avr/iotn461.h>
#elif defined (__AVR_ATtiny461A__)
#  include <avr/iotn461a.h>
#elif defined (__AVR_ATtiny861__)
#  include <avr/iotn861.h>
#elif defined (__AVR_ATtiny861A__)
#  include <avr/iotn861a.h>
#elif defined (__AVR_ATtiny43U__)
#  include <avr/iotn43u.h>
#elif defined (__AVR_ATtiny48__)
#  include <avr/iotn48.h>
#elif defined (__AVR_ATtiny88__)
#  include <avr/iotn88.h>
#elif defined (__AVR_ATtiny828__)
#  include <avr/iotn828.h>
#elif defined (__AVR_ATtiny87__)
#  include <avr/iotn87.h>
#elif defined (__AVR_ATtiny167__)
#  include <avr/iotn167.h>
#elif defined (__AVR_ATtiny1634__)
#  include <avr/iotn1634.h>
#elif defined (__AVR_AT90SCR100__)
#  include <avr/io90scr100.h>
#elif defined (__AVR_ATxmega16A4__)
#  include <avr/iox16a4.h>
#elif defined (__AVR_ATxmega16A4U__)
#  include <avr/iox16a4u.h>
#elif defined (__AVR_ATxmega16C4__)
#  include <avr/iox16c4.h>
#elif defined (__AVR_ATxmega16D4__)
#  include <avr/iox16d4.h>
#elif defined (__AVR_ATxmega32A4__)
#  include <avr/iox32a4.h>
#elif defined (__AVR_ATxmega32A4U__)
#  include <avr/iox32a4u.h>
#elif defined (__AVR_ATxmega32C3__)
#  include <avr/iox32c3.h>
#elif defined (__AVR_ATxmega32C4__)
#  include <avr/iox32c4.h>
#elif defined (__AVR_ATxmega32D3__)
#  include <avr/iox32d3.h>
#elif defined (__AVR_ATxmega32D4__)
#  include <avr/iox32d4.h>
#elif defined (__AVR_ATxmega8E5__)
#  include <avr/iox8e5.h>
#elif defined (__AVR_ATxmega16E5__)
#  include <avr/iox16e5.h>
#elif defined (__AVR_ATxmega32E5__)
#  include <avr/iox32e5.h>
#elif defined (__AVR_ATxmega64A1__)
#  include <avr/iox64a1.h>
#elif defined (__AVR_ATxmega64A1U__)
#  include <avr/iox64a1u.h>
#elif defined (__AVR_ATxmega64A3__)
#  include <avr/iox64a3.h>
#elif defined (__AVR_ATxmega64A3U__)
#  include <avr/iox64a3u.h>
#elif defined (__AVR_ATxmega64A4U__)
#  include <avr/iox64a4u.h>
#elif defined (__AVR_ATxmega64B1__)
#  include <avr/iox64b1.h>
#elif defined (__AVR_ATxmega64B3__)
#  include <avr/iox64b3.h>
#elif defined (__AVR_ATxmega64C3__)
#  include <avr/iox64c3.h>
#elif defined (__AVR_ATxmega64D3__)
#  include <avr/iox64d3.h>
#elif defined (__AVR_ATxmega64D4__)
#  include <avr/iox64d4.h>
#elif defined (__AVR_ATxmega128A1__)
#  include <avr/iox128a1.h>
#elif defined (__AVR_ATxmega128A1U__)
#  include <avr/iox128a1u.h>
#elif defined (__AVR_ATxmega128A4U__)
#  include <avr/iox128a4u.h>
#elif defined (__AVR_ATxmega128A3__)
#  include <avr/iox128a3.h>
#elif defined (__AVR_ATxmega128A3U__)
#  include <avr/iox128a3u.h>
#elif defined (__AVR_ATxmega128B1__)
#  include <avr/iox128b1.h>
#elif defined (__AVR_ATxmega128B3__)
#  include <avr/iox128b3.h>
#elif defined (__AVR_ATxmega128C3__)
#  include <avr/iox128c3.h>
#elif defined (__AVR_ATxmega128D3__)
#  include <avr/iox128d3.h>
#elif defined (__AVR_ATxmega128D4__)
#  include <avr/iox128d4.h>
#elif defined (__AVR_ATxmega192A3__)
#  include <avr/iox192a3.h>
#elif defined (__AVR_ATxmega192A3U__)
#  include <avr/iox192a3u.h>
#elif defined (__AVR_ATxmega192C3__)
#  include <avr/iox192c3.h>
#elif defined (__AVR_ATxmega192D3__)
#  include <avr/iox192d3.h>
#elif defined (__AVR_ATxmega256A3__)
#  include <avr/iox256a3.h>
#elif defined (__AVR_ATxmega256A3U__)
#  include <avr/iox256a3u.h>
#elif defined (__AVR_ATxmega256A3B__)
#  include <avr/iox256a3b.h>
#elif defined (__AVR_ATxmega256A3BU__)
#  include <avr/iox256a3bu.h>
#elif defined (__AVR_ATxmega256C3__)
#  include <avr/iox256c3.h>
#elif defined (__AVR_ATxmega256D3__)
#  include <avr/iox256d3.h>
#elif defined (__AVR_ATxmega384C3__)
#  include <avr/iox384c3.h>
#elif defined (__AVR_ATxmega384D3__)
#  include <avr/iox384d3.h>
#elif defined (__AVR_ATA5790__)
#  include <avr/ioa5790.h>
#elif defined (__AVR_ATA5790N__)
#  include <avr/ioa5790n.h>
#elif defined (__AVR_ATA5791__)
#  include <avr/ioa5791.h>
#elif defined (__AVR_ATA5272__)
#  include <avr/ioa5272.h>
#elif defined (__AVR_ATA5505__)
#  include <avr/ioa5505.h>
#elif defined (__AVR_ATA5795__)
#  include <avr/ioa5795.h>
#elif defined (__AVR_ATA5702M322__)
#  include <avr/ioa5702m322.h>
#elif defined (__AVR_ATA5782__)
#  include <avr/ioa5782.h>
#elif defined (__AVR_ATA8210__)
#  include <avr/ioa8210.h>
#elif defined (__AVR_ATA5831__)
#  include <avr/ioa5831.h>
#elif defined (__AVR_ATA8510__)
#  include <avr/ioa8510.h>
#elif defined (__AVR_ATA6285__)
#  include <avr/ioa6285.h>
#elif defined (__AVR_ATA6286__)
#  include <avr/ioa6286.h>
#elif defined (__AVR_ATA6289__)
#  include <avr/ioa6289.h>
#elif defined (__AVR_ATA6612C__)
#  include <avr/ioa6612c.h>
#elif defined (__AVR_ATA6613C__)
#  include <avr/ioa6613c.h>
#elif defined (__AVR_ATA6614Q__)
#  include <avr/ioa6614q.h>
#elif defined (__AVR_ATA6616C__)
#  include <avr/ioa6616c.h>
#elif defined (__AVR_ATA6617C__)
#  include <avr/ioa6617c.h>
#elif defined (__AVR_ATA664251__)
#  include <avr/ioa664251.h>
/* avr1: the following only supported for assembler programs */
#elif defined (__AVR_ATtiny28__)
#  include <avr/iotn28.h>
#elif defined (__AVR_AT90S1200__)
#  include <avr/io1200.h>
#elif defined (__AVR_ATtiny15__)
#  include <avr/iotn15.h>
#elif defined (__AVR_ATtiny12__)
#  include <avr/iotn12.h>
#elif defined (__AVR_ATtiny11__)
#  include <avr/iotn11.h>
#elif defined (__AVR_M3000__)
#  include <avr/iom3000.h>
#elif defined (__AVR_DEV_LIB_NAME__)
#  define __concat__(a,b) a##b
#  define __header1__(a,b) __concat__(a,b)
#  define __AVR_DEVICE_HEADER__ <avr/__header1__(io,__AVR_DEV_LIB_NAME__).h>
#  include __AVR_DEVICE_HEADER__
#else
#  if !defined(__COMPILING_AVR_LIBC__)
#    warning "device type not defined"
#  endif
#endif

#include <avr/portpins.h>

#include <avr/common.h>

#include <avr/version.h>

#if __AVR_ARCH__ >= 100
#  include <avr/xmega.h>
#endif

/* Include fuse.h after individual IO header files. */
#include <avr/fuse.h>

/* Include lock.h after individual IO header files. */
#include <avr/lock.h>

#endif /* _AVR_IO_H_ */
Danke dir für das erstellen des HEX Datei.
War das nur die HEX Datei die erstellt wurde, oder war auch was als eep Datei dabei?

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 19:27
von Fritzler
@Andreas
Wie du selber sieht wird da in Zeile 14 keine page.h includiert.

Mach doch mal "avr-gcc -v" und Poste den Output.
Das sieht so aus als würde der avrgcc einen völlig flashcne includepath haben und sich daher sonstwas ziehen.

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 19:29
von Bauteiltöter
Ne, ein eep war nicht dabei. Im Git-Repo gibt es aber ein eeprom-default.hex, dass sollte dann dein EEPROM-Image sein.

Zum Buildproblem:
Deine io.h sieht richtig aus und hat in Zeile 14 keinen Code sondern noch Kommentar. Dein Compiler bekommt also offensichtlich NICHT diese io.h zu sehen sondern irgendeine - da bleibt nur die Frage warum.
Irgendwie sind deine Include-Pfade daneben.

Mach mal bitte

Code: Alles auswählen

avr-cpp -v

und poste das Ergebnis, da müsste sowas auftauchen:

Code: Alles auswählen

torben@igor:~/repositories/blinkstick-firmware$ avr-cpp -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/4.9.2/device-specs/specs-avr2
COLLECT_GCC=avr-cpp
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2 -fstack-protector-strong -Wformat ' CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS='-g -O2 -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2 -fstack-protector-strong' FFLAGS='-g -O2 -fstack-protector-strong' GCJFLAGS='-g -O2 -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2 -fstack-protector-strong -Wformat '
Thread model: single
gcc version 4.9.2 (GCC) 
COLLECT_GCC_OPTIONS='-E' '-v' '-specs=device-specs/specs-avr2'
 /usr/lib/gcc/avr/4.9.2/cc1 -E -quiet -v - -mn-flash=6 -mskip-bug
ignoring nonexistent directory "/usr/lib/gcc/avr/4.9.2/../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/avr/4.9.2/include
 /usr/lib/gcc/avr/4.9.2/include-fixed
 /usr/lib/gcc/avr/4.9.2/../../../avr/include
End of search list..

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 19:43
von Andreas_P
Das kam bei mir raus.

Code: Alles auswählen

andreas@andreas-M70Vn:~$ avr-cpp -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/4.9.2/device-specs/specs-avr2
COLLECT_GCC=avr-cpp
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2 -fstack-protector-strong -Wformat ' CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS='-g -O2 -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2 -fstack-protector-strong' FFLAGS='-g -O2 -fstack-protector-strong' GCJFLAGS='-g -O2 -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2 -fstack-protector-strong -Wformat '
Thread model: single
gcc version 4.9.2 (GCC) 
COLLECT_GCC_OPTIONS='-E' '-v' '-specs=device-specs/specs-avr2'
 /usr/lib/gcc/avr/4.9.2/cc1 -E -quiet -v - -mn-flash=6 -mskip-bug
ignoring nonexistent directory "/usr/lib/gcc/avr/4.9.2/../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/avr/4.9.2/include
 /usr/lib/gcc/avr/4.9.2/include-fixed
 /usr/lib/gcc/avr/4.9.2/../../../avr/include
End of search list.

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 19:46
von Wurstblinker
Chemnitzsurfer hat geschrieben:Wie lange stand die Farbe schon herum?
Meist geben die Hersteller 2 Jahre Lagerfähigkeit an. Wenn man Pech hat, steht die Plörrer halt schonmal 1 jahr im Hochregallager
Steht ja im ersten Post 3 Jahre Garantie, 5-6 Jahre alt

Habe jetzt mal auf RMK gehört und den Glibber weggekippt,
übrig blieb 4/5 Eimer "feste Farbe" die ja normal sa*** Teuer ist :lol:

Lässt sich aber gut verstreichen und riecht auch nicht Muffig

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 19:59
von Bauteiltöter
Tja @Andreas .. deine Ausgabe von avr-cpp ist 1:1 identisch mit dem was ich habe. Ich hab keine AHnung mehr wo man weiter suchen könnte...
Kontrolliere noch mal ob sich in den Pfaden
/usr/lib/gcc/avr/4.9.2/include
/usr/lib/gcc/avr/4.9.2/include-fixed
/usr/lib/gcc/avr/4.9.2/../../../avr/include
wirklich nur avr-Dateien befinden... dann keine Ahnung mehr.
Hoffen, dass sich hier noch jemand vorbei kommt der sich besser auskennt. Oder du wendest dich mal an die Experten im mikrocontroller.net, dort springen genug AVR-GCC, AVR-Binutils und AVR-libc-Entwickler rum die vielleicht noch eine Idee haben.

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 21:32
von Lukas_P
Kurze Frage, was meinen die Amis mit "Plaster of Paris" ? dürfte Stuckgips sein oder ? HIntergrund ist das ich einen Wachs Feinguss (alu) machen möchte und die ihre formen alle mit o.g. Zeug ummanteln

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 21:46
von Chemnitzsurfer

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 22:49
von xanakind
Irgendwo hier gab es mal einen Link auf einen Modifizierten Philips CD-Player.
Der hatte eine Fliese und Holzklötze im Inneren.
Wegen dem Klang und so..... :lol:
Leider finde ich das nicht mehr! ich würde das sehr gerne mal einen Kollegen schicken.

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 23:11
von Sir_Death

Re: Kurze Frage -> schnelle Antwort

Verfasst: So 7. Jan 2018, 23:21
von xanakind
Super, Danke!
Hab das gleich mal weitergeleitet, der wird morgen was zu lachen haben :lol:

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mo 8. Jan 2018, 13:50
von Lukas_P
was benutze ich am besten als trennmittel wenn ich ein Gipsteil mit Silikon Abformen möchte ? Spüli (zieht warscheinlich in den Gips ein??) ? Vaseline ? wichtig ist das der Abdruck danach nicht zerstört ist (oder zu sehr versifft)

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mo 8. Jan 2018, 19:53
von xanakind
Ich habe hier eine Fritz Box 4690 Cable.
Macht keinen Muck mehr.
Ok, wird wohl was an der Stromversorgung sein, aber die ist ok.
Die Internen Betriebsspanungen sind da und die CPU wird warm:
Fritz.jpg
Keine LED´s leuchten, kein zugriff über das Web Portal und keinen Reset Taster.
Und nun? wegschmeissen?

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mo 8. Jan 2018, 19:59
von ferdimh
Sind wirklich ALLE Spannungen da? Ich würde da nicht unter 3 getrennte Schaltregler + ein paar Linearbraten erwarten.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mo 8. Jan 2018, 20:03
von basti1
Fritzbox per Telefon resetten
Stellen Sie Ihr an die Fritzbox angeschlossenes Telefon so ein, dass es das Tonwahlverfahren unterstützt. Ob dies der Fall ist, wissen Sie, wenn Sie während eines Telefonats eine Taste drücken und am anderen Ende der Leitung ein Ton erklingt. Bei den meisten Telefonen ist dies bereits der Fall.
Sobald das Freizeichen zu hören ist, tippen Sie nacheinander folgende Zahlen und Zeichen in das Telefon ein: #991*15901590*. Auch hier gilt: Setzen Sie die Fritzbox auf Auslieferungszustand zurück, gehen alle gespeicherten Daten verloren.
Legen Sie anschließend auf, wird die Fritzbox neu gestartet. Nach ca. einer Minute ist Sie wieder einsatzbereit.

Hab ich früher schon mal gemacht.


MFG Sebastian

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mo 8. Jan 2018, 22:19
von Desinfector
kriegt einer Unterlagen für ein Rohde & Schwarz NGB 70/5 Labornetzteil
zusammen?

der jüngste Fund sollte doch noch mal untersucht werden.
Nur krieg ich grad nicht so wirklich kluch, wie man das alles am besten freilegt.

Das Teil hat einen auf "Silvesternachzügler" gemacht (geballert), ordentlich gestunken.
Aber unter den Abdeckungen kann man nix erkennen wo das war.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mo 8. Jan 2018, 22:54
von IPv6
Irgendwo hier gab es mal einen Link auf einen Modifizierten Philips CD-Player.
Der hatte eine Fliese und Holzklötze im Inneren.
Wegen dem Klang und so..... :lol:
Ihr müsst den Thread zu Ende lesen, der Erbauer meldet sich auch noch zu Wort :D

Und dann beginnt eine große Schlacht um
- Jitter
- böse digitale Filter, deren Einschwingen man schon vor dem eigentlichen Ton hört, was für den Menschen ganz unnatürlich klingt und vermieden werde muss, quasi die Gitarrensaite die schwingt, noch bevor der Finger die berührt
- die Klangunterschiede von Cinch- und Kaltgerätebuchsen
- Netzbrummen, das auf digitale Signale einstrahlt
- die groben, unempfindlichen Messgeräte die es heutzutage gibt, die nichtmal ansatzweise dazu fähig sind messen können, was das Ohr hören kann
- Bits, die das Laufwerk nicht zur richtigen Zeit liefert was man deutlich hören kann
- Daten, die bitgleich am Wandler ankommen aber trotzdem unterschiedlich klingen, weil da steckt mehr dahinter
- Vibrationen, die das auslesen von Daten zum richtigen Zeitpunkt verhindern
- Die ganzen Entwicklungsabteilungen von Audioherstellern haben so wenig Ahnung, dass man am Küchentisch einen CD-Player durch das Entfernen einer Filterschaltung verbessern kann

Und ganz viel
Ich hab Recht
Nein, ich hab Recht!
NEIN, ICH HAB RECHT!!!
NEIN, ICH HABE RECHT!!!

Und außerdem muss man den Ohren vertrauen, keinen Messgeräten!
Und außerdem habe ich mal viel mehr Ahnung als du weil ich kenn den Chefentwickler von hastdunichtgesehen persönlich und der hat mir bestätigt, dass das so ist und außerdem mache ich das schon seit 130 Jahren und bin gelernter xyz und daher weiß ich das, komm mir nicht mit deiner Theorie, du musst das hören und selber ausprobieren sonst kannst du nicht mitreden, bloß weil du ein Oszillogram von einem total verzerrten Sinus vom CD Player zeigst heißt das noch lange nicht, dass das schlechter sein muss als ein sauberes Sinussignal welches aus einem bösen digitalen Filter stammt, das ist nämlich viel schlimmer!!!

Und zwischendurch ein paar kleinlaute Stimmen, die verkünden, dass sie doch eigentlich bloß Musik hören wollten...

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mo 8. Jan 2018, 23:31
von Julez
Wenn ich sowas sehe bin ich immer extrem froh, kein audiophiler Musikhobbyist zu sein. Ich würde da wahnsinnig werden, wenn ich eventuelle und aufwändige Verbesserungen nur erahnen, aber nicht messtechnisch nachweisen könnte. Wenn ich mir dagegen einen Motor für meine Modellflieger selbst wickle, kann ich wenigstens messen, ob der nachher besser ist als vorher.

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mo 8. Jan 2018, 23:53
von Lukas_P
vll etwas ot, aber ... kann man nen motor von Hand überhaupt "besser" wickeln als die hersteller die das schon...ehm.. öfer machen? Audiophile sind manchmal etwas gelangweilt, weil heute widergabegeräte so ähnlich aufgebaut sind das es klanglich ab einer gewissen preisklasse, keinen unterschied mehr gibt.. da muss mann dann halt selber klangliche unterschiede erfinden um weiterhin mit den anderen über irgendwas streiten zu kennen

Re: Kurze Frage -> schnelle Antwort

Verfasst: Mo 8. Jan 2018, 23:54
von Fritzler
Vor allem wie sich dann ein Mitentwickler eines der alten CD Player meldet und dann geh der Schlagabtausch erst so richtig los :lol: