Hallo,
die zickigen TFT's sind schon das Problem wass ich damit umgehen will.
Im EEPROM_1 ist sowas wie der Administrator des Systems, er wird komplett vom EEPROM geladen.
Das Speicherproblem ist aufgrund das sich die SD-Carte am Prop 2 befindet nicht so kritisch.
Prop 1: ADMIN
wird komplett aus dem EEPROM geladen
vergleicht Boot.bin mit EEPROM und wenn unterschiedlich Boot.bin --> EEPRON --> Reeboot
- den 1. Monitor in Textmodus (Adminisrtative handlungen)
- die Tastatur für das ganze System (umschaltbar über Windowstaste)
- bei der maus binn ich noch am überlegen (echtzeit)
Prop 2: SD
minni bushandling mit readfunktion von 1.SD-Karte(Boot laufwerk)
den EEPROM zu beschreiben
Programmteile zu laden und zu starten und zu benden
- 2x SD-Karten paralel in 2 COG's
- RTC
Prop 3: VID
den EEPROM zu beschreiben
Programmteile zu laden und zu starten und zu benden
- 2. Monitor text/graphig
- Maus (echtzeit)
Prop 3: AUDIO
den EEPROM zu beschreiben
Programmteile zu laden und zu starten und zu benden
- Audio in/out WAV/MIDI .....
Prop 4: SENS
den EEPROM zu beschreiben
Programmteile zu laden und zu starten und zu benden
- alle möglichen I2C Anwendungen
z.Z sollen Programme (da sie die Hartware über den bus Ansprechen) in frei verfügbare COG's gestartet werden aber ich glaube ich spendierre noch zwei Prop's
Daher ist der Speicherplatz nicht so kritisch anzusehen.
Um mein Proplem mit den Laden von Binary files besser zu verstehen suche ich ein kleines Beispiel zum

.