-
Thread
LED_Laufschrift mit Mega 32 und MAX 7219
nochwas ich benutze eine ATmega32 16PU finde diesen baustein aber nicht unter AVR studio, bringt da auch ne warnung, kann mein ganzes problem damit zusammenhänegn???
ok, los gehts Loaded plugin STK500 Loaded plugin AVR GCC Loaded partfile: C:\Programme\Atmel\AVR Tools\PartDescriptionFiles\ATmega32 AVR Simulator: Please wait while configuring simulator... AVR Simulator: ATmega32 Configured OK Loaded objectfile:
-
Thread
Controller mit FPU
m.n. schrieb im Beitrag #3778987: > Selbst ein AVR rechnet locker mit float- (32Bit) oder auch double-Werten > (64Bit) Ist double beim avr-gcc mittlerweile 64 Bits breit?
überhaupt nicht mehr, aber auch eine 64/32-Bit-Division wäre nutzlos, weil die Mantisse des Divisors größer als 32 Bit ist. In diesem Fall muss man über alle Bits der Mantisse des Dividenden iterieren. Da bleibt dem ARM gegenüber dem AVR
-
Thread
Neu hier und Anfängerfragen bezüglich Programmspeicher
Hi > Wenn Du keine Bankumschaltung machen willst ist bei 64KB Schluss bei den >8bittern. Wo steht das? 1. Der Programmspeicher wird in Words adressiert Datenblatt: ...the Flash is organized as 32K/64K/128K × 16 2. Wozu braucht der ATMega 24560/
Programmcounter Datenblatt: ...Program Counter (PC) is 15/16/17 bits wide, thus addressing the 32K/64K/128K program memory locations. MfG Spess
-
Thread
LPC800 existiert (fast) nicht in diesem Forum
Ich mach mal wünsch dir was: TQFP im 0.8 Raster, 32-64 Pins, viel und flexibles I/O welches per interner Switchmatrix auf die Ports configurierbar ist.
Board (Cortex M4 mit 256KB Flash und 64kB RAM) mit einer angepaßten "ARDUINO"-Entwicklungsumgebung. Alle AVR Libraries laufen auch auf ARM!
-
Thread
STM32 - Erster Artikel
- der je nach Anwendung AVR8, MSP430 oder STM32 einsetzt.
= 236 V/a STM32 = 132 Videos / 3a = 44 V/a AVR = 900k / 14a = 64 k/a STM32 = 400k / 3a = 133 k/a ...mal sehen wie es weiter geht...
-
Thread
Suche Programmgerüst: USB-Kommunikation und Daten Ein/Ausgabe Windows
Ben B. schrieb im Beitrag #7414308: > 32 Bit Windows interessiert mich nicht mehr Ja, aber viele Libraries und Verzeichnisse von Windows heißen immer noch so, obwohl der Code darin 64 Bit ist. Als beispiel habe einen Screenshot von der user32
Ordner du schaust. Die 3 Dateien, auf die man am häufigsten als Programmierer zugreift, sind Kernel32.dll, user32.dll und gdi32.dll Und die gibt es ja doppelt, Einmal als 32Bit im Ordner SYSWOW64 und einmal im Ordner SYSTEM32 als 64Bit. Klingt zwar kurios, ist aber so. Und die werden beim Systemstart
-
Thread
Das Ende des Z80
Gerhard H. schrieb im Beitrag #7650682: > Wenn ich mir den Asm-Code eines > 32Bitters anschaue kann ich nur sagen: nein danke. Gerhard H. schrieb im Beitrag #7650977: > Der Spaß hat sich bei mir auf den AVR übertragen. Mindestens so > assemblerfreundlich wie einst der Z80.
ohne blödsinnige Segmentierung. Das Motto "Alles geht mit allem" würde ich in der Tat auch beim AVR für erstrebenswert halten. Ansonsten sehe ich aber für den AVR mit seinen immerhin 32 Arbeits-Registern keine "Nachteile", die nicht unmittelbar aus seiner "Nur 8Bit" Architektur (und entsprechender
-
Thread
Mega32 im C64
unter dem Video steht "Mega32 im AVR" ?!
Jahre alte Stücke bei eBay und sonst wo. Klar) Die Intention dahinter ist, einen fast kompletten C64 mit 8 Bit AVR Controllern zu realisieren, ohne 32 Bit ARM CPUs und sonstiges dafür einzusetzen. Denn dann , lädt man sich einfach aufs Smartphone eine APP runter und spielt damit. Hier geht es um
-
Thread
[Sammelbestellung] µC-Board + RAM
zusammen, Preise für SRAM: 512 k x 8 (4 Mbit): ca. 3,00€ 512 k x 16 (8 Mbit): ca. 3,50€ 4 M x 16 (64 Mbit): ca. 4,75€ Besteht Interesse an einem "Breakout-Board" mit einem µC + RAM? Der CPU-Core wäre noch festzulegen: ARM, AVR, PIC, ... Ich kann mir vorstellen, dass man ab 1000 Stück in China
Beitrag #3598496: > Torsten C. schrieb: >> Wieviel RAM und welcher CPU-Core soll's sein? > CPU STM32 mit FMSC Memory Controller z.B.: STM32F103 Und dann mit 4MiB PSRAM? Das wäre dann die Variante mit dem kleinsten und teuersten Speicher: Ca. 4,50€. avr schrieb im Beitrag #3598480: > Das dachte
-
Thread
Game Boy Emulator auf AVR
sebi707 schrieb im Beitrag #3490201: > Meinst du eventuell dieses (Youtube-Video "Atmel-AVR32 uc3 Gameboy > Emulator") > Video? Das ist jetzt natürlich ein AVR32 und Game Boy Color Emulator. > Ich würde gerne nur den Game Boy Classic emulieren und das auf einem > 8-Bit AVR. Ne, also das war schon ein normaler AVR bzw. Classic-Emulator. Ich habs nur noch dunkel im Kopf, glaub aber dass da sogar zwei ATmega64 drauf waren...
-
Thread
C Code in AVR umwandeln
im Ram gespeichert werden, da dieser beim ATMEGA 32, welchen in verwende, ja 2 KByte groß ist. Ich habe im Programm das 64 Bit Wort in 2 x 32 Bits aufgeteilt. Ist aber eigetnlich nicht notwenig oder ist es nicht möglcihe in 64 Bitword direkt im ATEMGA32
(Helfer,Nullen); strcat(Helfer,s64); strcpy(s64,Helfer); //ltoa (i,s64,2); strcpy (sLOW32, s64+8); //strcpy( Ziel, Quelle) s64[8]='\0'; //setze an der 8 stelle des Hexwert strcpy (sHigh32,s64); lLow32
-
Thread
Z80 Mikrocomputer Bastelei
: > Soweit ich weiß, ist der ATMEGA644 auch nur 8-bit breit. Es gibt auch noch was anderes als AVR. Der Trend geht heute eindeutig zu 32 Bit System. Zumal 32Bit uC heute zum Preis von 8 Bit zu haben sind.
"Es gibt auch noch was anderes als AVR. Der Trend geht heute eindeutig zu 32 Bit System. Zumal 32Bit uC heute zum Preis von 8 Bit zu haben sind." Ja Helmut, das ist mir auch bekannt. Das Problem ist dabei, dass ich wieder von vorne anfangen
-
Thread
Umstieg von ATmega2560 auf STM32F767 ?
anspruchsvoller, was zum Beispiel die > Stromversorgung angeht. Der braucht ggf. 100 mA mehr als ein AVR8. Was ist denn daran anspruchsvoller? Brezensalzer schrieb im Beitrag #5747390: > Schöne Beispiele für richtig "runde" Pakete: STM32F072, STM32F303 > Natürlich bekommst du für diese beiden auch
FPGA? Klingt nach noch mehr Stress. Naja ok, ich versuch erst mal mit AVR32. Meine Frage: AVR32 arbeiten ja bekanntlich mit 3.3v. Ich müsste für jeden Servo für den Signal Logic Level Converter einbauen ?
-
Thread
Avr 8bit VGA
Das von mir in diesem Thread zweimal verlinkte Projekt ("AVR VGA Terminal") macht dasselbe, mit einem (übertakteten) AVR anstelle eines 32-Bit-PICs.
stm32 als GPU für nen 8 bit'ter.. ich weiss nicht, dann lass doch gleich einen "AVR-Emulator" drauf laufen. Oder schneid den AVR-Zopf gleich ab.
-
Thread
Wieso spricht man bei den 8 Bit-AVRs von RISC?
Operationen zu vergleichen, da braucht man eher ganze Funktionen bzw. Algorithmen. Und da kann der AVR u.a. mit seinen schier endlosen Registern (32!) massiv punkten. Der olle 8051 hat nur Akku, B und sonst fast nix. EIN Pointer Register. Der AVR hat drei! Jaja, ich weiß daß der RAM relativ "schnell"
allem bei den ganzen Erweiterungen, dem sei diese Seite hier empfohlen: http://ref.x86asm.net/coder64.html Es gibt viele sinnvolle 1byte/2byte Opcodes auf x86 die auch wesentlich kürzer sind als ihre (32/64bit) RISC Pendants, z.B. "ADD <register>, <register>" oder PUSH/POP, aber natürlich auch Entgleisungen
-
Thread
Art der if-Auswahl nur Geschmackssache?
`Every platform has a ”native” integer size, depending on whether the platform is 8-bit, 16-bit, 32-bit or 64-bit. e.g. On AVR this is 8-bit. Every integer smaller than the ”native” size is promoted to a signed version of the ”native” size. Integers equal to the ”native” size keep their signedness
einfacher? Ähm nein, da ist auch historisch viel Mist gewachsen. Deswegen verwende ich für den AVR prinzipiell nur uint8, uint16, int8, int16. Auf dem PC allerdings habe ich mir angewöhnt, dass ein Zähler von 1 bis 10 durchaus integer sein darf, und damit je nach Maschine 32 oder 64 Bits, weil es
-
Thread
union mit Struktur und Array gleicher Größe?
Compiler darf zwischen den struct-Membern Padding-Bytes einfügen. > > Aber auf einem 8-bitter (AVR) gibt's dazu doch keinen Grund? Mein Haken daran ist, das ich die Daten auf einer 64Bit Maschine erzeugen will und im AVR dann lesen. Das ist hier also durchaus zu beachten ..und zu unterbinden.
Hab ich was überlesen? Ich finde es nicht ..... Wenn die Endianess stimmt sollte man einen 32-Bit oder 64-Bit Compiler mit [c] #pragma pack(1) [/c] dazu bringen dem AVR entsprechend die richtige Union zu generieren.
-
Thread
Baupläne rotierendes Display
per Hallsensor erfasst. Ich werde aber mit diesem Projekt solange warten bis ich mich mit ARM7 oder AVR32 befasse, da es wenig Sinn macht einen AVR für so "große" Displays zu benutzen. Bei hoher Farb- Displayauflösung möchte man ja auch bessere Animationen etc.pp. darstellen und nicht nur einen Font und
von RGB-Displays vielleicht wieder ein wenig näher rücken: Nehmen wir als Grundlage ein Display mit 64 (also 2x32) LEDS und 512 Spalten. Wir wollen volles RGB, das macht 64*512*3 Byte. Das sind 96kB für ein Vollbild. Ich schlage eine einfache Idee vor: Die Reduktion des Bildes auf 256 dynamisch gewählte
-
Thread
AVR Assembler-Frage
; Portausgabe für Bit 64 ldi tmp,0b00100000 ; CompareMatch auf 32 setzen out PortB,tmp ; 32 auf OCR0A schreiben nop ; ich muss hier den nächsten Interrupt von .org 0x0006 auf nop ; timer0_match_bit-32 lenken
; bit-64 sort rol Channel5Value rol Output_tmp3 ; bit-64 sort rol Channel0Value rol Output_tmp2 ; bit-32 sort rol Channel1Value rol Output_tmp2 ; bit-32 sort rol Channel2Value rol Output_tmp2
-
Thread
AVR-GCC 4.7.2 Bug?
@Johann Leider funktioniert bei mir unter Win7 64bit der Simulator nicht. Da kackt mir immer das AVR-Studio ab. Deswegen mache ich das ganze ja per UART, damit ich überhaupt mal was debuggen kann. Leider kann ich das ganze nicht weiter Eingrenzen wie
uint16_t f = 254; // 0x00FE int main (void) { uint16_t vs = -32641; // 0x807F uint32_t u2 = (uint32_t) vs * f; if (u2 != 8355330) abort(); exit (0); return 0; } [/c] Compiliert mit avr-gcc 4.6.2, 4.7.2 und 4.8.0-rc1 vom 6.3.2013 läuft das Programm
-
Thread
einfache Grafikkarte mit 256x252 und 256 Farben für AVR
einfache Menüs, Grafiken, oder kleinere, langsame Animationen (so in der Richtung von Icons, also 32x32 Pixel) sollten ruckelfrei möglich sein. Immerhin hat ein Vollbild ja 64kByte, die auch erstmal erzeugt werden müssen (falls diese nicht nur dumm aus einem Speicher geladen werden).
Das SRAM ist ein normales 64kByte SRAM mit einer Zugriffszeit von <55ns. Da man sowas nur schwer bekommt, verwende ich 2x 32kByte, bei denen alle Pins direkt verbunden sind, außer CS\. Da diese SRAMs nicht mehr hergestellt werden
-
Thread
AVR Tiny Basic Computer mit ATMega1284
Hallo Steve, danke schön. Ja in den 90ern hatte ich auch einen C64. Leider sind die ganzen Emulatoren und Projekte auf AVR Basis erst später möglich gewesen, sonst wären wir alle reich :) Natürlich ist das kein "Wow, sowas ist möglich?" Projekt. Aber für nebenbei
Erde hat jemand vor 10 Jahren etwas ähnliches angefangen, hat aber gleich auf bessere Hardware (PIC32) gesetzt. Von Preis und Aufwand sind Atmega und PIC32 ähnlich, aber der PIC32 ist natürlich um einen Exponenten schneller. https://geoffg.net/micromite.html fchk
-
Thread
Vorteile 32 Bit Controller
obwohl er einen 20-Bit Adressbus hat. * 68000 ist ein 16-Bitter, obwohl er einen 24-Bit Adressbus und 32-Bit Register hat. * Der Pentium ist aufgrund seinen Datenbusses eigentlich ein 64-Bitter, obwohl man sich da aufgrund der 32-Bit Register streiten kann.
Sicht des Programmierers (ISA = Instruction Set Architecture). Und so war 68000 für mich immer eine 32-Bit Architektur mit 16-Bit Bus (der Compiler sah das ähnlich). > * Der Pentium ist aufgrund seinen Datenbusses eigentlich ein 64-Bitter, > obwohl man sich da aufgrund der 32-Bit Register streiten
-
Thread
XMEGA/ AVR-EXPLAIN code examples und Diskussion
@Klaus, Script Kiddi: ihr initialisiert den SDRAM beide mit CLK_PER2 mit 32MHz obwohl der mit 64MHz laufen würde: Gruß Hagen [c] // EBI PORTH.DIR = 0xFF; PORTK.DIR = 0xFF; PORTJ.DIR = 0xF0; // Taktsystem konfigurieren // - 32MHz CLK_CPU, 64MHz
-> 64MHz -> 32MHz CCPWrite(&CLK.PSCTRL, CLK_PSADIV_1_gc | CLK_PSBCDIV_2_2_gc); // 32MHz, 2MHz, ext. 32KHz RTC und PLL aktivieren OSC.CTRL = OSC_RC32MEN_bm | OSC_RC2MEN_bm | OSC_XOSCEN_bm | OSC_PLLEN_bm
-
Thread
C Frage zu Subtraktion
bytes) 1 - FF = 100 (4 bytes) 16 Bit 1 + FFFF = 10000 (4 bytes) 1 - FFFF = 10000 (4 bytes) 32 Bit 1 + FFFFFFFF = 0 (4 bytes) 1 - FFFFFFFF = 0 (4 bytes) 64 Bit 1 + FFFFFFFFFFFFFFFF = 0 (8 bytes) 1 - FFFFFFFFFFFFFFFF = 0 (8 bytes) [/pre] Ausgabe auf AVR: [pre] 8 Bit 1 + FF = 100 (2 bytes) 1 - FF = 100 (2 bytes) 16 Bit 1 + FFFF = 0 (2 bytes) 1 - FFFF = 0 (2 bytes) 32 Bit 1 + FFFFFFFF = 0 (4 bytes) 1 - FFFFFFFF = 0 (4 bytes) 64 Bit [/pre] 64 Bit kann der printf() auf AVR offenbar nicht. Was man hier dennoch schön sieht ist, dass die Größe des Ergebnisses
-
Thread
Programmieren unter Windows 7 64Bit?
?2,501 *Note : USE Parallel LPT Card. Following are the steps to use Ponyprog (with Parallel AVR ISP I/O) in Windows 7 x64 : 1] Install Ponyprog 2.07c on a 32-bit Machine. Copy %ProgramFiles%/Ponyprog2000 Folder to any folder in Windows 7 x64 Machine. 2] Now copy LPTCON.VXD from "System32" folder of 32 bit m/c to "system32" folder of Win7 x64 m/c. 3] GEt DLportiox64.zip. Extract "dlportio.sys" and "dlportio.dll". 4] Copy "dlportio.sys" and "dlportio.dll" to both "Systme32/Driver" and "Ponyprog2000
-
Thread
NFS mit grasshopper / AVR32
15:49 localhost mountd[3162]: authenticated mount request from 192.168.12.2:985 for /home/Superandi/Avr32/rootfs (/home/Superandi/Avr32/rootfs) Sep 16 10:15:49 localhost mountd[3162]: authenticated mount request from 192.168.12.2:985 for /home/Superandi/Avr32/rootfs (/home/Superandi/Avr32/rootfs) Sep
dd if=/tmp/rootfs.avr32.jffs2 of=/dev/mtdblock2 bs=64k das Flash schreiben. Nicht ausschalten, nichts sonstiges machen, bis der Prompt wieder erscheint. Dann einfach resetten und hoffen, daß alles funktioniert. Wichtig
-
Thread
Parallax Propeller
Worauf ich mich einlassen würde wäre ein Microcontroller mit integriertem expliziten Grafikcontroller. (AVR32 hat sowas) Gruß, Christian
Ich habe bereits programmiert auf: Valvo 2650, Motorola 6809, Motorola 68008, Freescale 68HC12, AVR8 und beginne gerade mit AVR32. Jeder dieser Architekturen hat ihre Vor- und Nachteile. Ich habe bis auf den AVR32 jede dieser Architekturen in Assembler programmiert, den AVR8 zusätzlich in C, den AVR32
-
Thread
Ab wann lohnt sich ein 32bit Controller? Compilerkosten?
wenn du 10 FLOPS brauchst. Für 1 DIV je 10 s, es lohn gar nichts. Gibt viele Möglichkeiten für 32-Bit Prozessoren (Hast du schon auf dem Parallax Propeller gedacht ?), PIC32, AVR32, ARMs, ZNEOs, Renesas R32, uvä., und in-zwischen wie den eZ80, H8/300, H8S(X). Eine Möglichkeit wurde sein: deine
Ein 32bitter lohnt sich im Preis. Wenn z.B. die 8bitter pic10/12/16 avr48 .. nicht genügen, wegen zuwenig RAM, ... dann ist meine Wahlt ein 32bitter, außer ein günstiger dsPic (16bit) oder ein siLabs (8bit
-
Thread
C++ DLL in Labview einbinden
C-Umgebung von MinGW > drin. Hab mal die aus meiner (der Ubuntu-) MinGW Distribution angehängt > (32 & 64 bit). Danke, probiere ich aus! > Avr Noob schrieb im Beitrag #3563152: > Niko schrieb im Beitrag #3563175: >> Was ist besser? > Da du aus LabVIEW eh nicht debuggen kannst bietet die
Member-Funktionen einer Klasse exportiert, die direkt aufgerufen werden können. Das ist die DLL die Avr Noob (balze) erfolgreich in LabView verwendet hat. Der Ordner libgcc enthält die libgcc DLL die Hilfsfunktionen für die C Runtime enthält, stammt aus MinGW. Alle DLL's jeweils als 32bit und 64bit
-
Thread
Einheitliche Regel für in C erstellte Variablen, Typen etc
als ein integer mit mindestens 16 Bit Breite laut Standard. Und am PC auf allen relevanten Systemen 32 Bit. Den einzigen integer Typ, den ich vermeide ist "long". Der ist auf unterschiedlichen PC Systemen entweder 32 Bit (Windows), oder 64 Bit (Linux). Das macht nur Probleme. > Das ist schon klar
return count; } [/c] Mal mit drei verschiedenen Typdefinitionen compiliert: [pre] $ avr-gcc -Os -mmcu=atmega328 -S -o default.s test.c $ avr-gcc -Os -mmcu=atmega328 -DTYPE=int -S -o int.s test.c $ avr-gcc -Os -mmcu=atmega328 -DTYPE=int_fast32_t -S -o int_fast32_t.s test.c $ md5sum *
-
Thread
Neuer ATtiny104?
Allerding ist /dieser/ Bug doch nun wirklich schon eine Weile korrigiert, oder? [pre] j@uriah 76% avr-as -mmcu=attiny25 -c foo.s j@uriah 77% avr-objdump -d a.out a.out: file format elf32-avr Disassembly of section .text: 00000000 <.text>: 0: 00 91 40 00 lds r16, 0x0040 j@uriah 78% avr-as -mmcu=attiny10 -c foo.s j@uriah 79% avr-objdump -d a.out a.out: file format elf32-avr Disassembly of section .text: 00000000 <.text>: 0: 00 a1 lds r16, 64 [/pre
-
Thread
Grundlegende Fragen zum Bootloader
page + i). Zu der Page Grösse befrag ich nochmal das Datenblatt, weiß gar nicht mehr wo ich die 64Byte her hatte. (Ging um den Mega 8) Vielen Dank Gruß Philipp EDIT: Laut S.225 32 Words -> 64Bytes
auf ihn existieren und nur eine virtuelle Funktion für seinen Ansprung ist nötig. Aber nun kann AVR Studio mit AvrGCC nicht mehr mithalten. Die Summe aller Segmente ist immer der komplette Flash des mega32. Ich finde keine Option dem LD beizubringen, dass mein mega32 nur ein Flash von 0x3800 hat.
-
Thread
Einfache CPU, einfacher Rechner, nur zum Lernen, Erfahrung?
die konnte man bequem in West-Berlin kaufen und über die Grenze bringen. Oder sich verbaut in einen C64 von Oma mitbringen lassen. Auf der Liste damals standen 32 bit Prozessoren, die aber geliefert werden durften, wenn auf dem pcb der datenbus nur in Hälfte (32 bit) ausgeführt war. > Und daß der U880
So grundsätzlich könnte man sich aktuell ruhig mit einem AVR beschäftigen und (also +) über VM mit DOS z.B. bekannte Algorithmen oder C-Programme mit dem Debug-Programm in Assembler erstellen. Bei dem FreeDOS kann man Debug sogar in 32Bit programmieren, und
-
Thread
Was nehme ich nur?
Guten Morgen, wäre das hier nicht etwas für mein Projekt? http://www.ebay.de/itm/ATMEGA32-minimum-system-board-MCU-AVR-Development-Board-core-board-USB-download-/251176689263?pt=Wissenschaftliche_Ger%C3%83%C2%A4te&hash=item3a7b4c1e6f 32 IO Interface. Sollte reichen. Oder?
zwar nicht nochmal nachgesehen, habe betreffs Mega128 aber noch RXD und TXD im Hinterkopf. > im 64-Pin-TQFP-Gehäuse, darunter AT90CAN32/64/128 und > ATmega641/1281/2561. Tip: Lass die großen AVRs erstmal in Ruhe. Kauf Dir ein paar Tiny2313, stecke einen davon auf ein Steckbrett, lies dessen
-
Thread
Windows7 64bit + AVR ISP MKII - moeglich?
@volatile Welche Betriebssystem hast du genau. Win 7 32bit oder 64bit?
Stefan S. schrieb: > @volatile > Welche Betriebssystem hast du genau. Win 7 32bit oder 64bit? 64bit
-
Thread
48KB SDRam für gcc auf xplain
"-Wl,-defsym=__heap_end=0x80ffff" * sind Pflicht! * avr-size berücksichtigt den dazubekommenen Speicher * nicht! * * 32KHz/32MHz RC-OSC Starten * PLL mit 64MHz Starten * ClkCpu auf
EBI_CS_SDINITDONE_bm)); // warten bis fertig // System Clock initialisieren OSC.PLLCTRL = OSC_PLLSRC_RC32M_gc | OSC_PLLFAC3_bm;// 32MHz/4 * 8 = 64MHz OSC.DFLLCTRL = OSC_RC32MCREF_bm; // 32MHz Rc kalibrieren DFLLRC32M.CTRL = DFLL_ENABLE_bm; // Kalibrierung ein OSC.CTRL |= OSC_RC32MEN_bm
-
Thread
40Bit Datentyp selber basteln
Die .S müssen nur Compilert werden und dann geninkt. Zum verwenden einfach den Datetype uint64_t verwenden. Matthias Hopf (mshopf) hat auch noch welche für 64bit=64bit*32bit und 64bit=64bit/32bit geschrieben. http://www.mikrocontroller.net/topic/186801#1814207 Ich habe für diese Projekt noch eine schellere mul64_32 Variante mit MUL, die nur 177 Ticks benötigt, eingebunden.
-
Thread
ATMega Flash wird langsam knapp. Upgrade o. Plattformwechsel?
Wenn du auf einen ESP8266 oder ESP32 wechselst, hast du Flash ohne Ende und das Netzwerk Interface auch schon dabei. Allerdings sind deren I/O Pins nicht ganz so flexibel einsetzbar, wie du es von deinem AVR gewohnt bist. Eine Kombination
vor main() ins RAM kopiert wird. Und DAS ist vermeidbar. Ja, nun hast DU auch eine Architektur (AVR) gewählt, wo Programm- und Daten in getrennten Adressräumen liegen. Bei anderen Architekturen wie ARM oder MIPS (PIC32) oder x86 ist das nicht so. Bei AVR, 8051 und 8-Bit PIC muss halt der Programmierer
-
Thread
sei nicht schlauer als der Compiler?
verwendet, dann ist Redundanz schlecht vermeidbar. Es gibt zu viele Variationen von Maschinen. Wenn eine 32-Bit Maschine keine 16-Bit Datentypen kennt (32-Bit Transputer), dann sind short=int=long=32. Im LP64 Modell der 64-Bit x86 hingegen besteht keine Redundanz: short=16, int=32, long=64. > Ich bin der
Operandenlänge beachtet. Manche meiner Programme und Libraries gehen zurück auf die 80er Jahre und haben 32bit 68000, 16bit x86, 32bit x86, 64bit x86 und IBM POWER erlebt. Spätere haben AVR und ARM erlebt. Da lohnt es sich, die Datentypen nicht auf direkt auf eine einzelne Zielmaschine zu optimierten, sondern
-
Thread
LCD Library T6963c
Mein komplettes AVR Studioprojekt für den Mega32 pinbelegung steht im headerfile, fertige HEX für 1Mhz liegt bei.
habe gerade "WetterStationDisplay" in WinAvr geladen, versucht die pins anzupassen, kompeliert, gebrannt AVRm32, 2 wagerechte lienien das wars
-
Thread
SPI Interrupt auf MEGA32U4
habe ... Mein "Problem" ist es so : [c] uint8_t spi_receive(void) { /* ONLY FOR MEGA32! */ #if defined(__AVR_ATmega32__) { /* Wait for reception complete */ while(!(SPSR & (1<<SPIF))); } #endif /* ONLY FOR MEGA32U4! */ #if defined (__AVR_ATmega32U4__)
Stimmt dieses '__AVR_ATmega32U4__'? In Assembler kenne ich es nur ohne 'AVR', also z.B. '__ATmega1284P__'.
-
Thread
Fixed-Point Support in avr-gcc?
nächstgrößere Integer- > typ 64 Bit breit ist, den man sich auf dem AVR nicht unbedingt antun > möchte. Die Basisarithmetik ist vorhanden; die saturierenden 32-Bit Multiplikation und Division ist allerdings nicht Assembler-Optimiert
typedef short _Fract fract8_t; typedef _Fract fract16_t; typedef long _Fract fract32_t; typedef long long _Fract fract64_t; typedef short _Accum accum16_t; typedef _Accum accum32_t; typedef long _Accum accum64_t;[/c] Ansonsten klingt das sehr praktisch, vor
-
Thread
Neue AVR Familie - AVR-DA
#6257697: > Nur bei den 24 MHz sind sie etwas sparsam geblieben, wenn > die alten XMegas doch schon 32 MHz konnten. Ich betreibe die mit 48, 56 oder 64MHz ;-)
sich viel weniger einschränken muss bei der Auswahl der Teile die man verwendet. Zurück zu den AVR128DA, wenn die Pins von den 28-Pin Gehäuse nicht reichen hat man da eh gelitten. Das 32-Pin TQFP geht noch wenn man ein wenig Übung hat, die Pins haben 0,8 mm Abstände. Bei den 48-Pin und den 64
-
Thread
XMEGA reif für den produktiven Einsatz?
Ein AVR32UC3L ist in derselben Kostenklasse...
Der AP7000 AVR32 ist doch auch quasi schon wieder abgekündigt oder hab ich das falsch in Erinnerung?
-
Thread
AVR Assembler, Macro, Conditional mit Register
Assembler. Cool. Falls man nur die Auflösung, aber keine große Dynamik braucht, kann man unter AVR-GCC auch int64_t benutzen. Die Winkelfunktionen fehlen dann natürlich. Der AVR-IAR kann auch 64Bit double.
4-6b ; outi16 @0 Ziel, @1 Data16, 4-6c, 8-12b ; outi24 @0 Ziel, @1 Data24, 6-9c, 12-18b ; outi32 @0 Ziel, @1 Data32, 12c, 24b ; outi40 @0 Ziel, @1 Data40, 15c, 30b ; outi48 @0 Ziel, @1 Data48, 18c, 36b ; outi56 @0 Ziel, @1 Data56, 21c, 42b ; outi64 @0 Ziel, @1 Data64, 24c, 48b ; ;====
-
Thread
LED-Matrix, 9x9 RGB, Voll dimmbar
du es sagst :-) stimmt, mir ist entgangen das ich einen propeller programmiert habe und keinen avr. spass beiseite, wie gesagt, die sache mit dem avr ist nur ein test, wieweit man damit kommt. 30hz bei 64rgb leds, und 8 bit tiefe sind fakt. das reicht nicht. (ansatz3) ansatz 1 und 2 sind
@ Dennis (Gast) >30hz bei 64rgb leds, und 8 bit tiefe sind fakt. das reicht nicht. >(ansatz3) Naja, runtimeterror hatte ja mal ein Beispiel für 32 Kanäle, 8 Bit, 440 Hz auf einem 16 MHz AVR. Der war dann aber *ZU*, und für nix
-
Thread
gcc und Optimierung
|= (1<<7); Bit 7 wird gesetzt, Bit 0:6 sind verloren gegangen. > ... > Sind für 4 Byte auch nur 32 solche Konstrukte, die 64 Assemblerbefehle > ergeben. Pinbelegung ist vollständig frei wählbar. + 4 mal Löschen per andi nicht durch Zuweisung. bst und bld brauchen 64 Assembler-Befehle.
übergeben werden sollen und am Ende in welchen Registern stehen. Ich brauche diese Funktion: http://avr-asm.tripod.com/math32x.html (ziemlich in die Mitte scrollen)
-
Thread
pgm_read_byte(); --> Nur für Lower 64k Flash (mega128)???
Error: value of 67785 too large for field of 2 bytes at 0 Als IDE verwende ich die neueste WinAVR Version. Ich sehe zwar dass 67785 zu viel für eine integer variable ist (65535 = 0xffff) aber ich weiß nicht wo das passiert! Kann es sein dass die funktion pgm_read_byte(); nur auf die Lower 64k
eigentlich noch nicht so wirklich beschäftig. Ich hab halt mal eine Makefile mit Program das bei dem WIN AVR paket dabei ist, mfile glaub ich, generiert. Die Arrays wurden bis jetzt ja auch nicht in die oberen 64k geschrieben aber seit mein code mit den Arrays größer 64k ist stehen eben alle neuen arrays
-
Thread
Servo am Mikrocontroller
43.49190247 was dieser Wert bedeutet und wie man auf die 5619 gekommen ist weiß ich zwar nicht, aber die 64 kommt sehr wahrscheinlich aus der tabelle 54 (bzw aus der dem ATMega32 entsprechendem Datenblatt, da der c'T-Bot nen ATMega32 hat....) Im text steht dazu: Das WGM21 Bit sorgt dafür dass der Zähler
darin also keinen Platz. Wenn ich mich nicht irre, rechnet dein Compiler auch nur mit Ganzzahlen. Beim AVR-Assembler z.B. wird (vom Assembler) mit 32-Bit-Ganzzahlen gerechnet. Das Konstrukt: > OCR2 = ((XTAL/64/Timer_2_CLOCK) -1); ist übrigens was für Profis oder Mathematiker, ich habe es gern einen