Aus RN-Wissen.de
Wechseln zu: Navigation, Suche


Hier ist ein Multi-Achs-Controller zur interpolierenden Hardware Steuerung von (z.Z.) bis zu 8-Achsen entstanden, ich habe ihn RoBo-mac genannt. Vom Roboternetz habe ich vieles gelernt, das in die Entwicklung eingeflossen ist; mit diesem Artikel möchte ich mich revanchieren. Sogar für die C+++ Fans habe ich einen Hinweis.


Vorwort

Kaum war RoBo-mac fertig, kam die Frage auf, ob man so einen CNC- und Roboter Controller nicht auch Stand-Alone, ohne PC betreiben könne. Bevor es nun bald die SD-Card Variante gibt, mußte ich lernen "wie das geht": Nahezu alles was ich hier zu Papier gebracht habe, habe ich (viel zu lange) im Internet recherchiert aber nichts zusammenhängendes zum Thema, sondern nur Fragmente gefunden. Für dieses Tutorial selbst gebührt mir das Copyright, für den zusammengetragenen Code der begleitenden Tutorial-Datei (Get_Flash_FileSector.bas) nur bedingt.

Mit einigen Links verweise ich auf diejenigen, von denen ich "Honig gesaugt" habe – da vieles mehrfach und wiederholt zitiert wurde, ist jedoch nicht immer klar, wer der eigentliche Ur-Autor wirklich ist. Einige sind kommerzielle Anbieter, die durchaus sinnvolles zu verkaufen haben, andere hoch qualifizierte "Hobby-isten". Alle externen Links sind offen mit ihrer URL im Kontext des Tutorials ausgewiesen und nicht hinter einem Pseudonym versteckt. – Clicken muß man sie nur, um in die Tiefe zu gehen !


SD und MMC Karten

SD, eigentlich SD-Memory Cards sind intelligente MCC Karten, hier ein Blick ins innere: http://de.wikipedia.org/w/index.php?title=Datei:Sdcard_panasonic64mb_inside_front.jpg&filetimestamp=20080829140929 Viel Hintergrund Know-how auch bei http://de.wikipedia.org/wiki/SD_Memory_Card.

SD steht für Security Digital – und kümmert sich um Urheberschutz und unerlaubtes Kopieren (DRMS = Digital-Rights-Management-Systeme). Dieses Security Know-how unterliegt strenger Geheimhaltung und deren Nutzung einer Lizenz. Wer bereit ist, hierfür mehrjährig mehrere 10.000 US$ Royalty jährlich zu zahlen, kann beantragen, als Geheimnisträger in den Club aufgenommen zu werden. Mehr dazu und vielleicht noch ein paar nützliche Infos unter http://www.sdcard.org


Für alle, die es lieber umsonst möchten, geht es hier weiter:

Ihre explosionsartige Marktakzeptanz verdankt die SD Karte einem genialen Marketing-Schachzug: Nicht alles unterliegt der Lizenz und Geheimhaltung, sondern wurde gezielt für Otto-Normalverbraucher zugänglich gemacht und veröffentlicht. SD-Karten können "Royalty free" über das SPI (Serial Peripheral Interface) angesprochen werden, hierfür stehen die Pin 1 bis 7 zur Verfügung (8 und 9 sind die "geheimen").


Pin-Belegung

Ein Anschlußbild der Pin-Belegung und sein Interface zum ATMega 128 findet sich unter "Schematic" hier: http://members.aon.at/voegel/index.html?Downloads.htm

Pin 8 der SD-Card liegt unmittelbar neben Pin 7, Pin 9 unter der abgeschrägten Ecke neben Pin 1.

SD und MMC Karten sind elektrisch und programm-technisch (zumindest für den veröffentlichten Teil) Pin-kompatibel. Mechanisch gibt es Einschränkungen. SD-Karten haben ein etwas dickeres Gehäuse als MMC-Karten. SD-Karten passen daher nicht in MMC-Steckplätze; umgekehrt ist dies bedingt möglich: Manchmal nur ein mal - falls man die kurze MMC nicht wieder aus dem langen SD Slot heraus bekommt !!!


SD-Schreibschutz

SD-Karten haben einen "Schreibschutz Schieber" der mit der eigentlichen SD-Technologie nichts zu tun hat, sondern im Slot einen mechanischen Kontakt gegen Masse betätigt betätig (meist Negative Logik: Bei nicht aktiviertem Schreibschutz geschlossen). Der Schreibschutz kann also geräteseitig vom Microprozessor ausgewertet werden – muß aber nicht.


TTL-Kompatibilität

Elektrisch zählen SD und MMC Cards zur Flash-Technologie und arbeiten mit einer Systemspannung von 3,3 V (im Gegensatz zur TTL–Welt mit einer Systemspannung von 5 V). - Und damit sind sie mit "normalen" Mikroprozessoren nur bedingt kontaktfähig. Während man "von oben nach unten" mit 2 in Reihe geschalteten Dioden die Spannungssysteme angleichen kann, ist dies umgekehrt natürlich nicht möglich; die 3,3 V liegen zwar knapp über der Trigger-Schwelle des Mikroprozessor Einganges - aber eben sehr knapp.

Dies und ähnliches sind ein ewiger Quell teuflischen Unheils: Tage und Nächte habe ich schon verschwendet, um festzustellen, das das Netzteil "eigentlich reicht" (reichen müßte) – aber eben nur eigentlich, abgesehen von wenigen usec, die den Datentransfer torpedierten! Also als Low End Bastlerlösung, na ja:

Professionelles bietet http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html dort gibt es für gute 20,- EU einen SD-Karten Connector mit Spannungs Level Shifter. Wer gerne SMD lötet, kann von Maxim den "MAX 3392 EEUD" hierfür einsetzen. Hier sein Datenblatt: http://www.datasheetcatalog.com/datasheets_pdf/M/A/X/3/MAX3392EEUD.shtml


SD & SDHC

Mitte des ersten Jahrzehnts dieses Jahrtausends zählten SD-Karten mit 512 MB (Mega Byte) zu den (fast unbezahlbaren) Leistungsträgern. Zum Vergleich: Das sind ca. 75 % einer CD auf der Fläche einer Briefmarke. Fotografen zeigten stolz ihre SD-Karte mit den Worten: "Da sind über 200 Bilder drauf".

Die Pixel-Inflation der Digital-Cameras katapultierte in der zweiten Hälfte diese Jahrzehnts die Auflösung von einigen MB in den zweistelligen Bereich – und es wurde eng auf der SD-Card, deren Technologie auf 2 GB (Giga Byte) beschränkt ist. Größeres mußte her. Die SD-Technologie zeigte den anderen Karten-Technologien die Zähne, um Marktanteile zu fressen; dies ist wohl gelungen:

  • Die SDHC (SD High Capacity) Technologie bietet angeblich "open end". 16 und 32 GB Karten in der Bauform der klassischen SD sind bereits auf dem Markt. SDHC ist abwärts kompatibel zu SD; SDHC kann also SD-Karten schreiben und lesen. Umgekehrt nicht - und somit sind USB SD-Card Reader und PCs aus der Windows XP Zeit hiermit mitunter überfordert.
  • SDHC kennt "Leistungsklassen", diese gibt die Mindest- Transferrate im MB/sec an. Eine 2 bedeutet 2 MB/sec, eine 6 steht für 6MB/sec.


Zurück zu beherrschbarem, der SD-Card:


SD/MMC Karten und C+++

Bevor wir nun zu BASCOM kommen noch der Tip für die C-Fans: Ulrich Radig (http://www.ulrichradig.de/home/index.php/avr/mmc-sd ) bietet einen SD-Kartenleser von Roland Riegel (http://www.roland-riegel.de/sd-reader/index.html ) mit detaillierten Informationen aus der C+++ Welt. Da dies nicht meine Welt ist, kann ich nur den Quell-Hinweis geben.

Ein Vorschlag zur Low End Hardware Verdrahtung auf Basis eines "alten ISA Slots" und ohne den o.g. Spannungs Level Shifter findet sich ebenfalls bei Ulrich Radig.


BASCOM, SD/MMC und andere Flash-Karten

Es gibt mit BASCOM zwei Möglichkeiten, Daten auf der (SD/MMC)-Karte zu speichern bzw. zu lesen:

  • zum einen mit AVR-DOS
  • zum anderen mit DriveWriteSektor() bzw. DriveReadSektor()

Beide sind Bestandteile von BASCOM - und für den nicht kommerziellen Gebrauch ist AVR-DOS bereits Bestandteil der BASCOM Lizenz. Da das ganze recht strukturiert angelegt ist, beherrscht BASCOM noch einige andere Karten wie z.B. CF und wohl auch richtige Laufwerke. An Stelle der hier und im folgenden verwendeten "MMC.LBX / MMC.LIB / Config_MMC.bas" sind dann die entsprechenden Pendants einzusetzen.

Schlüsselfunktion im BASCOM-Dateimanagement hat der Befehl "Initfilesystem()"; er liest den Master-Boot Record, die FAT etc. und muß vor allen anderen Datei-Befehlen als erster aufgerufen werden. Wird nach einem "Initfilesystem()" die Speicherkarte gewechselt, so geht alles durcheinander! Es macht also Sinn, über den Slot-Kontakt (Interrupt oder Polling) zu prüfen, ob die Karte seit dem letzten "Initfilesystem()" nicht gezogen wurde.

  • Hier ein Code-Schnipsel, der allerdings nur überprüft, ob auf dem Entwicklungsboard überhaupt die Karte gesteckt ist. Bei den ersten Gehversuchen und Software Tests war ich ins stolpern geraten; das Aufstehen dauerte mehrere Stunden, bis ich merkte, daß die Karte nicht gesteckt war!
'Hardware:  Mega 128 / LCD-Display 4 * 20 /  SD-Kartenhalter von Display 3000

Config Lcdbus = 4                            '4-bit Step_Step_Mode
Config Lcd = 20 * 4                          '20x4 LCD display
Config Lcdpin = Pin , Db4 = Porte.4 , Db5 = Porte.5 , Db6 = Porte.6 , Db7 = Porte.7 , E = Porte.3 , Rs = Porte.2

Const Lcd_line1 = ""
Const Lcd_line2 = "CopyRight:"
Const Lcd_line3 = "     www.RoBo-mac.de"

Cls : Cursor Off Noblink
Locate 1 , 1 : Lcd Lcd_line1
Locate 2 , 1 : Lcd Lcd_line2
Locate 3 , 1 : Lcd Lcd_line3

'Special Function (Display 3000)
Config Pinb.4 = Input                        'Pad Nr. 9   Cardsensor
Config Pinb.5 = Output                       'Pad Nr.10   SD-Card      active (High) / inaktiv (Low)
Config Pinb.6 = Input                        'Pad Nr.11   Writprotect  active (Low)  / inaktiv (High)
Config Pinb.7 = Output                       'nicht belegt

Portb = &B01110000

   If Pinb.4 = 1 Then
      Locate 4 , 1 : Lcd "Card NO"
   Else
      Locate 4 , 1 : Lcd "Card YES "

      If Pinb.6 = 1 Then
        Locate 4 , 11 : Lcd "read only"
      Else
        Locate 4 , 11 : Lcd "read/write"
      End If
   End If
  • Nach einem "Initfilesystem()" weiß BASCOM, wie die Flash-Card organisiert ist.

Während AVR-DOS sich um alles kümmert, wird beim direkten Zugriff jeder Datentransfer per DriveWriteSektor() bzw. DriveReadSektor() über Sektoren blockweise abgewickelt. Um an bestimmte Informationen und ihre Bytes heranzukommen müssen wir nur wissen, in welchem Sektor sie "wo" stehen. NUR – und darum dreht es sich hier.


AVR-DOS

kann Files erzeugen, öffnen, überschreiben, Daten anhängen usw. Es ist ausgesprochen mächtig, braucht aber auch mächtig viel System Ressourcen (Empfehlung Mega 128). Was es kann, findet sich auf der Autoren-WebSite: http://members.aon.at/voegel/index.html?Downloads.htm unter "Interactive File System Interpreter with Description of commands"; laden Sie beide herunter, wir brauchen sie gleich!

Das ist nicht die BASCOM-Website (www.mcselec.com), sondern die von Josef Franz Vögel, der viel zu BASCOM beigesteuert hat. Gezählt habe ich ca. 70 Befehle "aus der guten alten DOS-Zeit" und darüber hinaus bis zur FAT 32 !

Um SD/MMC Karten mit AVR-DOS aus dem eigenen Programm zu lesen müssen sich im BASCOM - LIB Ordner die Dateien

  • AVR-DOS.LBX
  • MMC.LBX

befindenden sowie die Dateien

  • CONFIG_AVR-DOS.bas
  • CONFIG_MMC.bas

in den Ordner kopiert werden, indem sich das eigene Projekt befindet. Mit dem Befehl

  • $include "Config_AVR-DOS.BAS"
  • $include "Config_ MMC.BAS"

im eigenen Programm werden sie beim compilieren eingebunden.


Alternativ hierzu kann der Code von CONFIG_AVR-DOS.bas und CONFIG_MMC.bas ins eigene Programm kopiert werden, die beiden $Include- Befehle entfallen dann. Beide Wege sind im Ergebnis absolut gleichwertig.

In den Internetforen "geistern" eine Menge von Beiträgen herum, die den 2ten Weg des Kopierens genutzt haben – und sich gelegentlich als "Neuer Lösungsansatz" präsentieren. Wenn in diesen Quellcodes Variablen der (schwer lesbaren) Art "Cperrdrivereadresponse / Cpsectorsperclusternotsupported etc." enthalten sind, so stammen die Ur-Lösungsansätze mit hoher Wahrscheinlichkeit aus der Schmiede von Josef Franz Vögel.


DOS-Interpreter, ein Schnupper-Kurs

Über das Terminalprogramm von BASCOM (Aufruf mit Control T) und eine COM Verbindung zwischen PC und Mikroprozessor können wir jetzt die Flash-Card ansprechen.

  • Tip
Für die ersten Gehversuche recht hilfreich ist die Datei Test_DOS_Drive.bas (Download Vögel, s.o.), in die man weit oben meinen Karten-Prüf-Schnipsel einbauen sollte.
  • Installations-Info am Ende von Test_DOS_Drive.bas zu File System Interpreter beachten, sowie die Datei FS-Interpreter.bas in den Ordner kopieren, indem sich das eigene Projekt befindet.
  • Ich habe mit dem PC die Datei "Kurztext.txt" mit dem sinnvollen Inhalt:
Das ist ein Kurztext
123456789
erzeugt und in die erste Verzeichnis Ebene kopiert (um es lebensnah zu gestalten, befinden sich hier noch einige andere Dateien und Verzeichnisse).


  • Machen wir es uns nochmals bewußt:
Ein DOS findet Dateien, weil die von ihr befragte FAT weiß, wo und wie der Dateiinhalt (ggf. auch noch fragmentiert) gespeichert ist.


AVR-DOS Directory

Mit diesen Befehlen finden sich die Dateien im Directory, die wir zuvor mit dem PC geschrieben haben.

TYPE Kurztext.txt 	zeigt den Inhalt der Datei
DUMP Kurztext.txt 	das Hex-Dump hierzu

Das ist vielleicht schön aber sinnlos! Letztendlich wollen wir Daten per Mikroprozessor sammeln, auf der Flash-Card speichern und diese am PC auswerten oder mit Daten, die ein PC-Programm geschrieben hat, den Mikroprozessor etwas tun lassen.


AVR-DOS File

Studieren wir hierzu die Befehle der Gruppe File open, read and write

  • Die meisten dieser Befehle arbeiten nicht mit dem Datei-Namen, sondern einer File-Nummer – und die wissen wir nicht.
  • Die File-open Befehle geben freundlicher weise dies File-Nummer zurück, wenn wir sie mit dem Namen aufrufen
FOB Kurztext.txt	bringt z.B. 128  	(kann natürlich auch eine andere Nr. sein)!
FILEINFO 128		zeigt den Hex-Dump der Datei Kurztext.txt und einige Informationen,  
u.a.Sector#:		z.B. 3200 	 	(kann natürlich auch eine andere Nr. sein)!


Nun wird's spannend: Unter Drive/Card Sector finden wir den Befehl SD, und wahrlich:

SD 3200			zeigt den Hex-Dump der Datei  Kurztext.txt 
CLOSE 128		schließt die Datei  Kurztext.txt 
FILEINFO 128		meldet:   No Filehandle for 128 found 
- aber
SD 3200			zeigt trotzdem den Hex-Dump der Datei  Kurztext.txt 


wir probieren aus der der Gruppe File open, read and write

RL 128			und erhalten Error: 67  (die Datei ist ja auch geschlossen)
- also nochmals
FOB Kurztext.txt	bringt z.B. 128 	(kann natürlich auch eine andere Nr. sein)!

Das erste    RL 128	zeigt die Zeile 1  "Das ist ein Kurztext"
Das zweite   RL 128	zeigt die Zeile 2  "123456789"
Das dritte   RL 128	bringt die Fehlermeldung DOS Error: 1 
- Nun ja, die Datei hat nur 2 Zeilen!


  • Die Befehle aus der Gruppe File open, read and write erfordern also eine "nament- und nümmerlich" geöffnete Datei;
  • die Befehle aus der Gruppe Drive/Card Sector sind deutlich genügsamer !


AVR-DOS Error-Code

Falls irgendwas schief läuft, erhalten wir eine Information:

  • DOS Error: xxx
Diese Nr. (xxx) bezieht sich auf ein DOS eigenes Nummernsystem, daß mit den BASCOM Error-Nr. nichts zu tun hat. Es ist unter AVR-DOS beschrieben.


BASCOM, direkter Sektor Zugriff

Mit deutlich weniger Möglichkeiten, dafür aber ohne den Zeitfresser-Umweg über die FAT arbeiten die Befehle

  • DriveWriteSektor() und DriveReadSektor() etc;
sie lesen/schreiben einen vollständigen Sector (512 Byte). Ob dies der richtige Sector ist und ob er überhaupt beschrieben werden darf, hierum kümmern sich diese Befehle nicht; dafür gibt es das DOS! - Oder wir müssen selber wissen, was wir tun!


Beide Befehle arbeiten mit der gleichen Syntax:

  • Fehler = DriveReadSector(SRAM, Flash) -- Read schiebt von Flash nach SRAM
  • Fehler = DriveWriteSector(SRAM, Flash) -- Write schiebt von SRAM nach Flash


  • Fehler
Wenn kein Fehler auftritt, ist der Rückgabewert 0 und die Welt in Ordnung.
Ist der Rückgabewert <> 0 , so gibt die ERROR-Tabelle Auskunft, was schief gelaufen ist. Ob und wie wir dies Programm technisch auswerten bleibt uns überlassen.


  • SRAM
Ist die Adresse einer Variablen im SRAM.
  • Unangenehm, die wissen wir nicht.
  • Wir wissen nur,
wie die Variable heißt, weil wir ihr mit Dim Buffer As String * 512 ein Plätzchen von 512 Byte im SRAM zugewiesen haben.
  • Mit Pointer = Varptr(buffer) schreibt BASCOM die SRAM-Adresse von "Buffer" in die Variable Pointer.


  • Flash
Ist der Sector auf der SD/MMC-Karte, den wir bearbeiten wollen.
So einen komfortablen Befehl wie Varptr() für die SRAM-Adresse gibt es hierfür leider nicht – und darum habe ich dieses Tutorial und die Datei > Get_Flash_FileSector.bas < geschrieben. Das ist eine Art Kochbuch zum Thema!
Get_Flash_FileSector.bas baut auf Test_DOS_Drive.bas (Download Vögel, s.o.) und vielen Fragmenten, die ich in Internet-Foren gefunden habe, auf. Daher nochmals: Für die Formulierungen gebührt mir das Copyright, für den Code der begleitenden Tutorial-Datei nur sehr bedingt.


FAT, Sektoren und Cluster

Damit es nicht zu einfach wird:

Mehrere Sektoren bilden einen Cluster. Bei den SD-Cards sind es wohl meist 32. Wieviel Sektoren das je Cluster wirklich sind, bestimmt das Betriebssystem entsprechend dem eingesetzten Speichermedium. Wichtig ist: DOS / Windows speichert eine Datei immer in ganzen Clustern.

Wenngleich die folgende Tabelle nicht mehr ganz taufrisch ist, erkennen wir, daß eine Cluster Größe von 32 Sektoren nicht zwangsläufig eine FAT 32 erfordert.

                  Laufwerksgröße     FAT-Typ     Sektoren     Cluster-
               (logischer Datenträger)          pro Cluster    größe
                 ----------------   --------   -----------   -------
  (Disketten)         360K           12-bit         2         1K
                      720K           12-bit         2         1K
                     1.2 MB          12-bit         1       512 Byte
                     1.44 MB         12-bit         1       512 Byte
                     2.88 MB         12-bit         2         1K
  (Festplatten)    0 MB - 15 MB      12-bit         8         4K
                  16 MB - 127 MB     16-bit         4         2K
                 128 MB - 255 MB     16-bit         8         4K
                 256 MB - 511 MB     16-bit        16         8K
                 512 MB - 1023 MB    16-bit        32        16K
                1024 MB - 2048 MB    16-bit        64        32K
Auf einem MS-DOS-Datenträger wird einer Datei mit einer Größe von 1 Byte 1 Cluster Speicherplatz zugeordnet, wobei der nicht genutzte Teil des Clusters verschwendet ist. Einer Datei, die gemäß ihrer Größe 3,2 Cluster benötigt, werden 4 Cluster zugewiesen. Insgesamt folgt daraus, daß kleinere Cluster weniger Verschwendung zur Folge haben. Quelle und mehr dazu unter: http://support.microsoft.com/kb/67321

Der Begriff FAT16 steht für ein 16 Bit Adressiersystem der Cluster, FAT32 für ein 32 Bit Adressiersystem. Mehr hierzu unter: http://users.iafrica.com/c/cq/cquirke/fat.htm#EntryStructure ebenfalls hilfreich: http://www.dewassoc.com/kbase/index.html – Aber sehr mächtig  !!!

Während innerhalb eines Clusters die Sektoren immer fortlaufend sind, können die Cluster mehrerer Dateien im Laufe der Zeit in Ihrer Reihenfolge gemischt (fragmentiert) werden.


Immer wieder Jungfrau

Wenn wir Dateien mit dem PC auf der Flash-Card speichern, kann es passieren, daß sie nicht zusammenhängend in fortlaufenden Clustern und mithin Sektoren, sondern fragmentiert gespeichert werden. AVR-DOS findet die Zusammenhänge; die Drive...Sector() Befehle nicht. Um das Problem zu umgehen, empfiehlt es sich frisch formatierte SD/MMC zu verwenden und für den Datentransfer vom AVR zum PC zuvor ein Dummy-File (lieber zu groß als zu klein) als Platzhalter anzulegen.

Ein Formatierer befindet sich hier: https://www.sdcard.org/downloads/formatter_4/index.html Der Formatierer hat eine "Qick" Funktion. Die löscht zwar nicht den Dateninhalt, sondern lediglich die FAT etc. dies ist jedoch völlig ausreichend. Alternativ hierzu, kann eine vorhandene Datei mit den Windows – üblichen Befehlen gelöscht werden – in jedem Falle muß das Stammverzeichnis im Explorer als "leer" angezeigt werden.

Hier ein Dummy-Datei Generator http://www.raylow.com Dieses Dummy-File können wir umbenennen. Wenn es das erste ist, daß wir geschrieben haben, befindet es sich sein Start-Sektor (bei einer FAT 32) mit hoher Sicherheit an Sector# 512.


"Data First Sector:" ausgewiesen.

Programm technisch kann dies vieles vereinfachen.

System Resourcen

Der Mega128 hat ja schon eine ganz ansehnliche Speicherkapazität. Trotzdem:

Compilieren wir die Datei > Get_Flash_FileSector.bas < mit Function_Switch = 1 so belegt dies 32% seines Programm-Speichers; die beiden anderen Varianten (2 bzw.3) liegen um 5% bzw. 1%. Aber: Function_Switch = 1 bzw. 2 haben einen nahezu gleich großen SRAM Bedarf von gut 3.000 Byte und belegen rund 75 % seiner Kapazität.

Und nun das Wunder:

Function_Switch = 3 frißt nur knapp 800 SRAM Byte, denn die Sektor-Befehle benötigen kein: Config_AVR-DOS.bas !!!


BASCOM ohne DOS

Diesen Vorteil erkaufen wir uns damit, daß wir letztendlich auf der Flash-Card nur eine Datei (mit dem Start-Sektor 512) nutzen können. Natürlich können wir mehrere Flash-Cards (jeweils eine je Datei) verwenden, aber da kann wohl beim Verwechseln einiges Unglück passieren – denn den Dateinamen können wir so nicht lesen.

Zwar weist der Root Start Sector 480 einiges aus, was an den Dateinamen entfernt erinnert – aber hier wird es kryptisch; das packt nur noch AVR-DOS. Spätestens bei langen Dateinamen (also denen mit mehr als 8-Buchstaben) steigt aber auch AVR-DOS aus.


Lange DateiNamen & Date/Time

Es geht trotzdem: Zugegeben, etwas tricky und nur, wenn der AVR eine vom PC geschriebene Datei auswerten soll, die wir kennen – weil wir sie selbst erzeugt haben.

  • Wenn das PC-Programm die ersten (z.B. 64) Byte des Sektors 512 mit dem Filename und dem Zeitstempel belegt, können wir diese gezielt auslesen und über das LCD oder das Terminal-Programm anzeigen. Und hierfür brauchen wir noch nicht mal eine zusätzliche Variable im SRAM, - Overlay macht's möglich!
Wenn Sie mit der DIM Overlay-Option nicht vertraut sind, sollten Sie unbedingt das BASCOM Manual hierzu und die Artikel Bascom Speicherstrukturen und Bascom UART Input lesen.
  • Get_Flash_FileSector.bas zeigt im Gültigkeitsbereich des Compiler-Schalters 3 ein Code-Beispiel für einen Dateinamen von max. 40 Zeichen zuz. Extension (40.3) - und wie Overlay hierauf zugreift.


Tutorial-Datei

Eigentlich wollte ich die Tutorial-Datei als Download einstellen, - habe aber nicht gefunden, wie das geht. Falls das jemand weis, wäre ich für eine Info dankbar --> NLB@Manager-OnWeb.de .

Zunächst daher etwas umständlicher im Copy und Paste Verfahren die Programm-Datei:

Get_Flash_FileSector.bas


Daten-Transferzeit

Verbleibt die Frage: Wie schnell ist der Datentransfer ?

  • Das Hardware SPI des AVR MEGA128 wird mit 4 MHz getaktet. Hiermit liegt die Lesezeit je Sektor von DriveReadSector() recht stabil bei ca. 1,35 msec, beim Schreiben bei ca. 1,65 msec. Mit dem Software SPI stark schwankend bei dem 4 bis 5 fachen Wert.
  • 512 Byte je 1,35 msec entspricht 2,6 usec pro Byte bzw. einer Datentransferrate von ca. 380 kByte/sec. Im Vergleich zur COM-Schnittstelle ist dies extrem schnell, im Vergleich zu USB und FireWire gemächlich.
  • Und nun die gute Nachricht:
Falls die 1,35 msec zu lang sind – Robo-mac muß in dieser Zeit bis zu 50 Schritte für 8 Achsen interpolieren – kann der Datentransfer per Interrupt unterbrochen werden.


Ärger & Co.

Wer nun glaubt, alles würde problemlos laufen, der ist entweder ein gläubiger Mensch oder hat die Rechnung ohne den Wirt – will heißen, die SD-Card gemacht. Hier sind Überraschungen vorprogrammiert: Karten gleicher Kapazität laufen wie erwartet - oder auch nicht. Je nach Hersteller; unabhängig davon, ob sie sich nun High Speed nennen oder nicht.

Festgestellt habe ich, daß mehrere Karten eines Herstellers erst nach dem 2ten Hardware Reset ansprechbar sind, dann aber durchaus zuverlässig arbeiten. (In der DigiCam machen diese Karten keinen Kummer).

Der Lösung dieses Problems sind wir auf der Spur; nur läuft das Ganze noch nicht stabil. Gut Ding will eben Weile haben.

  • Gewiß steht an Stelle dieses Absatzes hier bald eine Lösung !!!


Siehe auch


Wer noch was zum RoBo-mac wissen will, findet ihn hier:


NLB