-
Thread
Anfänger Microcontroller - bräuchte mal einen rat
reichen für Dich. > Naja dann noch ... Wo ist der Unterschied zu den AMTEL Controllern? Atmel AVR meinst Du. Vorteile AVR: - verbreitet - GCC verfügbar (wie bei PIC24/dsPIC/PIC32) - angenehm in Assembler zu programmieren Nachteile AVR: - AVR Default-Programmierschnittstelle ISP: nur programmieren
PIC: - PIC16/PIC18: sehr alte Architektur, max 3968 Bytes RAM möglich (PIC24: Architektur ähnlich AVR aber 16-bittig, PIC32: MIPS-Kern (vgl alte SGI-Workstations, sehr leistungsfähig) fchk
-
Thread
Hardware TWI,I²C, I²C EEPROM
Chip. Chips mit geringer Kapazität bis 256 Bytes benutzen EEPROM_ADDRESS_BYTES = 1, alle anderen bis 64K EEPROM_ADDRESS_BYTES=2. Desweiteren muß EEPROM_PAGE_SIZE = 32 eventuell geändert werden. Die meisten EEPROM Chips benutzen aber beim Schreiben der Daten einen 32 Bytes Latch. Bei diesem Source wurde
sollte dann doch auch mit 8 gehen!? - Wenn ich Mattias Änderungen in die i2c.S einfüge wirft mir WinAVR einen Fehler aus: i2c.S:42: Error: number must be less than 64 i2c.S:44: Error: number must be less than 64 i2c.S:59: Error: number must be less than 64 i2c.S:63: Error: number must be less than
-
Thread
Kauf- Erfahrungsberatung AVR Programmer
> Was mache ich falsch, daß dieser > "USBASP-Schrott" keinerlei Probleme bereitet. Vielleicht 32 statt 64 BIT OS?
Was mache ich falsch, daß dieser >> "USBASP-Schrott" keinerlei Probleme bereitet. > > Vielleicht 32 statt 64 BIT OS? Da im Screenshot System32 und Syswow64 steht, handelt es sich hier um ein 64 Bit OS!
-
Thread
Stm32f429i-Disco für neueinsteiger
Funktionen hat. (Ja das widerspricht sich jetzt ein wenig, aber die Unterschiede von einem kleinen STM32 zu einem großen ist imho deutlich kleiner als die von avr zu STM32.)
lesen musst und dann die Adresse des Portregisters findest, wo du dann ebenfalls wie beim AVR direkt auf den Port Zugriff hast? Moby AVR schrieb im Beitrag #3785010: > Die Enywicklung geht natürlich weiter hin zu 64 und 128 Bit. Dann sehen > heutige 32Bitter nämlich ziemlich alt aus, während
-
Thread
Atmel AVR Toolchain for Linux
./avr/include/avr/iom32u2.h ./avr/include/avr/io90scr100.h ./avr/include/avr/iom32m1.h ./avr/include/avr/iox128a4u.h ./avr/include/avr/iom64a.h ./avr/include/avr/iom169pa.h ./avr/include/avr/iotn25.
_1.h ./avr/include/avr/iocan64.h ./avr/include/avr/iotn84.h ./avr/include/avr/sleep.h ./avr/include/avr/io43u32x.h ./avr/include/avr/iousb647.h ./avr/include/avr/iotn43u.h ./avr/include/avr/iom64hve.h .
-
Thread
(Umfrage) Was war eure erste Programmiersprache usw.?
hauptsächlich Buskartensteuerung von Messgeräten PC Assembler TurboPascal QuickC, dann TurboC PIC, AVR, 8051, STM32, NXP ARM7 in C Bin halt ein Dinosaurier was Programmieren anbelangt...
um 1990 rum BASIC (c64), dann auch Assembler TurboPascal (Schule, Informatik) Assembler (z80) Assembler (AVR), später C C++/C#/Java (Studium) heute hauptsächlich nur noch C und C#
-
Thread
8 mal 1bit zu einmal 3bit zusammenfassen
mit einem 64kB Eprom als Statemachine
> Hippelhaxe schrieb im Beitrag #7931449: >> Weil die Tabelle zwei Milliarden Zeilen hat. > > 64bit sind irgendwas 10^19 Zeilen, bisschen > mehr als 2Mia. Mea culpa. Ich war gedanklich bei 32bit... es sind also 4 Trillionen Zeilen. > Läuft aber alles auf even/odd parity raus, also
-
Thread
8051 MP3 Player (Web Radio )
Hi, jo der Player weitet oben ist von mir. Er besitzt 32kb ram, den witznet-chip fuers ethernet und einen ti dac fuers audio. Das Display wird seriell angestuert und hat nochmal einen eigenen avr fuer Zeichensatzgenerierung und Displayverwaltung. Ich wollte
@Benny: Man braucht ja nicht gleich 128kB RAM, 64kB (2x32) tun es auch. Auf die Art hast du die volle Ausreizung ohne zusätzliche Banking-Hardware. Man kann ja auch ein zweites RAM vorsehen, wenn man sieht, dass man es braucht, baut man es ein. Somit
-
Thread
AVR gegen den Rest der Welt
nachher sehr vorsichtig, wenn es darum geht, Atmel-Zeugs einzudesignen. Anderes Thema: Abkündigung der AVR32AP7000'er Serie. Das hat etliche Leute kalt erwischt. Atmel hatte einfach nicht die personellen und finanziellen Kapazitäten, um AVR32 und ARM Cortex M3 gleichermaßen zu supporten, und haben bei AVR32
Rolle. GCC erzeugt keinen optimalen Code, weil er eigentlich für 32 Bit Unix-Maschinen gedacht ist, und der Fokus bei der Weiterentwicklung des GCC liegen eher auf x86/x64/ARM/MIPS/PPC. Es kann sein, dass neuere GCC-Versionen größeren Code erzeugen als ältere. Die AVR-Portierung
-
Thread
Keine MCU Auswahl unter Eclipse Juno mit AVR Eclipse plugin
habe jetzt nach diesem Link: http://www.mikrocontroller.net/topic/266246#new als root ar p avr-gcc-4.5.1-avrfreaks-2011-dec-29-u10.04.x64.deb data.tar.gz | tar xzC / ausgeführt. Aber irgendwie habe ich weder die MCU Auswahlliste noch hat sich an as: unrecognized option '-mmcu=atmega32'
auszutauschen der nur ("This assembler was configured for a target of `x86_64-suse-linux'!") x86_64 output erzeugt und demnach auch keine avr mcu option kennt ;)) MCUs werden jetzt auch wirklich angezeigt! Sowohl in der "AVR Supported MCU" Liste (keine roten Kreuze mehr) als
-
Thread
Viel RAM am kleinen Controller
oder AVR32, da gibts auch etliche mit SDRAM Interface. fchk
@ Frank K. (fchk) >oder AVR32, da gibts auch etliche mit SDRAM Interface. Ist mir zu exotisch, da bin ich eher ein Mainstreamer.
-
Thread
Versuch einer Millis Funktion für AVR
Ben S. schrieb im Beitrag #7940601: > 64bit in Mikrosekunden 64 Bit in Mikrosekunden... auf einem AVR? Oder bin ich hier im falschen Thread?
Daniel A. schrieb im Beitrag #7940826: > Schade, das c11 atomics für AVR noch nicht implementiert sind. > (Folgendes ist vermutlich keine gute Idee, war nur mal zum ausprobieren, > was passiert: https://godbolt.org/z/hh8jbfscj) Die 64-Bit und 32-Bit Versionen sind
-
Thread
pgm_read_byte_far
habe mal eine frage, und zwar benutze ich einen Mega128,habe mehre bilddaten im flash ligen alles bis 64K wird korrekt angezeigt aber alles über 64K eben nicht,dann habe ich mit pgm_read_byte_far das ganze versucht, aber das haut auch nich hin. meine bilddaten; #include <avr/pgmspace.h> //WinAVR prog_uchar
pgm_read_byte_far() braucht eine 32-bit-Zahl als Adresse. Zeiger sind im AVR-GCC aber nur 16 bit groß.
-
Thread
Messen mit Atmega16
64K wären z.B 65536... ...
Hi Andi... <Zitat> Es tut mir leid, aber ein Oversampling von 64 ADC Werten (64 * 1023) kann immer noch nicht 65536 ergeben ;-) </Zitat> Das habe ich auch nie behauptet. Ich habe nur behauptet, dass 64K 65536 entspricht... ;-) Ein anderer Weg zur Korrektur
-
Thread
gibts irgendwo eine fertige AVR-GCC Toolchain mit Make fertig..
für Win32/64 ************ top aktuell und mit make.exe **************************** avr-gcc-8.2.0-x64-mingw *********************** http://blog.zakkemble.net/avr-gcc-builds/ abspeichern in C:\Atmel_Toolchain
MitLeserin schrieb im Beitrag #5604473: > für Win32/64 > ************ > top aktuell und mit make.exe > **************************** > avr-gcc-8.2.0-x64-mingw > *********************** > > http://blog.zakkemble.net/avr-gcc-builds/ > > abspeichern
-
Thread
Rücksprungadresse auf dem Stack schwachsinnig?
.. >> das hört sich für mich nicht nach Wortadresse an. > Der Mega128 hat 128KiB Flash, das sind 64Ki Worte... Allerdings steht im Datenblatt 64K Programm Memory 64K sind 64k egal ob 8 16 oder 32 bit breit. Den Zugriff auf den Speicher oberhalb der 64K erfolgt anscheinend anders. Ist hier
die > zusätzliche Register nutzen, um den Adressraum komplett ansprechen zu > können... > >> 64K sind 64k egal ob 8 16 oder 32 bit breit. > 64 K sind zunächst mal nur 64 * 2^10 = 65536. Ohne Einheit dahinter ist > das nur eine Zahl. Und die Einheit steht in diesem Falle direkt > dahinter, nämlich
-
Thread
64 bit? Lohnt sich das wirklich?
meine damit vor allem das aktuelle Windows 7 64 bit oder noch die alte 32 bit nehmen? welchen Vorteil bringt 64 bit real??? was soll damit besser sein?
Bereich kann ich sonst nix weiter sagen, da ich diese nicht kenne bzw. nutze. Alles in allem merkt man 64 bit nur wenn man auch 64bit Programme verwendet, für alle anderen Programm läuft ja eh den 32 bit API von Win. So lange nicht mehr Leute auf 64bit u steigen wird dieses gerangel 32 bit oder 64bit
-
Thread
Schnelle Bitmaske in AVR-Assembler
jedem Zugriff auf die Adresse des statischen Speicherbereichs setzen und den ihn einmalig mit {128,64,32,16,8,4,2,1} initialisieren. Es ist aber nicht der allg. Weg, wie geschrieben.
pop ZL .org (PC+$7f) & $ff80 ;damit's an einer 256 Byte-Grenze losgeht bitmask: .db 128,64,32,16,8,4,2,1 ;1 .db 128,64,32,16,8,4,2,1 ;2 . . . .db 128,64,32,16,8,4,2,1 ;32 ;die Tabelle kann ggf. optimiert werden, falls count niemals einen eingeschränkten Wertebereich überschreitet
-
Thread
ATMega Auslaufmodell?
die > Entwicklung nicht weiter. Atmel wurde 2016 von Microchip gekauft, und die neueren 8-Bit-AVR-Mikrocontroller heißen nicht mehr ATmega, sondern AVRxxxxxx, z.B. AVR64DB48, AVR32DD32.
schrieb im Beitrag #7740644: > Atmel wurde 2016 von Microchip gekauft, und die neueren > 8-Bit-AVR-Mikrocontroller heißen nicht mehr ATmega, sondern AVRxxxxxx, > z.B. AVR64DB48, AVR32DD32. Es gibt auch etliche ATmega mit der "neuen" Architektur. Siehe: https://ww1.microchip.com/downloads/
-
Thread
Wiedereinstieg AVR-Programmierung mit Studio7
Genau, da gibt es weiter unten auch noch meine Version: AVR® Studio v4.19.730 ab 5.1 heisst es "All 8-bit and 32-bit microcontrollers are supported" Wer ARM programmieren will soll doch dafür eine eigene Toolchain benutzen, nur für AVR war die 4.19 die letzte
> Einsatz, privat wie beruflich. Dazu hätte ich eine Frage: Funktioniert bei Dir unter einem X64 BS noch der AVR-ISP MK2? Ich konnte den bei mir nie zum Laufen kriegen. Nur mit AS7 funktioniert der noch.
-
Thread
Noch einer (f8); 8bit-Computing mit FPGA
gleiche Spiel mit 16/8 vs 32 Bit, und dann nochmal mit 32 Bit vs. 64 Bit. Ich sehe den Platz des f8 unterhalb von 32-Bittern wie RISC-V. Wie viel Platz es unterhalb des f8 für diskrete µC noch gibt, weiß ich nicht. Aber irgendwann
und das betrifft harte CPUs und solche die in einen programmierbaren Baustein kommen. Es sind aber 32 Bit-CPUs. Wie wäre es mit einer 64er / 128er?
-
Thread
Lob für usprog
Hallo zusammen! > > Ich wollte hier nur mal meine Freude kundtun, wie gut das Programmieren > von AVR's mit usbprog + AVR Studio + Winavr auf Windows 7 funktioniert! 32 Bit oder 64 Bit Windows 7?
Mein System ist ein ganz normales Windows 7 auf nem 32 Bit Rechner... Also im Prinzip hab ich überhaupt nichts gemacht! AVR Studio mit den USB Treibern installiert. WinAvr installiert Led Blinkprogramm geschrieben Programmiert und fertig Habe
-
Thread
Verständnissfrage zur nötigen Mehrfachmessung eines AD-Messwertes mit µC
mal zu einem sehr gut erarbeitetem Beispiel der Sprud.de_Seite im Anhang. Da steht was von einer 64-fachen Messfolge? Ist diese hier wirklich nötig? Würde da auch zb. 32 fache Messungen ausreichen um nicht unnötig Rechenzeit zu verbraten?? [[https://www.sprut.de/electronic/pic/projekte/luefter
Rudi R. schrieb im Beitrag #6917680: > Da steht was von einer 64-fachen Messfolge? > Ist diese hier wirklich nötig? > Würde da auch zb. 32 fache Messungen ausreichen um nicht unnötig > Rechenzeit zu verbraten?? Unnötig Rechenzeit verbraten ist hier nicht das
-
Thread
Suche 16 bit CPU mit externem Buszugriff
H-G S. schrieb im Beitrag #4575724: > @ARM CPU: > Irgendwas sagt mir dass 32-Bit-Code nicht gesund ist, ich möchte nämlich > gerne in Assembler selber programmieren - daher auch meine Wahl einer > 16-Bit-CPU. > 8 Bit waren einfach zu wenig mit 64kB Adressraum - soviel braucht
avr schrieb im Beitrag #4594766: > Ich weiß nicht was für dich jetzt ein Knaller ist, aber die meisten > 32-bit µCs mit Businterface können auch externen Code ausführen. Und nun nochmal zurück zu den
-
Thread
Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?
Torsten C. schrieb im Beitrag #3891587: > Ich komme auf led_array[sprache][minuten][32] Ja, Du hast recht. Sorry, falsch gerechnet. > Im STM32F103C8T6 64 Kbytes, beim m1284p 128K Bytes. Hm das ist etwas knapp. Beim STM32F4 hätten wir so etwas in der Größe von 1 bis 2MB. > Dann
#3942675: > Ich finde es erstrebenswert, dass wir einen gemeinsamen Code haben, > der sich für ARM und AVR compilieren lässt. Ja, spricht ja nichts dagegen. Die Unterschiede kann man mit [c] #if defined (STM32F4XXX) Hier STM32-F4-Code (Disco und Nucleo) #elif defined (STM32F1XXX) Hier STM32
-
Thread
8-Bit Controller noch zeitgemäß?
guck dir mal STM32CubeMX an). ARM Assembly ist aber halt schon eine andere Hausnummer als 8-bit AVR, logischerweise.
was brauche, kann ich einfach da hin. Ich war halt nur überrascht, das manche Controller von wie STM32 für knapp 50 Cent zu bekommen sind, wobei einige AVR mega teuer sind. Was für tolles Wortspiel :) LG
-
Thread
Ein Bytecode-Interpreter für ATMega644 u.a.
Bytecode-Interpreter braucht ca. 15000 Bytes - je nach Konfiguration mehr oder weniger. Wenn man z.B. die avr-gcc-floats benutzen will, muss man die float(32 Bit) Bibliothek hinzurechnen. Meine float64-Bibliothek (komplett mit allen Funktionen) braucht als Bytecode etwa 5700 Bytes, während sie als compilierter
zwar länger, spart aber Programmspeicher. Beispiel dafür sind etwa die Division/Modulo-Routinen, die avr-gcc von Hause aus mitbringt. > Und wie erwähnt, schneidet mein Compiler bei 32- > oder 64-Bit-Datentypen besser ab, weil die Operationen nicht aus vielen > 8-Bit Operationen zusammengesetzt werden
-
Thread
AVR Videogenerator, 40x25 Zeichen, nur 60% CPU Auslastung !
liegt. Ich habe mit exakt den gleichen Widerständen am Mega8 direkt auf einem Videomonitor (alter C64 Monitor) ein glasklares Bild... Die Ausgangspegel sind ja eh bei beiden AVR´s gleich. Desweiteren läuft mit dem Mega16 bei mir das Bild neben den Verzerrungen durch was direkt auf einen falschen
das 432x576 Pixel die theoretisch mit einem mega8515 und externem SRAM möglich sind. Wenn man den AVR übertaktet natürlich mehr. In diesem Fall würde ich aber zu einem ARM mit 32kByte internem RAM greifen.
-
Thread
Frage zu Datentypen in C++
mh schrieb im Beitrag #6595155: > Ich habe explizit nach 64 Bit Systemen gefragt, bei denen sizeof(double) > == sizeof(float) ist, da es ja "nicht ungewöhnlich" sein soll. Gibt es: GCC für AVR hat nur 32-Bit Floats.
cppbert3 schrieb im Beitrag #6595348: > Verstehe ich nicht, egal ob 32 oder 64 bit system, float(single > precision) sind 4 und double(double precision) 8 bytes, in den letzten > Jahrzehnten... Nicht bei GCC für AVR. Ist aber ein 8-Bit System.
-
Thread
wortbreite void*
hallo, kann mir jemand auf anhieb die wortbreite eines void* in avr-gcc nennen? ich vermute 16 bit. zumindest da beschwert sich der kompiler nicht. vll ist das auch der grund, warum die guten pgmspace-routinen nur bis 64k definiert sind (u.a. ja, ich hab mir ein
In avr/pgmspace.h gibt es ein paar pgm_read_xxx_far Funktionen, denen die Adresse als uint32_t übergeben wird. Damit lassen sich Adressen jenseits der ersten 64KB ansprechen.
-
Thread
SD Karte Speed Up
Deleting files Start writing files 8 15.82s 126.4kB/s 16 12.72s 157.2kB/s 32 11.10s 180.1kB/s 64 10.34s 193.4kB/s 77 10.28s 194.5kB/s 128 9.93s 201.4kB/s Start reading files 8 16.77s 119.2kB/s 16 12.89s 155.1kB/s 32 10.93s 182.9kB/s 64 9.97s 200.6kB
Deleting files Start writing files 8 12.46s 160.5kB/s 16 10.20s 196.0kB/s 32 9.16s 218.3kB/s 64 8.69s 230.1kB/s 77 8.76s 228.3kB/s 128 8.44s 236.9kB/s Start reading files 8 9.78s 204.4kB/s 16 7.37s 271.3kB/s 32 6.17s 324.1kB/s 64 5.57s 359.0kB
-
Thread
ATmega328P; Bit setzen/löschen eines Integers klappt nicht.
Bit-Nummern und den Bit-Masken, über eine Tabelle (Array), nutzen. [c]uint8_t toBitmask[] = {1,2,4,8,16,32,64,128}; uint8_t bitmask; bitmask = toBitmask[0];[/c]
Karl M. schrieb im Beitrag #5256353: > uint8_t toBitmask[] = {1,2,4,8,16,32,64,128}; Aber bitte nur mit const davor und hoher Optimierungsstufe. Wir wollen ja keine Variablen.
-
Thread
Welchen Mikrocontroller für Millisekunden-Stoppuhr?
AVR Datasheet: "Two 16-bit Timer/Counter Type B (TCBn) can be combined to work as a true 32-bit input capture." Damit kann man sehr lange Millisekunden zählen.
Normalerweise meinen Leute hier im Forum den internen R/C Oszillator. Dieser hat bei den klassischen AVR 8 MHz +/-10%, soweit ich mich erinnere. Im gleichen Beitrag wie ich darauf hin der (interne) Quarz-Oszillator > nicht weniger genau, als ein 32 kHz Uhrenquarz ist.
-
Thread
kurze frage zur Init.
> passt ja zumindest dahingehend, dass das Gesamtergebnis ohnehin kaum > noch auf Controllern < 64 KiB sinnvoll zu benutzen sein wird. ;-) M.E. nicht bei einer smarten Assemblerlösung nebst der Implementierung des 64-Bit Move im avr-gcc.
Beitrag #3227045: > M.E. nicht bei einer smarten Assemblerlösung nebst der Implementierung > des 64-Bit Move im avr-gcc. Schon richtig, aber dafür muss erstmal jemand Zeit und Muse haben. (Mit anderen Worten: es muss jemand 64-bit-double so nötig brauchen zusammen mit den übrigen avr-libc-Features
-
Thread
Hausautomatisierung mit Embedded Linux
nur 69$ - also knapp 52€ kosten soll: http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=AVR32NGKit_3_26.html Es ist alles drauf, was man so braucht für die Hausautomatisierung: * AVR32 Risc CPU AT32AP7000 with 140MHz * 8MB Program Flash, 8MB DatFlash, 32MB SDRAM * SD-Card
@ RelaisKarte: Eine Alternative ist zum Beispiel das Grasshopper AVR32 (AP7000) Board. Das kostet 75 Euro und ist komplett opensource (Hardware und Software). * 140MHz max. 200MHz * 64MB SDRAM, 32Bit Datenbus * 8MB Flash * USB-UART via CP2102 vorinstalliert, optional
-
Thread
SDRAM mit Atmega328P
erstmal eine *Anwendung* die die *4Mx16* RAM annähernd braucht, aber sonst mit einem 8-Bit µC mit *32KB* Flash auskommt. Mir fällt keine ein. Klar, an einem Z80 (der nochmal langsamer ist) haben wir auch DRAM betrieben. Aber eben 64KB, meist sogar weniger (weil teuer und 64KB der gesamte Adressraum
32MB SIMM-Modul und SD-Karte an ATMega1284p, auf dem AVR ein ARM Emulator, das ganze bootet Linux... https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit
-
Thread
Machbarkeit - LED-Sternenhimmel mit AVR?
wieso nicht einfach 2 atmegas? dann hast du 64 ports für 64 leds ^^
nur muss man die erstmal bekommen :-) Zumindest als PDIP ist das >nicht so einfach... Nimm einen AVR mega 16, dort kannst du per [[Soft-PWM]] problemlos 32 Kanäle ansteuern. Der ist auch als DIL verfügbar. MFg Falk
-
Thread
Günstiger uC mit hoher Taktfrequenz
auswertung von der Embedded AT91SAM3U CortexM3 mit bis zu 96Mhz (256/52) AT91SAM3S CortexM3 mit bis zu 64MHz (512/64) ST32F10x CortexM3 mit bis zu 72Mhz (1024/96) ST32F2xx CortexM3 mit bis zu 120Mhz ( weiss jemand mehr dazu?) TI Stellaris CortexM3 mit bis zu 100Mhz (256/96) Toschiba CortexM3
Nimm nen AVR und übertakte den ordentlich, der Rekord liegt glaub ich grad bei 32 MHz. :D
-
Thread
1-Wire Slave auf AVR
ausgewählt ISR (INT0_vect) { unsigned char tim0_i, status; status = status_global; #ifdef __AVR_ATtiny13__ DDRB &= ~(1 << ONEWIREPIN); // Pin auf Eingang #elif defined (__AVR_ATmega8__) DDRD &= ~(1 << ONEWIREPIN); // Pin auf Eingang #endif #ifdef __AVR_ATtiny13
Reset-Signale nacheinander gesendet wurden. Das verträgt jetzt der neue Code. Der iButten Viewer32 sendet nachweislich ein den Befehl 64h ich vermute mal zum Temperaturmessen. Habe ich einfach mit eingefügt und nun geht’s ohne Probleme. Für den Counter muss wohl ein Attiny25 herhalten. CRC16 und
-
Thread
Nächster Schritt nach AVR: Empfehlungen gesucht
zu Visual Studio Code. So kannst du für viele unterschiedliche MC programmieren (AVR, ESP32, STM32, RP2040 ...)
ich weiß gibt es keine 64bit ARM-Mikrocontroller (ARMv8-M ist 32bit). Die Cortex-M3 (und später) können 64bit-Werte einigermaßen effizient verwalten, aber sind dennoch 32-Bitter. Die ARMv8.1-M Vector Extensions können auf
-
Thread
Was brauche ich, um am PC etwas C zu programmieren?
Yalu X. schrieb im Beitrag #3595968: > Oder kennt jemand einen C-Compiler, der auf 32- oder 64-Bit-Windows oder > -Linux direkt (also ohne DOS-Box) lauffähigen Code generiert, bei dem > man aber die Int-Größe aber optional auf 16 Bit einstellen kann? Also wenn -std=c99 beim gcc angegeben
16bit-Rechnung auf jeder Plattform erzwingen. Ausgabe des Programms auf x86: [code]16bit Rechnung: 169 32bit Rechnung: 10000 Diese Plattform hat 32bit "int", 32bit "long", 32bit Adressraum.[/code] Auf x86_64: [code]16bit Rechnung: 169 32bit Rechnung: 10000 Diese Plattform hat 32bit "int", 64bit "long
-
Thread
CH32V003 - RISC-V für angeblich $0.10
habe ich ehrlich gesagt nicht verstanden, da fehlt irgendwie > ein Wort. Der bei LCSC gelistete CH32F203F8P6 ist doch der RISC-V, oder? CH32_F_203 ist ARM Cortex-M3 CH32_V_203 ist RISC-V
Gerd E. schrieb im Beitrag #7250462: > CH32_F_203 ist ARM Cortex-M3 > CH32_V_203 ist RISC-V OMG, Danke! Edit: Jetzt habe ich den Fehler, wenn man bei WCH nach CH32V203F8P6 sucht, kommt erst das Datenblatt des CH32F und erst als drittes
-
Thread
Senden einer Infrarotsequenz
Super, die Warnings sind weg! Hier jetzt der Code: [c]void JAPAN(uint16_t data){ uint64_t sequenz = 108016212ULL | ((uint64_t) data << 28); uint8_t parity = ((sequenz & 0xFF0000UL) >> 16) ^ ((sequenz & 0xFF000000UL) >> 24) ^ ((sequenz & 0xFF00000000ULL) >> 32); sequenz |= ((uint64
die hier durchgeführt werden. Das 64Bit-Paket wurde beim AVR-GCC mit der heißen Nadel dazugestrickt, d.h. völlig ohne jegliche Optimierung. Jeder 64Bit-Operator ruft ganze Orgien von MOV/PUSH/POP und sehr lange Funktionscalls auf.
-
Thread
Gefahren bei Interrupts
Wenn du auf einem AVR eine uint64_t verwendest und während des Schreibvorganges dieser variable ein Interrupt auftritt, kann es zu Schwulitäten kommen. Denn eine 64bit Zahl wird durch acht 8Bit Register/Variablen ausgedrückt
andere Strategien sich aneignen. Jaja, der 32 Bit Zugriff ist dort atomar, weswegen das hier gekäute Problem gegenstandslos wird, aber hier geht's mir um das Wegkommen von der archaischen AVR-Denke. W.S.
-
Thread
atmega4808 mit microchip ICD3 programmieren/debuggen UPDI interface
--------------- QUELLE: Atmel.ATmega_DFP.1.7.374.atpack\gcc\dev\atmega4808\device-specs\ ZIEL: avr-gcc Ordner\lib\gcc\avr\x.x.x\device-specs\ Datei: specs* [/code] Zusätzlich habe ich noch die avr-gcc 9.4.0 Version für Linux64 ergänzt so wie ich es bei meiner Toolchain für Windows mache. Meine
attiny1604, 1606, 1607, 1614, 1616, 1617 attiny3216, 3217 attiny1624, 1626, 1627 attiny3224, 3226, 3227 avr128db28, avr128db32, avr128db48, avr128db64 avr64db28, avr64db32, avr64db48, avr64db64 avr32db28, avr32db32, avr32db48
-
Thread
[S] Leute die eine "Grafikkarte" für uC bauen wollen
dauert. Ich denke mit dem AVR32 + S1D13506 bekommt man das gut hin. Ich habe mal in Youtube nach AVR32 gesucht und war überascht, was da grafikmäßig geht. Gut das waren die grossen AVR32, aber die haben da teilweise Computerspiele
Berny wrote: > Ich denke mit dem AVR32 + S1D13506 bekommt man das gut > hin. Ich habe mal in Youtube nach AVR32 gesucht und war überascht, was > da grafikmäßig geht. Gut das waren die grossen AVR32, aber die haben da > teilweise Computerspiele
-
Thread
Bauen oder nicht bauen ?
verbrauchen und gleichzeitig ein paar mehr Farben wie der C64 zu schaffen.
steht immernoch das Angebot das Teil mal an den MIPS TTL Rechner zu stöpseln: http://www.fritzler-avr.de/spaceage2/index.htm Das Speicherinterface ist simpel: - 32Bit Daten (davon wirste ja sicher nur 8Bit brauchen) - 32Bit Adresse, die kann man mit 3 Vergleichern eindampfen auf nCE und Subadresse
-
Thread
avarice keine verbindung zu AVR-Dragon (libusb0.dll?)
"D:\Users\Kucky.ADMIN-PC\Projekts\BotOne"): CreateProcess error=193, %1 ist keine zulässige Win32-Anwendung" Damit kann ich nun garnichts anfangen. Betriebssystem: Windows7 64bit Eclipse: Helios Debugger: AVR Dragon LibUsb-win32-bin-1.2.5.0 Ich weis schon, das hier win32 steht, aber ich
Werde mal nachschauen was bei mir faul ist. Eine Frage aber noch. Ist es richtig, dass der libusb-win32 auch für ein 64bit System geht? Kucky.
-
Thread
avr-libc 1.8.1 freigegeben
, ATxmega256A3BU, ATxmega256A3U, ATxmega256C3, ATxmega32A4U, ATxmega32C4, ATxmega384C3, ATxmega384D3, ATxmega64A3U, ATxmega64A4U, ATxmega64B1, ATxmega64B3, ATxmega64C3, ATxmega64D4 * Contributed Patches: [#3729] Printf for integers speed
Konrad S. schrieb im Beitrag #3778851: > tar xzf avr8-gnu-toolchain-3.4.3.1072-linux.any.x86_64.tar.gz Installieren != Entpacken
-
Thread
Feedback zum Artikel "Plattformunabhängige Programmierung in C"
#3075965: > Die Frage ist auch, wie praxisrelevant eine komplette Portierbarkeit > zwischen einem 64-Bit und einem 8-Bit System überhaupt ist. Da die Portierbarkeit zwischen 8-, 16- und 32-Bit Architekturen ein ziemlich aktuelles Thema ist, kommt es auf eine Vervollständigung durch 64-Bitter nun auch nicht mehr an. Vom Adressraum abgesehen sind die dank dominierendem LP64/LLP64 auch nur falsche 32-Bitter, die besser mit 64-Bit Typen umgehen können als echte 32-Bitter.