Show Posts
Pages: 1 ... 84 85 [86] 87 88 ... 201
1276  International / Deutsch / Re: Microcontroller einzelnd betreiben, ohne Entwicklerboard on: November 15, 2013, 05:54:35 am
Und das ist dann alles? Genial. Danke Leute

Wenn Du nackte und ohne Arduino-Bootloader gekaufte Controller programmieren möchtest, benötigst Du noch einen "ISP Programmer".  Wenn Du keinen richtigen Programmer kaufen möchtest, kannst Du notfalls mit entsprechender Verkabelung auch ein Arduino-Board als Programmer verwenden:
http://arduino.cc/en/Tutorial/ArduinoISP
1277  International / Deutsch / Re: Microcontroller einzelnd betreiben, ohne Entwicklerboard on: November 15, 2013, 05:35:25 am
Gibt es da was vorgefertigtes?
Wird das billiger, oder sind die Produkte schon so günstig, dass sich das nicht lohnt?
Kann ich mir sowas selbst basteln?
Was bräuchte ich dafür?

Es gibt beispielsweise abgespeckte Mini-Boards ohne den USB-Plumpatsch dran.
Die werden teilweise sehr preiswert verkloppt.
E-Bay Suchbegriff zum Beispiel "pro mini atmega328".
Die billigsten Angebote mit der Suchoption "weltweit" gibt es von chinesischen Versendern.

Zum Programmieren solcher Boards, die bereits mit Arduino-Bootloader drauf ausgeliefert werden, brauchst Du dann noch einen USB-TTL Adapter, eBay Suchbegriff zum Beispiel "PL2303HX usb ttl" (auch dabei wieder die billigsten Versender aus China mit Option "weltweit").

Dann kannst Du Deine Anwendung z.B. auf einem UNO entwickelt, und zum Programmieren schließt Du den USB-TTL Adapter an, lädst das Programm auf das Mini-Board und kannst danach den USB-TTL-Adapter wieder abnehmen (und zur Programmierung weiterer Mini-Boards verwenden).
1278  International / Deutsch / Re: Quarz an DS1307 schwingt nicht on: November 15, 2013, 05:26:10 am
Kann es sein, dass der IC defekt ist?

Die DS1307 kannst Du per Software anhalten und starten.
Kann es sein, dass Du die DS1307 noch gar nicht gestartet hast?
1279  International / Deutsch / Re: sainsmart ethernet shield + lcd keypad on: November 15, 2013, 02:56:15 am
danke für deine schnelle Antwort. Dann muss ich das Keypad wohl extern verkabeln und nicht aufstecken.
Die Seite werde ich mir gleich mal in die Lesezeichen legen.

Keine schlechte Idee.

Beim Keypad-Shield mußt Du aber wie ich gerade sehe, doch diesen Link nehmen:
http://shieldlist.org/dfrobot/lcd
Dein Sainsmart-Shield verwendet wie das DFRobot-Shield D10 für die Hintergrundbeleuchtung.
1280  International / Deutsch / Re: sainsmart ethernet shield + lcd keypad on: November 15, 2013, 01:40:53 am
Gibt es da möglicherweise kollissionen bei den Pinbelegungen?

Ja, die Shields entsprechen von der Pinbelegung her:
http://shieldlist.org/nuelectronics/lcd
http://shieldlist.org/arduino/ethernet-v5
Und demnach verwenden beide D4 und A0, und zwar nicht für denselben Zweck.
1281  International / Deutsch / Re: Kleine Daten auf dem Arduino speichern und wieder abrufen on: November 13, 2013, 05:05:05 pm
Oh das hört sich ja Klasse an. Allerdings habe ich rein zufällig nur das DS1302 Uhrenmodel gekauft.
Laut Datasheet hat sie auch einen Speicher, aber nur 31 Bytes. Sollte aber reichen für ein paar Zahlen, oder?

Die Speicherung von Zahlen beansprucht genau so viel RAM im Uhrenmodul wie im RAM-Speicher des Arduino
byte - 1 Byte http://arduino.cc/de/Reference/Byte
integer - 2 Bytes http://arduino.cc/de/Reference/Int
long - 4 Bytes http://arduino.cc/de/Reference/Long
float - 4 Bytes http://arduino.cc/de/Reference/Float
1282  International / Deutsch / Re: SD-Karte: Dateinamen als String öffnen on: November 13, 2013, 03:18:50 pm
Lediglich die ersten sechs Nullen kommen mir noch "spanisch" vor, aber das kriege ich bestimmt auch noch hin.

Ja, sieht gut aus, wenn man sich die ersten sechs Nullen wegdenkt.
2e 75 56 sind 46,117,86, das scheint zu stimmen.

Jedenfalls kann ich damit jetzt sicherlich was anfangen. Ich brauche kein Komma mehr und muss die Binärzahlen (eigentlich sind es ja Hexadezimalzahlen?) nur noch in 512 Byte-Blöcken auslesen.  
Eine ähnliche Datei (nur mit 506 Bytes drin) ist als BIN-Datei 510 Bytes groß und als utf8-Datei 1396 Bytes groß. Das ist doch schon mal was!! Das muss ich alles nicht einlesen - das ist mal der Faktor 2,7!

Genau! Mit Speicherung in Binär statt ASCII belegt die Datei viel weniger Platz und beim Einlesen der gesamten Datei braucht man weniger Zeit zum Einlesen, bei fest vorgegebener maximaler Datenrate. Das ist die Idee dahinter.

Wenn die SD-Ausleserei mal schnell funktioniert dann schreibe ich mal, um wieviel Prozent ich die Geschwindigkeit steigern konnte!

Ich habe mal kurz mit der SD-Library getestet, die mit Arduino mitgeliefert wird: Das Ding fällt raus, weil es die geforderte Datenrate nicht bringt.

Meine Tests ergeben, dass mit der standardmäßigen SD-Library maximal 24 bis ca. 27 KBytes pro Sekunde Leserate machbar sind, je nach Chichi beim Einlesen und Timen. Diese SD-Library unterstützt nicht das blockweise Einlesen kompletter 512-Byte Blöcke mit einem Funktionsaufruf, und mit dem zeichenweisen Einlesen ist das Ding nicht schnell genug.

Da müßte man mal eine schnellere SD-Library auftun. So wie ich das sehe, darf die Library ja gerne andere Mankos haben, aber sie muß wenigstens rasend schnell sein und muss das einlesen kompletter 512-Byte Blöcke aus einer Datei ermöglichen.

Mal schauen, was es da an Alternativen zur standardmäßigen SD-Library gibt und um wie viel schneller die dann ggf. sind.

Wenn Du was schnelles findest, kannst Du ja mal Bescheid geben.
Ich würde wohl als erstes mal die "SdFat" Library gegenchecken, was die an Einlesegeschwindigkeit und Funktionen bietet.

Edit/Nachtrag: Der oben gestrichene Absatz stimmt so nicht. Auch die standardmäßige Arduino SD-Library unterstützt ein "buffered read", und das ist viel schneller als das Einlesen einzelner Zeichen in einer Schleife. Wenn ich das richtig überblicke, sind mit "buffered read" etwas über 200 KBytes pro Sekunde mit der SD-Library machbar.  Das könnte für Deine Zwecke doch brauchbar sein.

Nachtrag-2: Ich habe nochmal weiter getestet, wie schnell man beim Lesen sein kann. Und zwar mit 177 Byte großen Puffern, die 59 LEDs mal 3 Bytes RGB entsprechen. Das Ergebnis zeigt, dass die Einlesezeit beim Einlesen eines einzelnen 177-Byte-Puffers sehr stark schwanken kann, wenn man eine große Datei liest:
- Maximale Einlesezeit: 5880 usec,
- Minimale Einlesezeit: 120 usec
- Durchschnittliche Einlesezeit: 799 usec
Was auch klar ist, denn die SD-Karte wird Sektorenweise zu je 512 Bytes gelesen. Mal kommen die 177 Bytes aus einem bereits gelesenen Sektor, das geht schnell. Mal muß ein neuer 512 Byte Sektor eingelesen werden. Und mal muß sogar im FAT-Dateisystem ein neuer FAT-Sektor eingelesen werden um nachzuschauen, welches der nächste zur Datei gehörende Sektor ist.

D.h. "im Durchschnitt" reicht eine Einlesezeit von 0,8 Millisekunden aus, um alle 2 Millisekunden einen kompletten Puffer ausgeben zu können. Aber die maximale Einlesezeit von fast 6 Millisekunden reicht bei weitem nicht, nicht mal mit 2 oder 3 Puffern, um die Darstellung flüssig zu halten. Mein Vorschlag: 8 Puffer a 177 Bytes. Mit einem MEGA sollte das kein Problem sein., und im Schnitt hast Du dann alle 2 Millisekunden im Timer-Interrupt bis zu 1 Millisekunde = 1000 Mikrosekunden Zeit, um die 59 LEDs zu setzen. Das sollte passen. Falls Du Hilfe bei der Umsetzung brauchst, melde Dich, ich habe hier zum Testen der Geschwindigkeit schon einiges zusammengestrickt, was sich ggf. als Ansatz verwenden läßt.
1283  International / Deutsch / Re: SD-Karte: Dateinamen als String öffnen on: November 13, 2013, 01:10:46 pm
OK. Habe ich verstanden. Ich generiere mir mit PHP die RGB-Daten: http://raspberrypi.fmhmamehlauorxfo.myfritz.net/rgb/sd.php (Ich war schon so stolz, dass ich überhaupt an die RGB-Werte komme ...)  smiley Aber mal sehen. Vielleicht geht das ja mit PHP irgendwie ... Umwandeln in Binärzahlen geht wohl mit
Code:
decbin()
aber ich glaube, dass die Datei selbst irgendwie als Binärdatei angelegt werden muss ...?

Wenn Du Deinen Arduino besser programmieren kannst als Dein PHP kannst Du es im Endeffekt auch mit Arduino machen und Dir einen kleinen Sketch erstellen, der Dir Deine Datei "Bild.txt" einliest und eine "Bild.bin" Datei auf die SD-Karte zurückschreibt. Laufzeit ist ja egal, da das nur einmalig zur Vorbereitung der Datei gemacht werden muss.

Dein Programm arbeitet dann mit der viel kleineren Bild.bin Datei, die dann immer eine durch 177 teilbare Dateigröße aufweisen sollte (177 = 59 LEDs mal 3 Bytes RGB).
 
Das bedeutet, dass ich momentan pro Byte einen Dateizugriff auslöse, sinnvoll wären aber ein Dateizugriff pro 512 Bytes. Sehe ich ein. Weißt du, was nur das Problem sein wird? Wenn dann nach 512 Bytes der Dateizugriff tatsächlich stattfindet wird es einen kleinen Ruckler geben, weil ja dann nicht mit der gleichen Geschwindigkeit "abgespielt" werden kann.

Wegen dem "Ruckler" beim Nachladen: Das kommt ganz darauf an, wie das Programm läuft. Ein MP3-Player macht ja auch keine Ruckler beim Abspielen, wenn er den Sound aus der Datei nachlädt. Es kommt nur auf die richtige Programmlogik an. Mir schwebt da folgendes vor:

a) Du definierst nicht einen, sondern ZWEI Lesepuffer a 512 Bytes für das Lesen von SD-Karte
b) Das Befeuern der LEDs findet in einem Timer-Interrupt alle 2 Millisekunden statt.

Und nun läuft es von der Programmlogik her wie folgt:
Zu Beginn werden beide Lesepuffer vollgeladen und dann der 2ms-Timer-Interrupt zum Abspielen gestartet. Nennen wir die Lesepuffer mal LP0 und LP1.

Eine globale Variable im Programm legt fest, welches gerade der "aktive" Lesepuffer ist, aus dem der Timer-Interrupt die Daten holt. Beginn mit LP0.

Nun feuert der Timer-Interrupt, die ISR holt 177 (59*3) Bytes aus dem LP0 Puffer, setzt die LEDs.
Nach 2 ms feuert wieder der Timer-Interrupt, die ISR holt 177 (59*3) Bytes aus dem LP0 Puffer, setzt die LEDs.
Das geht 2 mal gut. Beim 3. mal sind nicht mehr genügend Daten in Lesepuffer LP0.
Die ISR holt sich nun die fehlenden Bytes aus dem Lesepuffer LP1, setzt das Flag für "LP1 ist aktiv".

So werkelt der Timer mit seinen Interrupts vor sich hin, holt mal die Daten aus dem einen, dann aus dem anderen Lesepuffer, und setzt jeweils das Flag, welcher Lesepuffer aktiv ist.

Nun zur loop-Funktion: Die loop-Funktion achtet in einer ganz engen Schleife darauf, ob sich das Flag für den Lesepuffer ändert. Sobald das Flag für den Lesepuffer wechselt, lädt die loop-Funktion neue 512 Bytes an Daten in den jeweils nicht aktiven Puffer. Und lauert anschließend wieder darauf, dass das Flag für den aktiven Lesepuffer wechselt.

Das läuft vom Prinzip her vollkommen ruckelfrei. Allerdings läuft es nur wie beabsichtigt, wenn die loop die Daten schnell genug nachladen kann. Zeitabschätzung: Da 2 mal 177 Bytes auf jeden Fall komplett in 512 Bytes hineinpassen, hat die loop-Funktion immer mindestens 2* 2ms = 4 Millisekunden Zeit, um einen 512 Byte großen Puffer nachzuladen.

Genauer gesagt: 4 Millisekunden abzüglich der Zeit, die die 2 Timer-Interrupts zwischendurch verbraten zum Setzen der 59 LEDs jedesmal.

Wenn Du das hinbekommst, kann es von SD-Karte laufen. Und auch ruckelfrei.

Aber ich befürchte: 4 ms sind schon sehr knapp zum Nachladen von SD-Karte.
1284  International / Deutsch / Re: [gelöst] Eingang abfragen on: November 13, 2013, 10:05:34 am
if (digitalRead(7)=HIGH)

Wenn Du stattdessen sogar eine boolsche Abfrage machst
if (digitalRead(7))
oder in der Negation
if (!digitalRead(7))
dann kommst Du auch nicht in die Verlegenheit, die Zuweisung "="  mit dem Vergleich per "==" zu verwechseln.
1285  International / Deutsch / Re: Kleine Daten auf dem Arduino speichern und wieder abrufen on: November 13, 2013, 09:53:02 am
Und speichert der Arduino das auch wenn ich das USB-Kabel abziehe und nach einiger Zeit wieder einstecke?

Der Arduino UNO hat 2 KB RAM-Speicher, der beim Ausschalten und beim Reset jedesmal gelöscht wird.

Und er hat zusätzlich 1 KB EEPROM-Speicher, der beim Ausschalten permanent erhalten bleibt.

Der EEPROM-Speicher darf unbegrenzt ausgelesen werden, aber er nutzt sich beim Schreiben ab und der Hersteller garantiert nur für 10.000 Schreibzyklen. Wenn Du zu häufig in den EEPROM-Speicher schreibst, wird der Speicher kaputtgeschrieben. Vorgesehen ist der EEPROM-Speicher eigentlich für dauerhafte Konfigurationseinstellungen, die sich eher selten ändern.

Eine Alternative ist vielleicht für Dich vielleicht ein DS1307 Uhrenmodul, das ist eine Echtzeituhr mit Batteriepufferung, die beim Ausschalten weiterläuft. Als kostenloses Goodie obendrauf hat die DS1307 einen ebenfalls batteriegepufferten RAM-Speicher von 56 Bytes. Dieser batteriegepufferte RAM-Speicher bleibt so lange erhalten, bis die Pufferbatterie entweder leer geworden ist oder aus dem Uhrenmodul herausgenommen wird.


1286  International / Deutsch / Re: Schneller, großer, mobiler Speicher für Arduino gesucht on: November 13, 2013, 09:43:38 am
88.500 Bytes/s ~ 86 KBytes/s abgespielt.

Wow, fast 100 KBytes pro Sekunde, das ist eine Menge Holz!

Hast Du mal versucht, Deine SD-Karte mit  SPI_FULL_SPEED zu betreiben, funktioniert das?

Hast Du mal einen Timing-Test gemacht, mit 512 Bytes Blockgröße beim Lesen (und dabei ständig geöffneter Datei), welche maximale Datenrate beim Lesen Du bekommst, wenn der Sketch sonst nichts anderes macht?

Weil wenn Du in der maximalen Leserate in einem Nur-SD-Lesen-Sketch nicht deutlich über die geforderte Lesedatenrate drüberkommst, kannst Du es mit SD vergessen.

Aber Du mußt eben so effektiv wie möglich programmieren, und darfst nicht hier und da überall Millisekunden oder noch mehr liegenlassen.

Das mit der maximalen Leserate müßte man mal testen.
Möglichst mit verschiedenen SD-Libraries, wenn das einen Geschwindigkeitsunterschied bedeutet.
1287  International / Deutsch / Re: SD-Karte: Dateinamen als String öffnen on: November 13, 2013, 08:24:43 am
... wie würde es denn deutlich schneller gehen??

Oh, oh, wenn Du schon so fragst, brauchst Du wohl umfangreiche Erklärungen.

Zwei Dinge fallen mir an den drei Zeilen Einlesecode auf:

1. Du verwendest das ASCII-Klartextformat zur Speicherung binärer Daten. Das ist zwar gut für Menschen lesebar, z.B. in einem Texteditor, aber zur Abspeicherung von Datensätzen fester Länge verschwendet es massenhaft Speicherplatz. Und je mehr Speicherplatz das Datenformat in der Datei belegt, desto mehr Speicherplatz muß beim Einlesen durch den Arduino geschleust werden. Viel speichersparender in der Datei wäre es, die Daten binär zu speichern.

Beispiel: Du möchtest immer 59 RGB -LED-Werte nacheinander speichern, dann werden bei der binären Speicher in der Datei die RGB-Werte einfach als Bytes nacheinander weggespeichert:

Die ersten 18 Bytes einer Datei:
Code:
abcdefghijklmnopqr  <== die binären Daten als Bytes in der Datei gespeichert
RGBRGBRGBRGBRGBRGB  <==  R, G oder B-Wert ergibt sich aus der Position innerhalb der Datei
000111222333444555  <== Nummer der LED ergibt sich ebenfalls aus der Position innerhalb der Datei

D.h. anhand der Position innerhalb der Datei steht für jedes Byte fest, zu welchem Frame der Animation das Byte gehört, zu welcher LED der Anzeigeleiste das Byte gehört und ob es ein R, G oder B-Byte ist.

Nach den Bytes für die ersten 59 LEDs folgen die nächsten für den zweiten Frame etc.

Prinzip einer "Binären Datei mit Datensätzen fester Länge" verstanden?
Kannst Du die Daten in solchen binären Dateien bereitstellen?

2. Die Anzahl der Dateizugriffe muß minimiert werden.
Also nicht für jedes einzelne Byte eine Leseoperation auf die Datei anwenden, sondern die Datei möglichst "blockweise" auslesen. Das sind bei SD-Karten immer 512 Bytes am Stück. Also liest Du am besten immer mit EINER EINZIGEN Dateioperation 512 Bytes am Stück in einen Puffer ein, diese werden verarbeitet und erst danach erfolgt die nächste Leseoperation, mit der wieder exakt 512 Bytes eingelesen werden.

Das sind zwei Optimierungsmöglichkeiten, die mir so beim Ansehen Deiner drei Einlesezeilen auffallen, um den Datendurchsatz zu erhöhen.

Wie groß ist denn der notwendige Datendurchsatz, d.h. wie viele Bytes oder RGB-Werte pro Sekunde müssen verarbeitet werden?
1288  International / Deutsch / Re: For Schleife ohne Delay on: November 13, 2013, 07:43:31 am
Das Programm funktioniert zum Teil. Nur das Problem ist, das ich im Unterprogramm led_1 bis led_4 ein Delay drin habe.

Einsicht ist der erste Weg zur Besserung.

Nur das geht leider nicht, weil sonst der Taster nicht abgefragt wird. Ich hoffe ihr könnt mir helfen, ich sitze da jetzt schon mehrere Tage dran, und komme einfach nicht weiter.

Algorithmen und Datenstrukturen. Diese beiden Dinge müssen im Programm möglichst sinnreich zusammenwirken.

Was Du da programmierst ist im Prinzip eine Phasenanimation mit eine festen Zykluszeit von 250 ms zwischen den anzuzeigenden Bildphasen. Und die Animation soll interaktiv mit einem Taster umschaltbar sein.

Ein passende Loop-Funktion in Pseudocode würde von mir programmmiert ungefähr so aussehen:

Code:
unsigned long letzteMillis=0;
byte animationsNummer=0;

void loop()
{
  if (millis()-letzteMillis>=250)
  {
    letzteMillis=millis();
    Ermittle_neues_Bild();
    Zeige_neues_Bild();
  }
  if (TasteGedrueckt)
  {
    animationsNummer++;
    if (animationsNummer>MAXANZAHL) animationsNummer=0;
  }
}

Also jeweils nach 250 Millisekunden wird einmal ganz schnell das neue Bild (also eine Animationsphase) ermittelt und nur diese eine Animationsphase an den LEDs gesetzt,, und ansonsten wird in der loop immer nur abgefragt, ob eine Taste gedrückt wurde. So kann das Programm blitzschnell auf Tastendrücke reagieren.

Bei den Datenstrukturen fällt mir auf, dass Du viel zu verschwenderisch mit RAM-Speicher umgehst, um die Animationen zu speichern. Um zwischen 0 und 1 zu unterscheiden reicht ein einzelnes Bit, Du verwendest aber 1 Byte (1 Byte = 8 Bits). Du kannst die Animationsphasen also locker mit einem Achtel des bisherigen Speicherbedarfs abspeichern. Beispiel:
Code:
byte Lauflicht2[] =
{
    0b10000001 , 
    0b01000010 , 
    0b00100100 , 
    0b00011000 , 
    0b00100100 , 
    0b01000010 , 
    0b10000001   
};

Durch die Binärdarstellung des Bytes mit dem Präfix "0b" kannst Du auch im Quellcode sehr schön sehen, welches die gesetzten Bits sind. Und auslesen würdest Du das Bit aus dem Byte mit der Arduino-Funktion bitRead().

Auf Mikrocontrollern ist es beim Programmieren ziemlich wichtig, Speicher zu sparen, weil Mikrocontroller nur wenig davon haben. Um so mehr Speicher Du sparst, um so mehr an Funktionen kannst Du in einem einzigen Sketch realisieren. Nur für den Fall, dass Dein Sketch am Ende noch mehr können soll als diese vier Animationen. So wie Du den RAM-Speicher in multidimensionalen Arrays im RAM reservierst, geht Deinem Programm sonst ziemlich schneller der RAM-Speicher aus.

Und delay() darf in interaktiven Programmen nur so sparsam verwendet werden, dass die Summe der auftretenden Delays nicht länger als die typische menschliche Reaktionszeit beträgt. Also maximal vielleicht 100 ms (0,1s) Delay zwischen zwei Tastaturabfragen ist ggf. noch machbar, damit ein Programm flüssig auf Benutzereingaben reagiert. Alles darüber geht gar nicht. Am besten gewöhnst Du Dir an, auf alle Delays im Programm zu verzichten.

Also ich würde bei dem Sketch schon an etlichen Stellen anders ansetzen.
1289  International / Deutsch / Re: SD-Karte: Dateinamen als String öffnen on: November 13, 2013, 05:17:25 am
rgbwerte[counter][0] = myFile.parseInt();
rgbwerte[counter][1] = myFile.parseInt();
rgbwerte[counter][2] = myFile.parseInt();

Wenn ich mal querlese zu Deinem anderen Thread, dass das Lesen von Werten aus einer Datei auf SD-Karte angeblich so langsam sei, und dann das lese, wie Du offenbar RGB-Werte aus einer Datei liest, wundert mich nichts mehr.
1290  International / Deutsch / Re: Schneller, großer, mobiler Speicher für Arduino gesucht on: November 13, 2013, 05:06:51 am
3. SD-Karte:  funktioniert mittlerweile prima und es lassen sich gigantisch große Bilder abspielen. Großer Nachteil: LAAAAAANGSAAAAAM! Für die Montage am  Fahrrad vollkommen ungeeignet.

Mit was für einer Datenrate in "Bytes pro Sekunde" musst Du denn an die Daten herankommen und diese verarbeiten?
Pages: 1 ... 84 85 [86] 87 88 ... 201