-
Thread
Wieso vor allem AVR µCs bei Bastlern?
war mal ein Punkt aber ob Arduino oder PICKit ist egal. Ob auf den Kits nun AVR 8bit, AVR 32bit, PIC 8bit, PIC 32bit, STM32 oder MIPS drauf ist hat mit der Entwicklung nicht viel zu tun, außer man braucht spezielle Dinge die nur XYZ kann :-P AVR 8bit und PIC 8bit dürften 50:50
/ AVR / 8051 groß: MIPS (PIC32) / ARM (LPC2xxx) / Cortex-Mx (STM32, LPC17xx...) (beliebiger Hersteller) Und wenn man schon einen AVR kennt, dann wird man für die kleinst-Anwendungen keinen PIC nehmen
-
Thread
gcc auf dem pc ausführen
Test-Daten (reproduzierbar) zu erzeugen: [c] #include <stdint.h> #include "avrtest.h" uint64_t u64_rand (void) { uint32_t lo = avrtest_prand (); uint32_t hi = avrtest_prand (); return (uint64_t) hi << 32 | lo; } int main (void) { for (int i = 0; i < 6; ++i)
Wert = 0x71e4bc36667f8b1c[/pre] Als Option für avr-gcc brauch's dann noch ein -I$AVRTEST, damit der avrtest.h Header gefunden wird, der avrtest_prand() etc. implementiert. avrtest_prand und LOG_FMT_U64 sind als AVRtest Syscalls implementiert, d.h
-
Thread
MCU mit 64Mbyte RAM
Bei Deinen Randbedingungen (AVR, vom Bastler lötbar) sage ich: vergiss es. Wenn Du etwas haben willst, was in Deiner technischen Reichweite liegt: PIC32MZ1064DAG176 https://www.microchip.com/wwwproducts/en/PIC32MZ1064DAG176
PS: Also diverse ARM-uC wie STM32 können das natürlich auch, aber mir fällt gerade kein fertiges Board mit 64 MB ein. Selbst-Bau ginge damit aber.
-
Thread
1 Durch Division in uC
Wenn ich in Ganzzahlarithmetik einen 32 Bit Kehrwert bilden will, muß ich dann 2^64 (oder 2^63?) durch die 32 bit-Zahl teilen? Das wäre dann ein 64 Bit-Divisor, wenn auch ein sehr einfacher. Oder gibt es einen Trick um mit 32/32 Bit auszukommen? Mit 64/32 klappte das jedenfalls in meinem ersten Versuch, einen hochauflösenden Reziprokzähler zu programmieren. Die 32/32-Bit-Routine von A.Birua ließ sich einfach auf 64/32 erweitern.
-
Thread
AVR: zwei ISR's blockieren sich
hat? MWS schrieb im Beitrag #4023584: > Ein LDS/STS kostet 4 Takte pro Byte, mal 8 sind bereits 32 Takte, da ist > noch nichts inkrementiert, Ein-/Aussprung in die ISR fehlt und Register > sind auch keine gesichert. In Assembler kann man rücksichtslos acht Register (R8 - R15) als 64-Bit Variable
Zu spät aufgestanden? Träum' weiter. LOL > Ein LDS/STS kostet 4 Takte pro Byte, mal 8 sind bereits 32 Takte, da ist > noch nichts inkrementiert, Ein-/Aussprung in die ISR fehlt und Register > sind auch keine gesichert. Hast du es mal probiert? Die AVR haben wunderbar viele Register, vor allem
-
Thread
Vor- bzw. Nachteile AVR / 8051
Add./Sub./Vergleich von 32-Bit Zahlen zeigt, daß diese beim AVR elegant und schnell erledigt werden. Der 8051 hat z.B. nicht einmal einen compare-Befehl. Bei gleicher Taktfrequenz ist ein AVR ein Vielfaches schneller als ein 8051
Programm immer per ISP oder Bootloader in den Flash proggen. Dadurch hat man beim 8051 aber nur insgesamt 64kB für Programm und Datenspeicher (neue, teure und schwer zu erhaltene Exoten vielleicht ausgenommen), beim AVR gehts bis 128kB Programmspeicher und 64kB Datenspeicher
-
Thread
Unterschied zw. 8 und 32bit-Prozessoren
im Beitrag #2932885: > Was sind das fuer Messungen? Sie sind beim Pintogglen schneller als ein 32-Bitter wie der LPC2106, folglich müssen sie zu mindestens 64-Bittern äquivalent sein.
Tom M. schrieb im Beitrag #2932993: > bekannten 8 bittern 16 Bit weit (64 KB Adressraum). Auf moderneren 32 > bittern ist der PC oft 40 bit oder noch grösser Hättest du ein Beispiel eines 32-Bit Prozessors mit einem 40-Bit Program Counter? Wohlgemerkt dem PC selbst, also
-
Thread
Beratung Mikrocontroller
Cortex M3 32bit Evaluation Board (stm32discovery) für rund 8 euro. Da ist der Programmieradapter schon inklusive.
tip schrieb im Beitrag #2511997: > Cortex M3 32bit Evaluation Board (stm32discovery) für rund 8 euro. Oder gleich einen VIRTEX6 als Protokollumsetzer zwischen dem Gerät und einem 64-Bit Vierkernrechner (SCNR) Mal ehrlich, du kennst bestimmt
-
Thread
Arduino: page-write in I2C eeprom verliert sporadisch ein Byte
byte Ser_Arr[31]; > > Sicher, daß eine Page 31 Byte groß ist? > > Ich kenne nur EEPROMs mit 32 Bytes per Page. Das verwendete hat offensichtlich 64 Byte per Page. Der Wire Buffer hat nur 32 Byte Unser Klient möchte nur 30 pro Transfer übertragen.
00 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 16 F1 01 11 21 31 41 51 61 71 81 91 A1 B1 C1 D1 E1 32 F2 02 12 22 32 42 52 62 72 D3 D3 2B 2C 2D 2E 2F 48 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 64 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 80 50 51 52 53 54 55 56 57 58 59 5A 5B 5C
-
Thread
Festkommazahlen in Würde Gesperrt
Anyware::fixpoint< uint32_t, uint64_t, 1 > test_t; typedef uint32_t const_t; const char*t_text="f(32,64)"; //typedef Anyware::fixpoint< uint64_t, uint64_t, 1 > test_t; typedef uint64_t const_t; const char*t_text="f(64,64
4552 | fixpoint<uint16_t,uint16_t,1> | | 30300 | | 4560 | fixpoint<uint16_t,uint32_t,1> | | 12859 | | 4726 | fixpoint<uint32_t,uint32_t,1> | | 12629 | | 4760 | fixpoint<uint32_t,uint64_t,1> | | 626 | | 6528 | fixpoint<uint64_t,uint64
-
Thread
Mikrocontroller - Erste Schritte
weil kompliziert wie ARM und wenig sinnvoll Falsch. >für den selben preis gibts cortex M3 die 32 bi kerne haben und die >entsprechende peripherie auch sinnvoll nutzen können Mag sein, interessiert AVR-Anwender aber nicht. Der XMega setzt da an, wo Anwender keine neue Entwicklungsumgebung, aber
Preis der NIEMAND bekommen kann! du muß aber nur NICHT vergesen, dass du ein Rechner mit Vista 64 Bit hast und auf diese Rechner wird nur der AVR-ISP mkII unter AVRStudio funktionieren, kein andere nachbau funktioniert unter Vista 64! so, jetzt muß du selber entscheiden da haben hier wie "immer
-
Thread
Gibt es den Atmega1284 auch eine Nummer größer?
The ATmega640/1280/1281/2560/2561 Program Counter (PC) is 15/16/17 bits wide, thus addressing the 32K/64K/128K program memory locations."
Frank schrieb im Beitrag #5755525: > STM32 progge ich schon länger, will mir aber die Portierung sparen. Dann war die ganze Mühe rund um 32bit Controller unnötig. Sage so etwas nächstes mal bitte gleich im Eröffnungspost. Um bei 8bit AVR
-
Thread
C - Function / Define / Macro / Obfuscated C ?
#include <stdint.h> #ifndef cmuls #define cmuls(dre, dim, are, aim, bre, bim) \ do { \ int32_t tre; \ (tre) = (int32_t)(((int64_t)(are)* (int64_t)(bre)-(int64_t)(aim)* (int64_t)(bim)) >> 31); \ (dim) = (int32_t)(((int64_t)(are)* (int64_t)(bim)+(int64_t)(aim)* (int64_t)(bre)) >> 31); \
(*dim) = (int32_t)(((int64_t)(*are)* (int64_t)(*bim)+(int64_t)(*aim)* (int64_t)(*bre)) >> 31); (*dre) = tre; } void cmuls3(int32_t* dre, int32_t* dim, int32_t* are, int32_t* aim, int32_t* bre, int32_t* bim)
-
Thread
Einstieg in die ARM Welt
Paganini wrote: > Ist der AT32AP7000 zu empfelen? Das ist kein ARM, sondern ein AVR32!
andere Architektur, beispielsweise AVR32 mal in Betracht ziehen. (Dieser Satz jetzt eher als Diskussionsinput, denn als Meinung.)
-
Thread
AD9850-Modul mit AtMega steuern
Ich hab's mit 64-bit-Integern gelöst. Langsam, aber genau. ;-) [c] #define MASTERCLOCK 99999200ull /* gemessen ;) */ static uint32_t val_to_dds(uint32_t v) { uint64_t x; x = v * 0x100000000ull;
Feedback hinterlassen obs passt oder nicht. Danke. Der Code zum prüfen meiner Lösung (nicht für AVR!) [c] #include <stdio.h> #include <stdlib.h> #include <stdint.h> int main(void) { const uint64_t frequency = 4000000; uint64_t tmp1 = frequency; tmp1 <<= 32; tmp1 /= 125; //
-
Thread
Einstieg 32Bit µC - Welche "Familie"
Ich wollte mal zum Lernen und auch weil es mir für mein "Projekt" sinvoller erscheint mir einen 32Bit µC zulegen. Leider war kaum ein Beitrag der SuFu aktuell genug um auch die AVR32 gescheit abzubilden, oder aber es verlief wie bei dem Beitrag über die Vorteile von 32Bittern bei starker Nutzung
Andreas K. wrote: >wie ist eigendlich so der AVR32 > verglichen mit den Cortex? Hängt der die wesentlich ab oder sind die in > etwa gleich stark? Und noch eine Frage zum AVR32: Also viel tut sich da nicht, aber sie Atmel behauptet das im direkten
-
Thread
Einstieg in 8051 - Atmels AT89S52 oder?
gemeint, also deren ARM-Konkurrenz PIC32 MIPS. AVR werden nicht unterstützt. https://www.segger.com/products/debug-probes/j-link/technology/cpus-and-devices/microchip-pic32-support/ Der J-Link unterstützt nur 8051 mit SWD, also die EFM8
Programmier- und Debuginterface der Microchip PICs (MCLR, PGCLK, PGDAT, VCC, GND). Die zugekauften Atmel AVR Controller haben alle was anderes. Und der JLink kann nur das ICSP vom PIC32, denn da wird das MIPS EJTAG-Protokoll der PIC32 MIPS-Kerne quasi durchgetunnelt, und der JLink kann ja auch MIPS EJTAG.
-
Thread
mal wieder binutils, diesmal v2.37 (avr-gcc)
HOME/toolchain/buildWindows/binutils ../../downloads/binutils/configure --prefix=$PREFIX --target=avr --build=x86_64-linux-gnu --host=x86_64-w64-mingw32 --disable-nls --disable-werror [/c] build: muss Linux 64 Bit, weil gebaut wird unter Ubuntu 20.04 LTS in einer VM. host: ist ja später ein Windows
/binutils ../../downloads/binutils/configure --prefix=$PREFIX --target=avr --build=x86_64-linux-gnu --host=x86_64-w64-mingw32 --disable-nls --disable-werror make -j $JOBCOUNT make install # Zeitnahme TIME_END=$(date +%s) TIME_RUN=$(($TIME_END - $TIME_START)) echo "
-
Thread
STK500v2-Bootloader von Peter Fleury
ohne Source und es gab keine passende Version für meine krummen 12 Mhz. Habe jetzt aber noch frische M32 und probiere das auch mal. Hier noch der Link zur Konkurenz: http://hubbard.engr.scu.edu/embedded/avr/bootloader/index.html
Aus obiger Beschreibung von Dominik habe ich den Verdacht, dass AVRStudio nur max 64 Bytes schickt pro FLASH command, anstelle der Mega32 Pagesize von 128 Bytes. Nun habe ich separate Address-Counter für Erase und Write implementiert. Jetzt sollte es gehen, ich kann es allerdings mangels
-
Thread
TFT an AVR anschliessen
Bild-Daten, die vom MicroController an den DisplayController gesendet werden. Der Programmspeicher des Mega64, mit seinen 64KB ist ja schnell ausgeschöpft! Evtl. auf einer SD-Card? Welches Interface ist zu bevorzugen: SPI, RGB, RD/RW??? Wie siehts z.B. mit dem STM32F4 (32 bit) als Alternative aus, eignet
Interface ist zu bevorzugen: SPI, RGB, RD/RW??? Ich glaub ich hole Popcorn... Im Ernst, der STM32F4xx ist die bessere Wahl als ein Mega64.
-
Thread
floating point coprocessor
Ich benutze schon einen 20MHz AVR. Ich denke, ein FPU ist schneller, weil es 32bit Architektur hat. Lookup-Tabellen habe ich schon einige implementiert, aber für einige Anwendungen müssten sie so groß sein, dass sie nicht in den
Gevorkov schrieb: > Wie kann denn sowas eigentlich sein? das Ding arbeitet mit 30MHz mit > einer 32bit Architektur, und ist dabei genauso schnell, wie ein AVR mit > einer 8bit Architektur und 16MHz An 32 Bits glaube ich eher nicht. Das Äussere passt aber prima zu Microchips 16bittern dsPIC30F2011
-
Thread
avr/iom328p.h ist da, wird aber nicht anerkannt
__AVR_ATmega32C1__) #elif defined (__AVR_ATmega32M1__) #elif defined (__AVR_ATmega32U2__) #elif defined (__AVR_ATmega32U4__) #elif defined (__AVR_ATmega32U6__) #elif defined (__AVR_ATmega64C1__) #elif
#elif defined (__AVR_ATmega64HVE2__) #elif defined (__AVR_ATmega103__) #elif defined (__AVR_ATmega32__) #elif defined (__AVR_ATmega32A__) #elif defined (__AVR_ATmega323__) #elif defined (__AVR_ATmega324P__) #elif
-
Thread
Vista-Treiber für USBProg (avr isp mkII clone)
enthält einen Treiber für Windows XP/Vista 32/64 Bit welcher die Verwendung des AVR ISP mk II Clones unter AVRDude notwendig ist. Nach der Installation dieses Pakets funktioniert USBProg+avrdude auch mit Vista. Die Kommandozeile lautet dann:
enthält einen Treiber für Windows XP/Vista 32/64 Bit welcher die Verwendung des AVR Dragon unter AVRDude notwendig ist. Nach der Installation dieses Pakets funktioniert USBProg+avrdude auch mit Vista. Die Kommandozeile lautet dann: avrdude
-
Thread
128kByte Ram an AVR
den nötigen Addresslatch und eine Addressdekodierungslogik für externe memory mapped Devices. Die 4 32Kb Blöcke des 128Kb SRAMs können über die 2 Bankregister in den 64Kb Addressraum des AVR's eingeblendet werden. Dabei kann jede dieser 32Kb Bänke entweder im oberen oder unteren 32Kb Addressraum des AVRs
Nochmal zum Banking. Der AVR hat 64Kb Addressraum. Dieser teilt sich in 2 AVR-Bänke a 32Kb, nennen wir sie mal AVR_0 und AVR_1. AVR_0 geht von 0x0000-0x7FFF, und AVR_1 von 0x8000-0xFFFF. Es ist klar das je nach AVR Prozessor in
-
Thread
AVR Mega32 auf Pollin Board lässt sich nicht schreiben
Passiert sowohl wenn ich Avr Autodetect einstelle als auch wenn ich Avr Mega 323 eisntelle. Mal mit Mega32 probiert ? Könnte bei einem Mega32 klappen Gruß Wars Das
Habe jetzt das simple Parallel Programmer Kabel von http://s-huehn.de/elektronik/avr-prog/avr-prog.htm nachgebaut. Damit habe ich versuchte den Mega32 auf eine Breadboardschaltung zu porgrammieren. Ergebnis: Funktioniert weder auf Vista64 noch XP32. Daher liegt die Vermutung nahe
-
Thread
AVR, Devices über 64k FLASH erkennen?
Gibt es einen Weg automatisch zu erkennen ob der Code für einen AVR mit <=64k FLASH oder >64k FLASH compiliert wird? Testen auf __AVR31__, __AVR51__ und __AVR6__ fällt mir jetzt dazu ein. Ich bin aber nicht sicher damit alles zu erwischen. Und käme ein __AVR7__
on MCUs with more than 64KB data space, and constant data fetch on MCUs with more than 64KB program space. --- Nur, es gibt doch gar keine AVR mit mit mehr als 64kB Daten? Und versagen würde der Test auf RAMPZ doch nur auf
-
Thread
Eclipse und WinAVR
../timer.c Finished building: ../timer.c Building target: test3.elf Invoking: AVR-GCC C Linker avr-gcc -o test3.elf ./bohrer.o ./display.o ./main.o ./timer.o -lm -Wl,-Map=test3.map --cref --oformat=elf32-avr -mmcu=atmega32 Finished building target: test3.elf Generating Program
information -v --version Display the program's version e:\Programme\WinAVR\bin\avr-size.exe: supported targets: elf32-avr coff-avr coff-ext-avr elf32-little elf32-big srec symbolsrec tekhex binary ihex E:\Programme\WinAVR\utils\bin\make: [sizedummy] Error 1 (ignored) Finished
-
Thread
AVR eclipse error message problem!!
Symbols -> Language auswählen z.B. GNU C -> Add Im "Add symbol" Dialog gibt man bei "Name" den AVR Typ an so wie er in der <avr/io.h> steht. z.B. für ATmega32 = "__AVR_ATmega32__" (ohne "") Das Feld "Value" bleibt frei. Vorraussetzung ist aber, das bei "Includes" der Pfad richtig angegeben
AVRLibC" ist einfach zu unspezifisch. Hast Du konkretere Probleme? Ich benutze unter Ubuntu 12.04, 32bit: Eclipse Kepler AVR Plugin 2.4.1 avr8-gnu-toolchain-3.4.3.1072-linux.any.x86.tar.gz (avr-gcc 4.81, avr-libc 1.8.0, avr8-header 6.2.0.142) avrdude 6.0.1 avarice 2.13 avr-gdb 7.6 Klar gibt
-
Thread
Glühwürmchen in Rotkohlglas gefangen
Samples verschieben und somit kürzere Waves bzw. deren Anzahl verändern. Es sollten dabei 8,16,32,64 Einzelwaves entstehen (links in der Listbox die Anzahl der Einträge). Sollte die Anzahl nicht eine Potenz von 2 sein so musst du im AVR Source in uprdate_fireflies() den Aufruf von lfsr(5) verändern
noch die firefly.h [c] #ifndef FIREFLY_H #define FIREFLY_H #include <inttypes.h> #include <avr/eeprom.h> #include <avr/pgmspace.h> #include "lfsr32.h" #include "wave.h" /* PB2 = = InOut = LED0 PB1 = = InOut = LED1 PB0 = = InOut = LED2 PB5 = = InOut =
-
Thread
Frequenzzähler 1Hz - 40MHz
auch die Erweiterungen für die AVR µP atMega48 - 328 Serie drin ! Der 48 Bit Zähler ist nun 64 Bit und der 24 Bit Zähler kann nun 32 Bit. Entsprechend wurde das Hauptprogramm |main()| angepasst. Alle Änderungen könnt ihr dort
fx = --------- Nx Nref Nref [/c] Wir betrachten nun noch die 64-Bit Arithmetik: "fref * Nx": 32-Bit * 32-Bit liefert ein 64-Bit Ergebnis. "fref" ist ~F_CPU "Nx" setzt sich nun aus einen 16-Bit Software Zähler in Timer0 und den 9-Bits aus HC590 und dem einen
-
Thread
Code wozu dient er?
if (ledTimeout!=0) { ledTimeout--; if (ledTimeout==0) { PORTB |= 64; } } } int main() { // Configure pin direction and pull-ups DDRA = 1|2; DDRB = 1|64; PORTB = 2|4|8|16; DDRD = 1|2|4|8|16|32|64; // Timer 0: fast PWM, prescaler
|| (USIDR==myAddress)) { // Switch activity LED for 80ms on PORTB &= ~64; ledTimeout=20; // 20*4ms // Sende ACK Bit USIDR=0; DDRB |= 32; USISR = (1<<USIOIF) | (1<<USIPF) | (1<<USIDC) | 14; while (!(USISR & (1<<USIOIF
-
Thread
Automarer Zugriff auf 32-Bit Variable die in einer ISR verändert wird
von der millis()-Funktion im Arduino habe ich so etwas in meinem ATmega8 implementiert: [c] uint32_t millis; uint32_t millis() { return millis; } int main() { // Timer2: 8Mhz F_CPU, Prescaler: 64 TCCR2 = (1 << CS22); TIMSK = (1 << OCIE2); OCR2 = 125; .... } ISR(TIMER2
definieren, z.B: so: [c] #include <stdint.h> #include <util/atomic.h> extern volatile uint32_t millis_cnt; static inline uint32_t millis (void) { ATOMIC_BLOCK (ATOMIC_FORCEON) { return millis_cnt; } }[/c] Atomare Typen werden von avr-gcc noch nicht unterstützt.
-
Thread
Kleiner AVR Trick zum schnellen Inkrementen grosser Zahlen
_t bla, blub, usw; void test(void) { inc64(&bla); 5a: 80 e7 ldi r24, 0x70 ; 112 5c: 90 e0 ldi r25, 0x00 ; 0 5e: e9 df rcall .-46 ; 0x32 <inc64> inc64(&blub); 60: 88 e6 ldi r24, 0x68 ; 104 62: 90 e0 ldi r25, 0x00 ; 0 64: e6 df rcall .-52 ; 0x32 <inc64> inc64(&usw); 66: 80 e6 ldi r24, 0x60 ; 96 68: 90 e0 ldi r25, 0x00 ; 0 6a: e3 cf rjmp .-58 ; 0x32 <inc64
-
Thread
Umstieg STM32 auf Atmel SAM Erfahrung
der Atmel IDE hab' ich nach einer Stunde abgebrochen, weil mein Core2Duo Laptop mit 4GB Speicher und 32 Bit Betriebssystem damit hoffnungslos überfordert war. Ohne i7-Prozessor, 64bit Betriebssystem und 8GB Speicher würde ich von dem Atmel Studio auf jeden Fall die Finger lassen (wobei mich nicht wundern
avr schrieb im Beitrag #4043625: > Keine Ahnung was hier anscheinend 90% der Leute falsch machen. 64bit OS? Speicherausbau?
-
Thread
Soft-PWM und Schieberegister / Multiplexen
haltet ihr von diesem Thread zu diesem Thema: >Beitrag "16 Bit Soft-PWM auf (fast) beliebig vielen AVR-Ports" Naja, ein Ansatz, wenn gleich etwas komplizierter. Mit [[Soft-PWM]] aus dem Artikel schafft man 10 Bit Auflösung bei 100Hz und 32 Kanälen auf einem 20 MHz AVR, und der hat dann noch MASSIG
schrieb im Beitrag #3175288: > Problemlos. 16 LEDs a 12 Bit macht 192 Bit / 24 Byte, die taktet der AVR > mit SPI-Modul bei 7 MHz in 27,4us raus, bei 32 LEDs halt in 54,8us. Man > schafft also bis zu 18 kHz Updatefrequnenz ;-) > > Die zeitliche Genauigkeit der Sache liegt ohne Mühe bei 10us, mit
-
Thread
"expected ')' before '*' token" -- Was ist da los?
uint16_t uint_fast16_t; typedef int32_t int_fast32_t; typedef uint32_t uint_fast32_t; typedef int64_t int_fast64_t; typedef uint64_t uint_fast64_t; # 273 "c:/winavr-20070525/bin/../avr/include/stdint.h" 3 typedef int64_t intmax_t; typedef uint64_t uintmax_t; # 38 "c:/winavr-20070525/bin/../avr/include/inttypes.h" 2 3 # 77 "c:/winavr-20070525/bin/../avr/include/inttypes.h" 3 typedef int32_t int_farptr_t;
-
Thread
Attiny Programmierung
Stefan ⛄ F. schrieb im Beitrag #6095926: > Bevor ich mich mit diesen "neuen" AVR beschäftige, schaue ich mir lieber > die STM32 an. Ich denke, davon habe ich langfristig mehr. ... kommt drauf an, wenn es mal um "richtig" low power oder batterie geräte geht sind die neuen avr's
läuft eigentlich immer darauf hinaus, daß man die Bits händisch durch die Gegend schiebt. Und eine 64x64 Multiplikation braucht kaum mehr Code als eine 32x32. Nur mehr Zeit. Falls das ein Problem wird, dann ist man mit einem 8-Bitter (vollkommen egal ob ATMega oder ATTiny) aber sowieso falsch. µC
-
Thread
"echter" double mit AVR-GCC
> auch 64bit FP wird von GCC unterstützt. Auf einem AVR? Das wär ja ganz was Neues. (Wenn FP Floating Point heissen soll)
Mischmasch zwischen 64-bit int und 32-bit float), aber eine effiziente Reihe für den AVR zu entwickeln ist jenseits dessen, was ich aus dem Handgelenk schüttele. (Die GCC-Implementierung bietet natürlich auch noch genügend
-
Thread
Einstieg GDB
\utils\bin;C:\WinAVR-20100110\utils\bin;C:\STW\WinAVR-20100110\utils\bin;C:\HIGHTEC\toolchains\tricore\v4.9.2.0\bin;C:\HIGHTEC\licensemanager;C:\Perl64\site\bin;C:\Perl64\bin;C:\Program Files (x86)\Common Files\Oracle\Java
(x86)\Embarcadero\RAD Studio\8.0\bin;C:\Users\Public\Documents\RAD Studio\8.0\BPL;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\SysWOW64;C:\Windows\SysWOW64\wbem;C:\Windows\SysWOW64\WindowsPowerShell\v1.0;C:\Program Files (x86)\AdminStudio
-
Thread
UVR 1611 (TA), Auswertung DL, Mega88, WinAVR
kann somit auch den Code nicht dementsprechend anpassen. [code]if (TCNT0>80 || TIFR0 ) // TCNT0=64: 64*32us = 2048us[/code] Warum hier 80x32usec? und die Oder-Verknüpfung mit dem Timer Interunpt Flag Register [code]OCR0A = 48; // 1536us[/code] Woher kommen die 1536us? Danke! Gruß Rick
entwickelten Hausautomatisierung. Daneben gibt es noch ca. 40 weitere aktive Teilnehmer, die entweder den AVR oder ESP8266, den ESP32 oder den RP2040 nutzen. Harald
-
Thread
ATmega128 double Werte in Flash (PROGMEM)
int16_t typedef unsigned int uint16_t 32-bit types. typedef long int32_t typedef unsigned long uint32_t 64-bit types. typedef long long int64_t typedef unsigned long long uint64_t [/pre] mit [c]dtostre()[/c] ging es, mit
@Mini Double: double ist im AVR-GCC nur 32 Bit breit. Das stimmt schon so. Es gibt noch keine Implementierung für 64-Bit-Gleitkommawerte. Deshalb sind float und double gleich lang.
-
Thread
Attiny85 mit 64Mhz PLL mehr als 8 bit Halb-Hardware PWM?
Samuel St. schrieb im Beitrag #3267424: > Wenn ich den 64Mhz Timer als Software-PWM verwenden würde bringt das ja > nicht so viel, da der Systemtakt bedeutend langsamer ??? Was? Ein AVR der einen Timer hat der mit 64MHz läuft und das schneller als der
Timer kann auf 32Mhz/64Mhz geboostet werden. Basis dafür ist der interne 8Mhz Takt, unabhängig was man von außen als Takt anschließt.
-
Thread
ich hab gelesen und gelesen, es bringt nichts!
Hallo Tany, da geht hier aus dem Datenblatt nichts hervor. Wo finde ich den Treiber "X64" in AVR Tools?
Nun fällt mir noch was auf: Unter C/Programme X86 befindet sich der Ordner AVR Jungo USB. Öffne ich den kommen wieder 2 Ordner USB32 (unter Eigenschaften hat er 12 Dateien mit 1.276.809 Byte) USB64 ( der hat 12 Dateien mit 1.327.502 Byte) der USB32 ist im Bild zu sehen
-
Thread
Mit Pic32 anfangen
Microcontrollers gestaltet sich nun offenbar schwieriger als erwartet. Eigentlich habe ich gedacht, PIC 32 = 64 Pin's = 64 Led's die gleichzeitig leuchten. Mittlerweile weiss ich (bzw. glaube ich zu wissen), dass es auch andere PIC gibt mit 64 PIN und dass für den Cube nur 32 (I/O ?)-Pins nötig sind und dass
Microcontrollers gestaltet sich nun offenbar > schwieriger als erwartet. Eigentlich habe ich gedacht, PIC 32 = 64 Pin's > = 64 Led's die gleichzeitig leuchten. Mittlerweile weiss ich (bzw. > glaube ich zu wissen), dass es auch andere PIC gibt mit 64 PIN und dass > für den Cube nur 32 (I/O ?)-Pins nötig sind
-
Thread
STM32F103 Bluepill mit 128kb lässt sich nicht flashen
Wert sogar für einen Cortex M4 stehen. Fest steht jedenfalls erstmal nur, dass es kein original STM32 ist. Ein CKS32 kann es meiner Meinung nach aber auch nicht sein, weil der tatsächlich nur 64kB Flash hat.
Thanks, Gerard P.s. Also the windows shell context menu application works nicely in both win7 (32/64) and windows 10.
-
Thread
Wunschliste für einen Xmega Nachfolger
, das ist auch eine etablierte Standardarchitektur, die tausend mal besser durchdacht ist als AVR8 (oder PIC12-24). Die meisten Argumente oben kann man genau so auf die PIC32 ummünzen. Reichelt hat sein Angebot grad fett ausgebaut, ab DIP28 für 5,50€. Wirklich, an all die AVR- und PIC-Fans: Wer
W.S. schrieb im Beitrag #2725953: > lieber eine Fujitsu-FR70-Kern, Bus 32 bittig > herausgeführt und nen eingebauten TFT-Controller. Ja genau, was denn noch, Mensch Leute bleibt auf dem Teppich! Ein XMega ist mal in erster Linie AVR-kompatibel.
-
Thread
Diverse fragen zu Hash Maps in C
7106 16384 17 CRC32_SW 32 38 0.69 5 1176 16384 18 CRC32C_HW64 18 28 0.73 17 1246 16384 19 CRC32C_HW64_B
32 0.53 3 794 16384 18 CRC32C_HW64 17 23 0.54 16 805 16384 19 CRC32C_HW64_B 35 40 0.00
-
Thread
Division mit WinAVR sehr langsam?
- x/16 = 8x/18 - 4x/16 - x/16 = 3x/16 = 0.1875 x zu klein, x/16 raus x/2 - x/4 - x/32 = 16x/32 - 8x/32 - x/32 = 7x/32 = 0.21875 x zu gross, x/32 bleibt drinnen x/2 - x/4 - x/32 - x/64 = 32x/64 - 16x/64 - 2x/64 - x/64 = 0.203125 x zu gross, x/64 bleibt drinnen x/2 - x/4 - x/32 - x/64 - x/128 = ( 64 - 32 - 4 - 2 - 1 ) x/128 = 0.1953125 x Was kleineres als x/128 gibts bei 8 Bit
-
Thread
Windows7 / Parallel-Port Programmer Problem
benutzen, nie wieder ärgern. Das Dragon unterstützt Programmierung und Debugging auch von XMega und AVR32! Nachteil: Ein passendes Gehäuse musst du selbst kaufen.
Eine Frage habe ich doch noch: AVR Dragon unterstützt folgende Typen der AVR-Familie: AT90USB162 AT90USB82 ATmega168 ATmega168P ATmega32 ATmega328P ATmega32U4 ATmega48 ATmega48P ATmega88 ATmega88P ATtiny13 ATtiny13A ATtiny2313 ATtiny25
-
Thread
Kann man denn jetz das hi- und low-byte eines uint16_t effizient lesen in c?
; out.u8[2] = in.u8[1]; out.u8[3] = in.u8[0]; return out.u32; } [/c] Das wurde von AVR-GCC recht effizient umgesetzt. Besser hätte ich es in Assembler auch nicht machen können. Und dann noch, um ein float als int32 zu übertragen ohne Cast: [c] static inline
2] = in.u8[1]; > out.u8[3] = in.u8[0]; > return out.u32; > } Schon mal einen Gedanken an __builtin_bswap32 verschwendet? http://gcc.gnu.org/viewcvs/trunk/libgcc/config/avr/lib1funcs.S?revision=193721&view=markup#l2723