ganz blĂśde Frage zu den 32 Bittern

M

Marte Schwarz

Guest
Hi,
ich kanns grad nicht ausprobieren, sollte es auch wissen, bin mir
trotzdem unsicher:
Mit einem 32 Bit-ÂľC, wie ESP8266 oder STM32 und Co soll ein Datenlogger
gebaut werden. Sind die Speicherzellen jetzt 32 Bit breit adressiert,
kann ich also mit einfach inkrementierendem Adresszähler gleich int32_t
speichern oder muss ich dafßr je 4 Stellen weiterhßpfen fßr die nächste
Zahl?

Tut mir leid, euch mit so 'nem Kleinkram zu belästigen

Marte
 
Am 25.07.2019 um 09:43 schrieb Marte Schwarz:
Hi,
ich kanns grad nicht ausprobieren, sollte es auch wissen, bin mir
trotzdem unsicher:
Mit einem 32 Bit-ÂľC, wie ESP8266 oder STM32 und Co soll ein Datenlogger
gebaut werden. Sind die Speicherzellen jetzt 32 Bit breit adressiert,

Der Prozessor kann 32bit breite Daten intern verarbeiten. Übblicherweise
kann auch auf jedes Byte des Datenwortes zugegriffen werden.
Benutzt man "C", hat man alle mĂśglichen Formen von Zeigeren, elementar
wäre ein "char*" auf ein einzelnes Byte im Speicher, fßr 32bit kÜnnte
das zB. der Typ "long" sein. Greift die CPU auf den Speicher zu, wird
genau dieser definierte Typ geladen. Ein inkrementieren des Zeigers
addiert im Grunde die GrĂśsse des definierten Typs zur aktuellen Adresse
hinzu.
Bei byteweisem phys. Speicherzugriff mĂźsste die CPU vier
aufeinanderfolgende Adressen einlesen, um auf ein 32bit-Datenwort
zuzugreifen.

Gruss Udo
 
Am 25.07.2019 um 09:43 schrieb Marte Schwarz:
Hi,
ich kanns grad nicht ausprobieren, sollte es auch wissen, bin mir
trotzdem unsicher:
Mit einem 32 Bit-ÂľC, wie ESP8266 oder STM32 und Co soll ein Datenlogger
gebaut werden. Sind die Speicherzellen jetzt 32 Bit breit adressiert,
kann ich also mit einfach inkrementierendem Adresszähler gleich int32_t
speichern oder muss ich dafßr je 4 Stellen weiterhßpfen fßr die nächste
Zahl?

Es werden auch beim 32-Bitter nur Bytes adressiert.

--
Michael
 
On 07/25/2019 09:43, Marte Schwarz wrote:
Hi,
ich kanns grad nicht ausprobieren, sollte es auch wissen, bin mir trotzdem
unsicher:
Mit einem 32 Bit-ÂľC, wie ESP8266 oder STM32 und Co soll ein Datenlogger
gebaut werden. Sind die Speicherzellen jetzt 32 Bit breit adressiert, kann
ich also mit einfach inkrementierendem Adresszähler gleich int32_t speichern
oder muss ich dafßr je 4 Stellen weiterhßpfen fßr die nächste Zahl?

Tut mir leid, euch mit so 'nem Kleinkram zu belästigen

Wenn mit C gearbeitet wird (int32_t), muß man eben den richtigen
Datentyp definieren, um durch Inkrement (++) weiterspringen
zu kĂśnnen.

uint32_t val, *ma = XYZ;

val= ma++; springt dann um 4 Bytes weiter.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
 
Am Donnerstag, 25. Juli 2019 15:32:51 UTC+2 schrieb Helmut Schellong:
On 07/25/2019 09:43, Marte Schwarz wrote:
Hi,
ich kanns grad nicht ausprobieren, sollte es auch wissen, bin mir trotzdem
unsicher:
Mit einem 32 Bit-ÂľC, wie ESP8266 oder STM32 und Co soll ein Datenlogger
gebaut werden. Sind die Speicherzellen jetzt 32 Bit breit adressiert, kann
ich also mit einfach inkrementierendem Adresszähler gleich int32_t speichern
oder muss ich dafßr je 4 Stellen weiterhßpfen fßr die nächste Zahl?

Tut mir leid, euch mit so 'nem Kleinkram zu belästigen

Wenn mit C gearbeitet wird (int32_t), muß man eben den richtigen
Datentyp definieren, um durch Inkrement (++) weiterspringen
zu kĂśnnen.

uint32_t val, *ma = XYZ;

val= ma++; springt dann um 4 Bytes weiter.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm

ja der richtig schlaue Programmierer probiert und findet dies selbst heraus ohne Forum.
 
Helmut Schellong <rip@schellong.biz> wrote:

uint32_t val, *ma = XYZ;

val= ma++; springt dann um 4 Bytes weiter.

| warning: assignment makes integer from pointer without a cast [enabled by default]
| val= ma++;
| ^

Eindeutig wäre

val = *(ma++);
 
On 07/28/2019 22:51, Nomen Nescio wrote:
Helmut Schellong <rip@schellong.biz> wrote:

uint32_t val, *ma = XYZ;

val= ma++;  springt dann um 4 Bytes weiter.

| warning: assignment makes integer from pointer without a cast [enabled by
default]
|  val= ma++; |     ^

Eindeutig wäre

val = *(ma++);
Ich hab den '*' vergessen.
Die Klammern sind nicht nĂśtig.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
 
On 07/25/2019 10:37 AM, Michael S. wrote:

> Es werden auch beim 32-Bitter nur Bytes adressiert.

Rein vom C Standard her gesehen muss das nicht sein, da ein "char" auch
z.B. 16 Bit sein kann. Bis auf Ausnahmen wie alte 8 Bit PIC Prozessoren
mit z.B. 12 Bit Daten pro Adresse, gibt es aber glaube ich keinen
modernen 32 Bit Prozessor, der nicht fĂźr eine Adressposition auch ein
Byte mit 8 Bits annimmt. FĂźr Speicher kann man dabei meist individuell
jedes Byte ansprechen. Bei IO-Registern muss man meist immer 32 Bit
gleichzeitig lesen oder schreiben mit einem Befehl.

Wie das dann intern implementiert ist, ist wieder eine andere Frage. So
gibt es z.B. RISC-V Cores, die 16 Bit direkt in einem Takt auslesen, was
der compressed instruction Größe entspricht (ähnlich dem Arm Thumb Mode,
aber kann generell mit 32 Bit Anweisungen gemischt werden, ohne
Mode-Umschaltung). Da das RAM-Dateninterface auch 32 Bit oder größer
sein kann, und meist Burst-Modes mĂśglich sind, kann dann ein Prozessor
per Pipelining, Caching usw. sogar mehr Instruktionen pro Sekunde
ausfĂźhren, als sein Takt vermuten liesse.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
 
On 30.07.19 07:58, Frank Buss wrote:
On 07/25/2019 10:37 AM, Michael S. wrote:

Es werden auch beim 32-Bitter nur Bytes adressiert.

Rein vom C Standard her gesehen muss das nicht sein, da ein "char" auch
z.B. 16 Bit sein kann.

Womit die Aussage von Michael aber trotzdem richtig bleibt, denn ein
char ist auch laut C-Standard exakt ein Byte groß und kann eben nur dann
z.B. 16 Bit breit sein, wenn ein Byte auch 16 Bit breit ist.

Gruß,
Johannes
 

Welcome to EDABoard.com

Sponsor

Back
Top