ftDuino32

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
Karl
Beiträge: 1725
Registriert: 24 Sep 2016, 17:28

Re: ftDuino32

Beitrag von Karl » 28 Mär 2021, 17:49

Hallo MoG,
Wieso fragst Du?
habe heute im Netz im Arduino-Bereich etwas über den DUE mit 32-Bit gelesen.
ESP32 setzte ich mit irgendwas im "Wifi"-Bereich in Verbindung - ESP8266.
Was steckt denn im ESP32, ein ESP-Prozessor-Chip ?
Was heissen die Ausdrücke "ESP32-WROOM" und ESP32-WROVER ?
Im Beitrag von "kräml" scheinen die doch nicht kompatibel zu sein oder ?
Gebe ehrlich zu bald die Übersicht über die ganzen Controllertypen zu verlieren. Zumal
ich heute auch gelesen habe daß die 32-Bit-Welt auch schon als nicht mehr aktuell gesehen
wird und viele Hardware auf 64-Bit einschwenkt, warum auch immer.
Bevor es lästig wird, nehme ich die Fragen zurück und erwarte auch keine Antworten.
Grüße von
Karl

Benutzeravatar
MasterOfGizmo
Beiträge: 2404
Registriert: 30 Nov 2014, 07:44

Re: ftDuino32

Beitrag von MasterOfGizmo » 28 Mär 2021, 18:10

Diese Fragen beantwortet doch ein kurzes Googlen.

Kurze Antwort: In ESP32 stecken als Rechenwerke zwei Xtensa-Cores und eben keine Arms wie z.B im TXT oder im Due.

Mit 32Bit kannst Du in der Regel max. 2^32 Bytes Speicher ansprechen, also 4Gigabytes. Jede Maschine mit mehr als 4 GB RAM ist also zwangsläufig >32 Bit. Das trifft primär auf PCs zu, aber inzwischen z.B. auch auf den Raspberry Pi. Beim ESP32 reden wir über max. 16 Megabytes, also sind 32 Bit völlig ausreichend. Da können 64 Bit sogar nachteilig sein, weil dann viele Operationen mit unnötig großen Zahlenräumen umgehen. Das kostet ggf . Platz und Zeit.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
H.A.R.R.Y.
Beiträge: 1039
Registriert: 01 Okt 2012, 08:38
Wohnort: Westpfalz

Re: ftDuino32

Beitrag von H.A.R.R.Y. » 28 Mär 2021, 18:54

Guten Morgen,
MasterOfGizmo hat geschrieben:
28 Mär 2021, 18:10
Mit 32Bit kannst Du in der Regel max. 2^32 Bytes Speicher ansprechen, also 4Gigabytes. Jede Maschine mit mehr als 4 GB RAM ist also zwangsläufig >32 Bit.
So? Die Maschinen werden nach Anzahl der Adressbits klassifiziert? Warum wird dann ein Z80, 6502 oder gar ATmega32U4 als 8-Bit HW bezeichnet? Zumal der ATmega32u4 gar keine Adressleitungen (aussen am Chip) verfügbar hat. Die alten 8086 mit 20 Adressleitungen werden heute wie damals als "16-Bitter" bezeichnet. Sogar die 8088 mit nur 8 Datenleitungen waren und sind 16-Bit Maschinen.

Meines bescheidenen und möglicherweise falschen Wissens nach, gibt diese Klassifizierung mit n-Bit die Arbeitsbreite des Rechenwerkes (Akku) an. Ob mehr Bits einen Vor- oder Nachteil darstellen, hängt sehr deutlich von der Anwendung ab und vom Befehlssatz der CPU.

Grüße
H.A.R.R.Y.
[42] SURVIVE - or die trying

Benutzeravatar
MasterOfGizmo
Beiträge: 2404
Registriert: 30 Nov 2014, 07:44

Re: ftDuino32

Beitrag von MasterOfGizmo » 28 Mär 2021, 20:31

H.A.R.R.Y. hat geschrieben:
28 Mär 2021, 18:54
So? Die Maschinen werden nach Anzahl der Adressbits klassifiziert?
Nein, das habe ich nicht geschrieben, Sie werden meistens nach ihrer Arithmetik-Breite beschrieben. Für Laien: "kann nativ mit Zahlen bis 255 rechnen -> ist ein 8-Bitter", "kann mit Zahlen bis 65535 rechnen -> ist ein 16-Bitter" usw ...

Und genau das benötigt man in erster Linie zur Adressberechnung beim Speicherzugriff. Wenn eine Maschinen mit Speicheradressen umgehen soll, dann muss sie die auch berechnen können. Deine "Gegenbeispiele" sind 8-Bitter und die 8086-Familie. Die 8-Bitter können tatsächlich kaum mit Ihrem 16-Bit-Adressraum umgehen und nutzen so was wie doppelte Register oder haben eben doch spezielle 16-Bit-Adressarithmetik. Aber direkt adressieren konnten sie Ihren Speicher nicht, wie man z.B. an der leidigen Zero-Page-Nutzung des 6502 sieht. Beim 8086 sah es nicht besser aus, die konnten auch nur mit Ihren Segment-Register-Krücken über den 16-Bit-Adressraum hinaus arbeiten und auch das ging mehr schlecht als recht, weswegen die meisten DOS-Programme nur 64 Kilobytes Speicher genutzt haben und z.B. die meisten Spiele nur Videomodes genutzt haben, die mit 16-Bit adressiert werden konnten. 320x200 Pixel in 256 Farben sind z.B. 64000 Bytes, die man gerade noch mit 16-Bit-Artihmetik adressieren kann, was der Grund ist, weswegen Spiele auf DOS-PCs lange in dieser damals schon nicht zeitgemäßen Auflösung liefen.

Deswegen schrieb ich "in der Regel". Ja, man kann für alles eine Lösung finden und sich irgendwas bauen. Ein 6510 konnte z.B. "Banken" und damit den Adressraum erweitern, der Atmel AVR adressiert Worte statt Bytes und kommt so mit 16 Bit auf 128kBytes usw usw. Und dann gibt es noch den 68000, bei dem sie sich nie ganz einigen konnten, ob er denn nun ein 16- oder ein 32-Bitter ist. Deswegen hieß der Atari-ST auch "ST". Das stand für Sixteen-Thirtytwo.

Wenn Du nicht glaubst, dass der Adressraum der Grund für das Aufkommen der 64-Bitter ist, was ist er denn dann? Es gibt praktisch keine andere Verwendung, die in der Praxis die Verwendung von 64-Bit-Arithmetik benötigt. Alle anderen Berechnungen lassen sich mit 32-Bit-Integer-Arithmetik gut abdecken. Das ist der erwähnte Grund, warum 64-Bit-Arithmetik ein Nachteil ist. Ein 64-Bitter macht nämlich praktisch alle Berechnungen mit 64-Bit-Zahlen und belegt mit denen doppelt so viel Speicher wie ein 32-Bitter und er muss auch doppelt so viele Daten transferieren. Ergo: 64-Bit-Arithmetik zu nutzen macht nur dann Sinn, wenn man es auch für irgendwas dringend benötigt. Und was ist das? Eben der Umgang mit mehr als 4 Gigabyte Speicher.

Zusammenfassend: Die Dinger heißen nicht 64-Bitter, weil sie 64 Adressbits haben. Das habe ich ja auch nicht behauptet. Sie heißen 64-Bitter, weil sie 64-Bit-Arithmetik beherrschen. Aber Karl fragte ja warum man neuerdings 64-Bitter nutzt. Und das tut man, damit man mit einem Adressraum von 64-Bits sinnvoll umgehen kann. Und genau deswegen verbaut man 64-Bitter, sobald man mehr als 4GB Speicher ansprechen will.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

kräml
Beiträge: 151
Registriert: 14 Aug 2020, 06:47

Re: ftDuino32

Beitrag von kräml » 28 Mär 2021, 21:26

Hallo,

um auf die Sache mit ESP32 WROOM und WROVER zurück zu kommen. Für mich war das auch neu, dass der Wrover 4 bis 8MB PSRAM hat. PSRAM steht anscheinend für pseude Static Ram. Wow. Dazu natürlich zwei Fragen:

1. Was sind pseude Static RAM? Statisches RAM ist klar, sind FlipFlops und benötigen kein Refresh. Aber psuedo?
2. Wie stelle ich fest wie viel PSRAM ein WROVER hat? Daraus natürlich die Frage, kann ich auch den 4MB für ftduino32 verwenden?

Wegen inkompatible, sehe das eher so, dass der ESP32 WROOM zum WROVER kompatible ist. Er hat nur zusätzlich RAM. Das ist alles. Für das Projekt ist das wahrscheinlich wichtig, da doch einiges abverlangt wird.

Hab hier mal ein Wrover Eval Board. Mal sehen ...

Gruß Kräml

Lars
Beiträge: 527
Registriert: 25 Okt 2016, 21:50

Re: ftDuino32

Beitrag von Lars » 28 Mär 2021, 21:45

Hallo zusammen,
MasterOfGizmo hat geschrieben:
28 Mär 2021, 20:31
Und dann gibt es noch den 68000, bei dem sie sich nie ganz einigen konnten, ob er denn nun ein 16- oder ein 32-Bitter ist. Deswegen hieß der Atari-ST auch "ST". Das stand für Sixteen-Thirtytwo.
soweit ich mich erinnere, war der Motorola 68000 lediglich ein abgespeckter 68020, der intern 32 bittig arbeitete, aber eine einfachere, kostengünstigere Außenbeschaltung erlaubte. AFAIR konnte man maximal 16 MByte RAM anschließen, weil lediglich 24 Adreßleitungen (2 ^ 24 = 16.777.216 Adressen) herausgeführt waren, was damals relevant sparte und zumindestens für Consumer-Geräte mehr als ausreichend erschien. 68020, 68030 und 68040 waren dann reinrassige 32 Bit-Prozessoren, deren gerades Design beispielsweise Apple ein dem damaligen PC haushoch überlegenen Benutzerkomfort erlaubte, selbst wenn der unter Windows lief und mit höherem Prozessortakt arbeitete. Selbst ein Atari ST war mit seinem 68000 komfortabler und bot mit seiner Oberfläche für lange Zeit deutlich mehr Schwuppdizität als ein PC.
MasterOfGizmo hat geschrieben:
28 Mär 2021, 20:31
Alle anderen Berechnungen lassen sich mit 32-Bit-Integer-Arithmetik gut abdecken.
Naja, ich kenne da Gegenbeispiele, in denen man mit 64 Bit schon besser als mit 32 Bit hinkäme. Mit 64 Bit ließen sich auch große Geldbeträge, Kurse und kalendarische Daten für die meisten Systeme hinreichend genau darstellen und trotzdem in einem Zug laden, während 32 Bit dann sehr wenig sind. Ist natürlich Theorie, wenn Entwicklungssysteme nicht die einfachstmöglichen Darstellungen wählen.

Mit freundlichen Grüßen
Lars

Benutzeravatar
MasterOfGizmo
Beiträge: 2404
Registriert: 30 Nov 2014, 07:44

Re: ftDuino32

Beitrag von MasterOfGizmo » 28 Mär 2021, 22:26

Lars hat geschrieben:
28 Mär 2021, 21:45
soweit ich mich erinnere, war der Motorola 68000 lediglich ein abgespeckter 68020
Nee, der 68020 kam später und hatte einen erweiterten Befehlssatz, Caches, externen 32-Bit-Datenbus usw usw. Im ersten Mac steckte auch der 68000, wie auch im Amiga und im Sega Genesis aka Megadrive usw ... Und ja, der externe Adressbus war nur 24 Bit groß, die Adressregister aber 32 Bit, was eine sehr merkwürdige Programmierung erlaubte. Hat Atari natürlich gemacht und daher liefen die Atari-Betriebssysteme später erstmal nicht auf dem 68020.
Lars hat geschrieben:
28 Mär 2021, 21:45
Naja, ich kenne da Gegenbeispiele, in denen man mit 64 Bit schon besser als mit 32 Bit hinkäme. Mit 64 Bit ließen sich auch große Geldbeträge, Kurse und kalendarische Daten ...
Für Geldbeträge und Kurse nutzt Du eh die FPU und die Fließpunktarithmetik. Das hat mit der hier namensgebenden 64-Bit-Integer-Arithmetik dann wenig zu tun. Und kalendarische Daten speicherst Du auch nur dann in einzelnen Integern, wenn Du sie kompakt und einfach zu handhaben brauchst. Die meisten Systeme nutzen dann aber nach wie vor häufig 32-Bit-Unix-Time, auch die 64-Bit-Systeme.

Es gibt tatsächlich wenig Verwendung für 64-Bit-Zahlen. Und auch bei den meisten Kontobewegungen kämst Du mit den +/- 2 Milliarden, die Du mit 32-Bit darstellen kannst recht weit. Ist ja nicht so, dass ein 32-Bitter nicht auch 64-Bit-Zahlen oder noch viel größere nutzen könnte. Er muss dann halt nur etwas mehr rechnen, was bei den von Dir genanntem Beispielen unerheblich wäre. Aber ob ein Computerspiel zum Verarbeiten von Milliarden einzelner Pixel mit 32 oder 64 Bit rechnet macht dann doch einen Performanceunterschied, wenn da die doppelte Datenmenge verarbeitet werden muss.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
MasterOfGizmo
Beiträge: 2404
Registriert: 30 Nov 2014, 07:44

Re: ftDuino32

Beitrag von MasterOfGizmo » 28 Mär 2021, 22:47

kräml hat geschrieben:
28 Mär 2021, 21:26
1. Was sind pseude Static RAM? Statisches RAM ist klar, sind FlipFlops und benötigen kein Refresh. Aber psuedo?
2. Wie stelle ich fest wie viel PSRAM ein WROVER hat? Daraus natürlich die Frage, kann ich auch den 4MB für ftduino32 verwenden?

Wegen inkompatible, sehe das eher so, dass der ESP32 WROOM zum WROVER kompatible ist. Er hat nur zusätzlich RAM. Das ist alles. Für das Projekt ist das wahrscheinlich wichtig, da doch einiges abverlangt wird.
Pseudo-Static RAM ist DRAM, das aber wie SRAM angesteuert wird und z.B. den Refresh selbst regelt.

Tatsächlich dachte ich der Wrover hat immer 8MB RAM. Aber auch 4MB sollten locker reichen. Nur die paarhundert Kb des Wroom reichen ja schon kaum für die 320x240x2 Bytes Videospeicher fürs Display. Aber ich hsbe ja auch noch den Webserver, Python usw ...

Aber bist Du sicher, dass Du nicht RAM und Flash verwechselst? Die Wrover haben m.E 4, 8 oder 16MB flash aber immer 8MB RAM. Z.Zt habe ich welche mit 4MB flash aber ins finale Gerät kommen 16MB flash ... schadet bestimmt nicht.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Karl
Beiträge: 1725
Registriert: 24 Sep 2016, 17:28

Re: ftDuino32

Beitrag von Karl » 28 Mär 2021, 23:07

Hallo,
danke für eure Fragen und den Erklärungen von MoG.
Das mit den Adressierungen mit 4 - 64 Bit Adressbreite habe bisher gedacht
sowie noch angenommen daß jedes Zeichen in 64 Bit Breite verarbeitet wird.
Wenn ich mich recht entsinne hatten meine Rechner, 286er und 386er, noch einen extra Rechenchip
drin - natürlich nachgerüstet. Der extra Chip wurde nicht von allen Programmen unterstützt. :oops:
Dank nochmal an MoG.
Etwas Off-Topic:
Erinnert mich noch an die 286er Zeit mit 40 MB-Festplatte die angeblich unter DOS nie
voll zu bekommen sei. Dann mit dem 286er und den 40 MB, erst recht mit dem 386er unter
WIN 3.1 fingen die Platzprobleme auf der "Rotationsplatte" für die Daten, immer schneller werdend, an.

Nachtrag: Haben die ESP32 auch EEprom an Bord ?
Grüße von
Karl

Benutzeravatar
The Rob
Moderator
Beiträge: 946
Registriert: 03 Dez 2015, 12:54

Re: ftDuino32

Beitrag von The Rob » 29 Mär 2021, 00:05

Von mir auch vielen Dank an MoG für diese äußerst ausführliche Auflistung.
Den Hintergrund von 32bit zu 64 kannte ich schon, aber das ganze mal mit dem historischen Kontext zu betrachten finde ich sehr interessant.

Benutzeravatar
H.A.R.R.Y.
Beiträge: 1039
Registriert: 01 Okt 2012, 08:38
Wohnort: Westpfalz

Re: ftDuino32

Beitrag von H.A.R.R.Y. » 29 Mär 2021, 08:22

Hallo zusammen,
kräml hat geschrieben:
28 Mär 2021, 21:26
1. Was sind pseude Static RAM? Statisches RAM ist klar, sind FlipFlops und benötigen kein Refresh. Aber psuedo?
MasterOfGizmo hat geschrieben:
28 Mär 2021, 22:47
Pseudo-Static RAM ist DRAM, das aber wie SRAM angesteuert wird und z.B. den Refresh selbst regelt.
PSRAM ist außerdem eine neue Art serielle Speicher. Du kennst (hoffentlich) diese kleinen EEPROMs für I²C (24xx)? Die gibt es auch für SPI (25xx). Und seit einiger Zeit gibt es solche kleinen 8-beinigen Chips auch als RAM für SPI. Das macht auf den ersten Blick keinen Sinn, jedoch gibt es MCUs die das per Hardware einfach so in den Adressraum einbinden. Transfertakte sind jenseits der 100 MHz.

Übrigens gibt es für SPI Schnittstelle auch FRAMs - Ferroelectric RAMs.

Grüße
H.A.R.R.Y.
[42] SURVIVE - or die trying

Benutzeravatar
MasterOfGizmo
Beiträge: 2404
Registriert: 30 Nov 2014, 07:44

Re: ftDuino32

Beitrag von MasterOfGizmo » 29 Mär 2021, 08:52

H.A.R.R.Y. hat geschrieben:
29 Mär 2021, 08:22
PSRAM ist außerdem eine neue Art serielle Speicher.
PSRAM hat mit seriell nichts zu tun, das tritt hier nur zufällig zusammen auf. Der alte 3com Palm-Pilot hatte z.B. nicht-serielles PSRAM.

https://de.wikipedia.org/wiki/Pseudostatisches_RAM
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
steffalk
ft:pedia-Herausgeber
Beiträge: 1530
Registriert: 01 Nov 2010, 16:41
Wohnort: Karlsruhe
Kontaktdaten:

Re: ftDuino32

Beitrag von steffalk » 29 Mär 2021, 10:17

Tach auch!

Nur am Rande:
Für Geldbeträge und Kurse nutzt Du eh die FPU und die Fließpunktarithmetik.
Höflicher Einspruch: Bei Geldbeträgen machst Du kein Fließkomma, weil Du keine 3,98999999999 € haben willst. Da macht man integers (und gerne 64 bit, oder sogar BCD), dezimalpunkt-skaliert auf 0, 2, 4 oder was auch immer für Nachkommastellen, damit Du ja keine komischen Rundungsfehler bekommst.

Gruß,
Stefan

Benutzeravatar
H.A.R.R.Y.
Beiträge: 1039
Registriert: 01 Okt 2012, 08:38
Wohnort: Westpfalz

Re: ftDuino32

Beitrag von H.A.R.R.Y. » 29 Mär 2021, 10:30

Hallo MoG,
MasterOfGizmo hat geschrieben:
29 Mär 2021, 08:52
PSRAM hat mit seriell nichts zu tun, das tritt hier nur zufällig zusammen auf.
Jo, stimmt. Im Zusammenhang mit den ESP32 wird allerdings auch gerne das SPI PSRAM als PSRAM bezeichnet. Eigentlich spielt es ja auch gar keine Rolle denn RAM ist RAM (der logischen Funktion nach), oder?

In dem Zusammenhang mag ich verlinken was Espressif selbst zum Thema erklärt. Wie dort bereits zu lesen, mehr als 4 MByte gibt es nicht. Siehe auch ESP32 - How To Use PSRAM. Vielleicht hilft es Euch ein wenig weiter.

Zum anderen Punkt war der Stefan war jetzt schneller.
steffalk hat geschrieben:
29 Mär 2021, 10:17
Für Geldbeträge und Kurse nutzt Du eh die FPU und die Fließpunktarithmetik.

Höflicher Einspruch: [...]
Genau. Bei Banken läuft das ganze Geschäft (immer noch) auf BCD-Darstellung.

Grüße
H.A.R.R.Y.
[42] SURVIVE - or die trying

kräml
Beiträge: 151
Registriert: 14 Aug 2020, 06:47

Re: ftDuino32

Beitrag von kräml » 29 Mär 2021, 10:32

Hey,
MasterOfGizmo hat geschrieben:
28 Mär 2021, 22:47

Tatsächlich dachte ich der Wrover hat immer 8MB RAM. Aber auch 4MB sollten locker reichen. Nur die paarhundert Kb des Wroom reichen ja schon kaum für die 320x240x2 Bytes Videospeicher fürs Display. Aber ich hsbe ja auch noch den Webserver, Python usw ...

Aber bist Du sicher, dass Du nicht RAM und Flash verwechselst? Die Wrover haben m.E 4, 8 oder 16MB flash aber immer 8MB RAM. Z.Zt habe ich welche mit 4MB flash aber ins finale Gerät kommen 16MB flash ... schadet bestimmt nicht.
Hab mir follgendes gekauft:

https://www.ebay.de/itm/WEMOS-LOLIN-D32 ... SwJQVcVxrw

In der Beschreibung fand ich NACH dem Kauf die Angabe von 4MB PSRAM. Hab daher mal nachgeschaut. Es gibt den WROVER-B in der ersten Version mit 4MB. Den WRoverE kann man mit 4MB bekommen. In der Regel wird dieser mit 8MB ausgeliefert. Daher meine Frage über Auslesen bzw. bestimmen der PSRAM Größe. Werde mich mal schlauer machen.

Das gut Teil von oben ist da. Meldet 16MB Flash. Nur keine Angabe über PSRAM mit esptool.py. Mal sehen ...

Gruß Michl

Benutzeravatar
MasterOfGizmo
Beiträge: 2404
Registriert: 30 Nov 2014, 07:44

Re: ftDuino32

Beitrag von MasterOfGizmo » 29 Mär 2021, 11:24

steffalk hat geschrieben:
29 Mär 2021, 10:17
Höflicher Einspruch: Bei Geldbeträgen machst Du kein Fließkomma
Ok, das sehe ich ein.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
MasterOfGizmo
Beiträge: 2404
Registriert: 30 Nov 2014, 07:44

Re: ftDuino32

Beitrag von MasterOfGizmo » 29 Mär 2021, 12:35

kräml hat geschrieben:
29 Mär 2021, 10:32
Hab mir follgendes gekauft:
Wow, da hast Du Dich ja richtig in Unkosten gestürzt.

Bei mir zeigt Micropython dies an:

Code: Alles auswählen

>>> import gc
>>> gc.mem_free()
1448816
>>> gc.mem_alloc()
2649536
Also insgesamt auch nur 4MB RAM. Ich bin mir recht sicher, dass das Board eigentlich 8MB haben sollte. Aber das sollte dann auf Deinem Board auf jeden Fall auch gehen. Da muss ich mich tatsächlich mal schlau machen, warum Micropython nur 4MB nutzt.

Edit: Hab das hier im MicroPython gefunden:

Code: Alles auswählen

    switch (esp_spiram_get_chip_size()) {
        case ESP_SPIRAM_SIZE_16MBITS:
            mp_task_heap_size = 2 * 1024 * 1024;
            break;
        case ESP_SPIRAM_SIZE_32MBITS:
        case ESP_SPIRAM_SIZE_64MBITS:
            mp_task_heap_size = 4 * 1024 * 1024;
            break;
Sie nutzen anscheinend nie mehr als 4MB, auch wenn 8MB da sind. Ich versuche mal raus zu bekommen warum.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

kräml
Beiträge: 151
Registriert: 14 Aug 2020, 06:47

Re: ftDuino32

Beitrag von kräml » 29 Mär 2021, 14:16

MasterOfGizmo hat geschrieben:
29 Mär 2021, 12:35

Wow, da hast Du Dich ja richtig in Unkosten gestürzt.
Das war am schnellsten zu bekommen und wollte wissen was ein WROVER ist. Nebenbei Fischertechnik ist kein billiges Hobby. Das mit dem ESP finde ich total spannend.

Hab auch ein paar Wrover aus Asien bestellt. Die brauchen aber noch etwas.

Wäre doch schön, wenn für den ftduino32 auch mehr RAM da wäre.

Kräml

Benutzeravatar
MasterOfGizmo
Beiträge: 2404
Registriert: 30 Nov 2014, 07:44

Re: ftDuino32

Beitrag von MasterOfGizmo » 29 Mär 2021, 14:50

Hatten wir's nicht gerade von Adressräumen und deren Größenbeschränkungen? Der ESP32 kann wohl max 4MB SPIRAM linear adressieren:

https://docs.espressif.com/projects/esp ... himem.html

Der Rest wird über eine "Himem"-API angesprochen und das ist aufwändig und Micropython unterstützt das nicht. Ergo: Dein ESP32 mit 4MB SPIRAM ist völlig ok, mehr ist eh unter MicroPython nicht zu nutzen.

Interessanter Name "himem". Das ist bestimmt kein Zufall. Den kennt man aus der 8086-Welt: https://de.wikipedia.org/wiki/HIMEM.SYS. Das ist genau die alte "DOS-.PC muss um drei Ecken an seinen Speicher ran"-Sache, die ich eingangs erwähnt habe.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

kräml
Beiträge: 151
Registriert: 14 Aug 2020, 06:47

Re: ftDuino32

Beitrag von kräml » 29 Mär 2021, 16:14

MasterOfGizmo hat geschrieben:
29 Mär 2021, 14:50
Hatten wir's nicht gerade von Adressräumen und deren Größenbeschränkungen? Der ESP32 kann wohl max 4MB SPIRAM linear adressieren:

https://docs.espressif.com/projects/esp ... himem.html

Der Rest wird über eine "Himem"-API angesprochen und das ist aufwändig und Micropython unterstützt das nicht. Ergo: Dein ESP32 mit 4MB SPIRAM ist völlig ok, mehr ist eh unter MicroPython nicht zu nutzen.

Interessanter Name "himem". Das ist bestimmt kein Zufall. Den kennt man aus der 8086-Welt: https://de.wikipedia.org/wiki/HIMEM.SYS. Das ist genau die alte "DOS-.PC muss um drei Ecken an seinen Speicher ran"-Sache, die ich eingangs erwähnt habe.
Habs auch gerade so verstanden. Mich erinnert dies an den VC64 mit 1MB Speicher Erweiterung in meiner Ausbildung. Das lief auch ab und an recht gut. Meist aber nicht.

Dann ist ja mal alles gut mit 4MB PSRAM. Ich hoffe das reicht noch für das ftduino32 Projekt. So wie ich es verstanden habe, kann man den himem Bnutzen um statische Daten wie Video, Musik dort abzulegen. Evtl. gibt es ja eine Möglichkeit für denftduin32. Da aber mircorpython davon keinen Gebrauch macht, ist das eh hinfällig.

Andere Frage:

Wie erstelle ich die Firmware für ftduino32?

Wenn ich das auf github richtig verstehe, soll man Micropython mit den Patches installieren. Das ist rechtes Neuland für mich. Gibt es im Netz eine gute Anleitung? Oder hab ich das falsch verstanden? Würde gerne mal meinen Rover eine ftduino32 Firmware verpassen.

Gruß Kräml

Antworten