-
Thread
Umwandlung eines Strings (hex) in Long Long int
String schon abgearbeitet: *p_dest = 0; } // weiter zu nächstem Byte in der uint64_t: p_dest += offset; } } int main( int nargs, char **args ) { char meintollerstring[] = "10ff00a3001"; uint64_t ganzlang = 0x0ULL; szhex2uint64( meintollerstring, &
Klaus Wachtler schrieb: > Grob gesagt sind Intel+AMD littele endian, der Rest (inkl. AVR) > big endian. Das mit dem AVR = big endian war nicht so wirklich ernst gemeint, oder? ;-)
-
Thread
1024 Lämpchen ansteuern (dimmen)
Sagen wir also das Modul bekommt einen RS-485 Ein/Ausgang. Für 1024 Kanäle muß man jetzt nur noch 64 von diesen Modulen bauen. Nach DMX-Spec darf man bis 32 Geräte daisy-chainen. Aber vielleicht läßt man sich besser etwas Luft und schaltet immer nur 16 Module zu einer Kette. Dann braucht man insgesamt
womit sich sicherlich 16 sinnvolle Helligkeitsstufen abbilden lassen. http://www.mino-elektronik.de/AVR_PWM_64/AVR_PWM_64.htm
-
Thread
AVRISPmkII + AVRDUDE + Window Vista ein Tipp!
Marius Wensing wrote: > Also unter Vista 64 funktioniert es definitiv nicht. Heißt ja auch libusb-win32...
Es geht! (bis jetzt zumindest) Konkret sieht meine Konfiguration so aus: Vista Ultimate SP1 (32bit) AVR Studio 4.16 WinAVR-20090313 Eclipse for C/C++ Developers (Ganymede 3.4.2) AVR Eclipse Plugin 2.3.1 libusb-win32-filter-bin-0.1.12.1 (mit Installer installiert, siehe unten) Sowohl mit
-
Thread
Genervt über Feature-Politik von Atmel - ATmega/ATtiny
Und MISO, der würde sonst kurzgeschlossen mit dem jeweils anderen AVR. Oder?
teile sind schon eindrucksvoll. Vielleicht teste ich die doch mal bzw. bevor ich mich in Xmegas und AVR32 einarbeite werde ich doch wohl mal mit diesen Teilchen beschäftigen. Vielleicht macht es wirklich Sinn wenn es nicht auf Kosten ankommt mal mit ner Kanone zu schießen. ;-) Ich gebe gerne zu, dass
-
Thread
Nach fast 3 Jahren fehlerkorrigiertes Datenblatt für die AVR-DB Serie erschienen
Client. https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR128DB28-32-48-64-DataSheet-DS40002247A.pdf
Nun gibt es schon die AVR_DU-Datenblätter: AVR64DU-28-32-Prelim-DataSheet-DS40002548.pdf AVR32-16DU-14-20-28-32-Prelim-DataSheet-DS40002576.pdf
-
Thread
Frage zu "sections" im ext. memory
jeder Zeit noch Änderungen am Memory Banking Konzept durchführen, falls sie eben die Arbeit mit WinAVR und AVRStudio sinnvoller machen sollten. Momentan sieht es so aus, für einen ATMega128: Die internen 64Kb MemorySpace sind primär in zwei Bänke aufgeteilt. 0x0000-0x7FFF Bank 0 0x8000-0xFFFF Bank
Hier mal eine kleine Grafik, vielleicht wirds dadurch besser verständlich. Links die 64Kb des AVR's, rechts der 512Kb SRAM. Rot die Bank 0 im AVR und grün die Bank 1. Rechts neben dem 8Bit großen Memory Bank Register der hypothetische Wert von 0x72. Die 2 selektiert also die Bank 2 des
-
Thread
Radig NetIO Atmega644P Scannerzeile auslesen
(__AVR_ATmega1284P__) #define ETH_INT_ENABLE EIMSK |= (1<<INT2) #define ETH_INT_DISABLE EIMSK &= ~(1<<INT2) #endif [/c] im enc28j60.c [c] #if defined (__AVR_ATmega32__) #define
[/c] Das sieht bei mir auch so aus. > im enc28j60.c > [c] > #if defined (__AVR_ATmega32__) > #define ETH_INT_ENABLE GICR |= (1<<INT2) > #define ETH_INT_DISABLE GICR &= ~(1<<INT2) > #endif > > #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) |
-
Thread
ARM - µC
z.B: AT91SAM7S64 bei ebay Feadi
wichtigsten Bauteile bekommt man bei Digikey zu fairen Preisen: 128Mbit SDRAM (ca 20 Euro fuer 64Mbyte) 64Mbit Parallelflash (ca 18 Euro) 32Mbit Seriel Dataflash (ca 11 Euro) Die Bauteilkosten sind relativ gering. Der Platinenpreis für 4 Lagen 1/2 Europlatine ist viel zuteuer Beispiel Prototyp
-
Thread
Faktensammlung Buderus EMS
Ok, ist im Wiki eingepflegt. Verdächtig ist noch Byte 7: bei mir 0x64 (warscheinlich 100%) bei Dir 0x32 (warscheinlich 50%). Ideen? Zum Rest fällt mir erstmal nichts ein. vg Jürgen
AlexS schrieb im Beitrag #5849761: > 00000210 10 08 1a 00 25 64 64 00 e1 01 10 92
-
Thread
sprintf: was ist falsch?
auf uint64_t oder uint32_t in Betracht gezogen werden, evtl. auch Fixed-Point aus stdfix.h. Dazu müsste man aber erst die benötigten Operationen / Algorithmen kennen.
denn der kann kein double. > Doch! ich habe hier in Forum eine Bibliothek gefunden! Äh, nein. Der AVR kann kein double. Die avr-libc kann auch kein double. > Dort sind double mit Hilde von u64 gemacht. Dann ist das Fließkommaarithmetik auf u64, kein double. Das funktioniert nicht mit den normalen
-
Thread
64-bit datentypen problematisch auf dem AVR?
Rechenoperation mehrere Faktoren zusammenrechne, die ich dann am Ende erst runden mag reichen mir leider 32 Bit nicht aus, ich brauche mehr.. 64. Wenn ich allerdings einen uint64_t verwende bläht das meinen Flash und den Ram extrem auf. Was kann man da tun? Gibt es noch ne alternative Vorgehensweise?
sie werden > beim Beu des GCC automatisch generiert. Das gilt heutzutage nicht mehr: Seit avr-gcc 4.7 sind die Operationen für 64-bit skalare Interer auch in Assembler, siehe zB die Erklärung in http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr-dimode.md?view=markup Das liesse sich zwar
-
Thread
Kleines Tiny13 Sensorboard
geschrieben, dass der Tiny13 der kleinst ist der in frage kommt, also ist alles mit Flash <= 1KB, SRAM <= 64B und 32 Register keine verschwendung. Bei einem Fertigen Produkt hat niemand etwas davon ob jetzt 0, 20, 100 oder 200 bytes Speicher frei sind. Die einzige Ressource die man eventuell verschwendt hat
Carl. Die Spitzfindigkeit ist, im Nachhinein den anderen vorzuschreiben, daß sie nur die unteren 32 Byte RAM und nicht auch die oberen 64 benutzen sollen. Wer halbwegs bei Verstand ist (und AVR-Befehle kennt), der würde dies schlicht zum eigenen Vorteil belächeln. Beides scheint aber hier eine falsche
-
Thread
STM32 USB Übertragungsproblem mit Code von S.F.
deutlich größer oder kleiner machst. Zum Beispiel 16 Bytes versus 1024 Bytes. (txLen muss nicht >64 sein, aber eine Zweierpotenz (4,8,16,32,...)
/c etc. für diese 3 Prozessoren, und für manche Projekte auch ein CPU-übergreifendes H-File für STM32 und AVR. Ich komme einfach nicht mehr hinterher, in einem Projekt eine Datei zu ändern und dann daran zu denken, diese Änderung auch für die anderen Prozessoren/Projekte einzuflechten. Irgendwann hat
-
Thread
AVRs über USB programmieren!
realtime" terminal gibt's umsonst dazu, d.h. man kann locker in 30min (wenn überhaupt) ein lauffähiges AVR system zambarschteln. Wer braucht mehr für daheim?? lou BTW: kennt jemand ein besseres (feature mäßig) Forum? Da kommt man sich ja vor wie zur Zeiten von C64 & co...
Schade schade... aber wäre das nicht etwas für die Zukunft, einen 64bit Treiber für Vista, um das AVR USB ISP zu betreiben? Immerhin werden neue PCs nur noch mit Vista ausgeliefert, und nahezu jeder hat dann schon einen 64bit Prozessor - die meisten auch mit 64bit Betriebssystem
-
Thread
Erste 65C02 Basteleien.
besser bleiben lassen. Dabei lernst du nichts nützliches. Wenn du gerade Langeweile hast und die AVR schon kennst, dann schau Dir einen 32bit ARM Controller an. Evaluation Kits bekommst du innerhalb von 48 Stunden original ab 10€: https://www.amazon.de/STM32-ST-NUCLEO-L073RZ-Nucleo-Development/dp
6502 ist der 6504. Komisch, mein Rockwell Datenbuch von 1984 hat auf Seite 2-18 einen R6501Q im 64 beinigen Gehäuse. Der hat 32 I/O Pins zusätzlich und etwas internen Speicher.
-
Thread
13 Bit Genauigkeit mit Atmega messen ?
"defines" ändern und den GCC neu kompilieren? z.B. im GCC 4.4.2 in Datei \\gcc-4.4.2\gcc\config\avr\avr.h Zeile 161: #define DOUBLE_TYPE_SIZE 32 #define LONG_DOUBLE_TYPE_SIZE 32 auf 64 ändern und den GCC neu kompilieren... Kann das jemand? In anderen CPU Headern ist der Wert auf 64.
two words. Be IEEE compliant. */ #define DOUBLE_TYPE_SIZE 64 #define LONG_DOUBLE_TYPE_SIZE 64 Ich meine die AVR-Flashgröße ist mittlerweile recht üppig. Da würde ich jetzt nicht mehr sparen. Vielleicht umschaltbar machen. Auf jeden Fall gab es hier im
-
Thread
AVR128DA übertakten
Vielleicht interessiert es den einen oder anderen: "The AVR128DA28/32/48/64 microcontrollers of the AVR® DA family are ... running at up to 24 MHz", so steht es im Datenblatt, und zwar ab 1.8 V. Da sollte doch bei höherer Spannung etwas mehr möglich sein, zumal
Landolt schrieb im Beitrag #6425939: > Vielleicht interessiert es den einen oder anderen: > "The AVR128DA28/32/48/64 microcontrollers of the AVR® DA family are ... > running at up to 24 MHz", so steht es im Datenblatt, und zwar ab 1.8 V. > Da sollte doch bei höherer Spannung etwas mehr möglich
-
Thread
in_addr_t - Datentypen Umwandlung Sinnfrage
unsigned long 64 Bit breit ist, ein uint32_t aber >selbstverständlich weiterhin 32 Bit. Bis jetzt arbeite ich ausschließlich auf einer 64 Bit Architektur. Mir ist es nicht in den Sinn gekommen, dass native Datentypen
mindestens den Bereich -32767 bis +32767 abdecken können, darf aber auch beliebig mehr. Auf einem AVR ist int 16 Bit breit, auf deinem PC aber 32 Bit. Das gleiche gilt ja auch für andere Typen wie Zeiger. Ein AVR braucht auch viel kleinere Zeiger als ein 64-Bit-PC, da der Adressraum ja viel kleiner
-
Thread
Float als 4 Byte im EEprom speichern
Vorzeichen (18 Bit rauschfrei) vom ADC entspricht einer Spannung von 0...5 V. Hatte vorhrt mit LONG (INT 32 Bit) gearbeitet, war aber zu ungenau. Na dann viel Glueck. Denn Longint mit 32bit hat 9 signifikante Stellen. Float mit 32bit hat nur 6 signifikante Stellen. Etwas anderes waere double mit 64bit.
>>>Na dann viel Glueck. Denn Longint mit 32bit hat 9 signifikante Stellen. >>>Float mit 32bit hat nur 6 signifikante Stellen. Etwas anderes waere >>>double mit 64bit. Das hat 15 signifikante Stellen. Das Problem bei Longint 32 Bit ist,
-
Thread
stdint.h in Projekt einbinden
uint8_t uint16_t uint32_t uint64_t int8_t int16_t int32_t int64_t Und jetzt rate mal welcher dieser Typen welche Eigenschaften hat. Auf einem AVR mit gcc wären das dann typedef unsigned char uint8_t; typedef
int8_t; > typedef int int16_t; > typedef long int32_t; > typedef long long int64_t; Nur zur Information: Die GNU-Toolschain für AVR definiert einen uint8_t als [c] typedef unsigned int uint8_t __attribute__((__mode__(__QI__))); [/c] binden den
-
Thread
Welcher ARM?
//www.mikrocontroller.net/topic/350400#4354169 Theoretisch kommt da noch hinzu, dass bei dem STM32-Mini nur 64kB Flash drauf sein sollten, wobei in der Praxis trotzdem 128kB verfügbar sind. Eine Garantie dafür hast du allerdings nicht. Steht aber auch alles in dem Thread. Das Maple Mini hat einen
habe diesen "2,90€ ST-Link V2" und kann damit alles machen, sowohl mit dem STM8 als auch mit dem STM32. Was habe ich übersehen, also was kann ich _nicht_ damit machen? Sogar beim AVR ist Source-Level-Debuggung preiswerter. Jörg W. schrieb im Beitrag #4503621: > Ja, natürlich, an jedes entsprechende
-
Thread
Atmel Studio 7 schnarchlangsam
Leistungsdaten meines Laptops: Prozessor: AMD E-350 1.6GHz Ram: 4GB HD: SATA 500GB System: Win7, 64 Bit Startzeit Atmel Studio: 28 Sekunden Zeit, die gebraucht wird, wenn man ein Projekt öffnet: 32 Sekunden Ram-Auslastung:1.95GB ( also nur die Hälfte des verfügbaren Rams ) Könntet Ihr mal die
@ chris_ (Gast) >Prozessor: AMD E-350 1.6GHz >Ram: 4GB >HD: SATA 500GB >System: Win7, 64 Bit Ich hab nur einen alten Core Duo2 mit 2x1,5GHz, 2GBRAm, WinXP >Startzeit Atmel Studio: 28 Sekunden Bei mir 45-60s >Zeit, die gebraucht wird, wenn man ein Projekt öffnet: 32 Sekunden
-
Thread
RL78/G14 Renesas - Free Linux Toolchain
bei Mouser deshalb so günstig, weil es nur käufliche Tools dazu gibt? Welche Controller Familien AVR, PIC, STM8/32, MSP430 kommen sonst in Frage, wenn man bei kleinen Stückzahlen (<100) einen 12bit ADC, genügent IOs und SPI braucht und 64k ROM 2k RAM gerne hätte und der MC unter 10 Euro (besser
/ProductDetail/Microchip-Technology/AVR64DD28-I-SP?qs=tlsG%2FOw5FFihPlDfBDs%252Bgg%3D%3D
-
Thread
Projekt : GPS Tracker
Soo ich habe mein Problem mittlerweise gelöst, man kann den mega32 komischerweise NUR per AVRdude flashen, nicht aber mit dem AVR Studio. Dieses verweigert weiterhin seinen Dienst. Naja wie auch immer, der Logger funktioniert jetzt soweit wieder, eine kleine Testfahrt
Tracker bauen möchte. Weiter oben habe ich gelesen dass man die .hex datei und die .eep Dateien auf den m32 brennen muss. Die .hex Datei zu brennen ist kein Problem, aber wie man die .eep Datei bei AVRWorkpad Plus in den Eprom bekommt habe ich keine Ahnung. Benutzt von euch noch jemand Avr Workpad und ein
-
Thread
Zahlenformat 100000L?
Der Albi schrieb im Beitrag #1676386: > Long alleine hat auf avr 32bit. also 4 Byte. Was du meinst ist long long > - der hat 64bit. ne "long long" hat mit 64bit nichts zu tun. "long long" kommt aus chengdon und hat keine Ahnung von Mikrorechentechnik sondern
klugschwätzer. Um die Uhrzeit kann eigentlich dann nur ich gemeint sein. > Long alleine hat auf avr 32bit. also 4 Byte. Was du meinst ist long long > - der hat 64bit. Hat mich allerdings auch verwundert. Vielleicht war es zu spät? Ich dachte bislang, long wäre immer 32Bit und nur der unsägliche
-
Thread
uC from Scratch
(ganz unten auf der Seite) https://www.pjrc.com/store/teensy35.html#tech dass noch ein MKL02Z32VFG4 (MCU Cortex M0+32K flash) (1.) zusätzlich zum MK64FX512 (Cortex M4 und "Gehirn" des Teensys) (2.) verbaut ist. Weiß jemand wieso? 1.: https://www.mouser.de/ProductDetail/NXP-Semiconductors/MKL02Z32VFG4
Du verwechselst glaube ich Microcontroller (Stm32 oder Atmel AVR) mit einen Dev Kit (teensy oder Arduino)
-
Thread
VGA Testbildgenerator
http://www.atmel.com/journal/Archive.asp unter "AVR Video Generator with an AVR Mega163". oder auch: http://www.roboternetz.de/phpBB2/viewtopic.php?t=5880
Hallo @Hagen, Ich realisiere ein wechselnden zugriff auf den Speicher mit 32Mhz, 16Mhz für die GraKa und 16Mhz AVR, der Prozessor(AVR) wird Syncron mit 32/2 betrieben (also 16MHz). Bei einen Speicher mit einer Zugriffszeit von 15ns könnte man diesen mit etwa 66MHz betreiben also
-
Thread
Frequenzzähler mit atmega48
. AVR haben ueblicherweise keine 64 bit floats. Weil es niemand fuer noetig fand diese zu implementieren.
braucht man schon mindestens einen TCXO-Takt. Für die hiesige Anwendung also völlig ausreichend. > AVR haben ueblicherweise keine 64 bit > floats. Weil es niemand fuer noetig fand diese zu implementieren. AVRs können von sich aus auch keine 32 bit float, da ihnen die FPU fehlt. Um Deine Unwissenheit
-
Thread
C code automatisch in hexfile compilieren
Ordnerstruktur ist die gleich wie bei dem Projekt von Ulrich Radig: http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex Ich benutze Außerdem Eclipse und gcc-avr kann mir jemand sagen was ich falsch mache? vielen Dank
Frage angekommen: > ich würde gerne den Programmcode: > http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex > automatisch compilieren lassen (in ein hexfile unwandeln) Wenn du jetzt noch mithilfe von dem makefile das Programm auf den AVR brennen möchtest, musst du noch folgendes einstellen
-
Thread
Kann jemand ein selbstgebautes FS brauchen ?
speichern und bei bedarf laden. - für einen basic-interpreter/eine intermediate language basierend auf avr/arm ein schnelles dateisystem zu haben das sind ein paar ideen die man genausogut mit einem fat32/16 realisieren kann, aber wie gesagt steht für mich eher im vordergrund sowas mal selbst gemacht
@Simon K, Anfang des Jahres hast Du geschrieben: "Läuft auch jetzt auf dem AVR ... Die AVR Version adde ich später." Wann ist denn endlich später? ;-))
-
Thread
Initialwert von globalen Variablen zur Laufzeit verwenden
Maxe schrieb im Beitrag #6061777: > Für den AVR ist ein LDI, welches ein 8-bit Wert enthält, als > Maschinenbefehl genauso 16bit lang wie ein LDS oder LPM, Wobei LDS ein 32-Bit Encoding hat auf den meisten AVRs. Auf Reduced Tiny ist LDS zwar
21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69,
-
Thread
8h Timer mit attiny85 - Genauigkeit ohne Quarz
lange auf PIC gekuckt. Aber diese zwei Sachen, gebankte SRAM und teure Compiler - das hält mich bei AVR. Wenn schon zu wechseln, dann lieber gleich auf STM32. Auch kostenlose Compiler und frei zugängliche (und auch viel größere) RAM. Wenn AVR nicht mehr reicht. Übrigens, hier hat man noch eins bei
CTC mode Table 11.5 TCCR0B |= (1 << CS00);// Prescaler table 11.6 OCR0A=121; //CTC Compare value 32,786885 khz, 0.0576% error , 243 on 16mhz ! } void loop(){ } [/code] sowie ein Code zur Kalibration z.B. diesen hier: [code] #include <avr/io.h> #include <util/delay.h> #include <avr
-
Thread
RAM-Erweiterung
ob AVR oder ARM. Ich will aber auch so mal was mit Mikrocontrollern machen, und will dann halt möglichst bei einem Typ bleiben, wenn ich mit dem schon Erfahrungen gemacht hab. Du hast geschrieben ein 64
u.a. A15 per Software schaltest und nicht vom RAM Interface. Dann mußt du leider immer zwischen zwei 32KB Bänken hin und her schalten. Wie's genau geht steht z.B. im Mega64 Datasheet (S. 34)... MFG Kai
-
Thread
CRC oder einfach die Daten doppelt schicken?
muss ich sicherstellen, dass ich fehlerhaft übertragene Daten verwerfe. Reflexartig habe ich an CRC32 gedacht, aber nachdem ich ewig nach einer AVR Implementation via LUT gesucht habe (CRC32 auf Bitbasis ist unverschämt lahm) dachte ich mir, warum nicht einfach die Daten doppelt senden? CRC32 hat 4 Bytes
die Daten haben 4 Bytes.... ich spare mir jede Menge Arbeit... Die Frage ist jetzt, ob Daten+CRC32 mehr Fehler abfangen könnte als Daten+Daten. Bin kein Mathematiker. PS: Wenn jemand weiss, wo man eine CRC32 LUT Version für AVR findet, wäre ich auch sehr dankbar. Angeblich kommt man mit einer 1
-
Thread
advanced Arduino Libraries
>Talkie werde ich mir wohl mal anschauen, besser anhören. >Referenz für mich wäre da SAM von C64 >https://www.c64-wiki.de/wiki/SAM >Da habe ich damals mal versucht dem das Singen von "Alle meine Entchen" >beizubringen, klang auf jeden Fall sehr lustig. >Einen Arduino-Port für den ESP32 habe
eigentlich mal genauer anschauen, Sourcen finden man im Netz, den 6510 usw. vom C64 kenne ich noch ganz gut, AVR-ASM mag ich auch, ist aber bisher nie was draus geworden... Markus schrieb im Beitrag #6765543: > Michael U. >>da eher noch: >>https://bitluni.net/esp32-color-pal
-
Thread
Mehrere V-USB Anwendungen auf einem AVR möglich?
DraconiX schrieb im Beitrag #4961068: > Der Mega32u4 ist ja auch nicht gerade Schwachbrüstig. leider gibt es nur 32k und keine 64k/128k ein mega 1284u4 wäre nett
Joachim B. schrieb im Beitrag #4961080: > leider gibt es nur 32k und keine 64k/128k > > ein mega 1284u4 wäre nett Habe mal geschaut: Bei den Chinesen kostet ein STM32F103 ziemlich genau das Gleiche wie ein ATMega32U4. Beide sind auf einer kleinen Platine, die
-
Thread
Welche CPU für Homebrew-Computer?
Evtl. könnte dich auch dieses Projekt interessieren: CP/M auf AVR: http://www.mikrocontroller.net/topic/177481 http://avr.cwsurf.de Dort wird ein vollständiges CP/M System mit einem AVR (ATmega88/168), einem (oder 2) DRam's und einer SD Karte gebaut. 8080 CPU
Beitrag #2226084: > ohne alles gelesen zu haben: so viel ich weiss, kann man bei einigen > PIC32 via DMA externen speicher anhängen von dem man auch code ausführen > kann. PIC32 ist eine ziemlich andere Grössenordnung und mit ARM vergleichbar.
-
Thread
C -> AVR -> Strukturen -> Padding Bytes
units (bytes). */ #define UNITS_PER_WORD 1 [/c] http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr.h?view=markup#l114 Ein formales ABI gab es für AVR nicht, d.h. das ABI des avr-gcc / avr-g++ definiert sich dadurch, wie Denis damals das Backend implementierte. ABI-Dokus wie http://gcc.gnu.org
aber drei Padding-Bytes kommen, die Teil der struct sein müssen. Also wird diese struct auf gängigen 32-Bit-Systemen vermutlich 64 Bit groß sein.
-
Thread
Floating point Geschwindigkeit
> Uint64 ist ebenfalls echt lahm. Das habe auch ich schon festgestellt. Beispiel: Bei einer 32x32->64 MUL werden die Operatoren zuerst auf 64 Bit erweitert und dann multipliziert, mit der Folge, dass statt
Tippgeber schrieb im Beitrag #7105640: > Bei einer 32x32->64 MUL werden die Operatoren zuerst auf 64 Bit > erweitert und dann multipliziert, mit der Folge, dass statt der > notwendigen 16 Multiplikationen 64 ausgeführt werden Welche Plattform, welcher
-
Thread
Audio Spectrum Analyzer
das schaltbild bassiert auf einem 64 kanal spec mit 18 led s pro kanal das in jeweisl 2x 32 kanal aufgeteilst ist ( deshalb die 2 atmels ) led s und eingänge sind auf deinem bild noch nicht drauf ... weil ich eine extra display platine
eine solche fft einssetzen könnte wäre ja auch die option in meiner variante entweder stereo 32 kanal oder mono 64 kanal ... und das mit 5x5 mm rechteck leds eine fläche ...
-
Thread
Mikrocontroller mit großem RAM
Na, wenns AVR sein und bleiben soll - nimm 'nen Mega128 und hänge ein 32K-SRAM dran.
Falk Brunner: ja, schon klar, aber das ist etwas wenig, 256 Bytes hat heute doch "jeder mittlere" AVR. Ich dachte da eher an 8kB, oder warum nicht 64kB, ich hab' ja 16 Adressen. Und der Port für die "oberen" 8 Adressbits ist sowieso verloren (wenn ich die "RAM-Befehle" des AVR benutze). oh,
-
Thread
[AVR] Mittelwertbildung
Joachim B. schrieb im Beitrag #4497881: > aber RC 64 sprengt die uint16_t vom ADC Wert, also bis 32 gehe ich mit. Überleg Dir das besser noch einmal ;-) Ha, ich war schneller!
mal aufsummiert, benoetigt man 16(24) bit dafuer. Ich verwend daher fuer 16bit Werte von einem ADC 32bit, das erlaubt mir 2^16 = 64k mal auszusummieren. Das sollte in den meisen Faellen genuegen. 32Bit Integer hat uebrigens mehr signifikante Stellen wie 32bit Float.
-
Thread
Spielekonsolen mit AVR
> RAM kann man ja bis 64 Kb an den AVR anschließen. Mit (RAM)Banking kann man unbegrenzt (S)RAM an den AVR anschliessen. Bsp.: Ab Adresse $1100 werden die oberen AdressBits für die Bänke (in FF-ICs (bsp '374 '
Konfig-Byte für verschiedene Aufteilungs-Varianten., geht in PLD (*)) Ab Adresse $8000 (obere 32kB vom AVR) werden diese Bänke (mittels 32kB- / 16kB- / 8kB- / 4kB- Pages) dann adressiert. (bsp. 1x32kB oder 2x16kB oder 4x8kB oder 1x16kB u. 2x8kB oder ...) (*) das PLD schaltet die
-
Thread
Anfänger / welcher mContr / welche Software
einzeln, auch hübsch verpackt für den Mac, eins von diesen beiden für kleine und große Cortex-M, z.B. STM32: arm-gnu-toolchain-13.2.rel1-darwin-x86_64-arm-none-eabi.pkg arm-gnu-toolchain-13.2.rel1-darwin-arm64-arm-none-eabi.pkg https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads 32-Bit
auch hübsch verpackt für den Mac, eins von diesen beiden für kleine und > große Cortex-M, z.B. STM32: > arm-gnu-toolchain-13.2.rel1-darwin-x86_64-arm-none-eabi.pkg > arm-gnu-toolchain-13.2.rel1-darwin-arm64-arm-none-eabi.pkg > Oh Danke! Das war jetzt sehr ausführlich zu STM32 und PIC - das werde
-
Thread
Wie erschaffe ich einen 1 ms Takt bei einer Frequenz von 16MHz
> zwischen Fuses und Quellcode. Und für dich wohl auch..... Lesestoff: https://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html
? Oder per Prescaler durch 16 und dann per Timer durch 1000, oder Prescaler durch 32 und Timer durch 500 oder Prescaler durch 64 und Timer durch 250? Oder durch 128 und Timer durch 125. Alles sehr seltsam - zumindest für mich, der ich mich bislang fern gehalten habe von allen AVR
-
Thread
dynamisch Code ausführen - Code von SD-Karte
M-fähig war. Was sind das für Kupferdrahtverhaue! Man könnte auch gemischte Geräte bauen: Z80 mit 64kB RAM, der über einen AVR mit USB geladen wird. :-) Ein Kumpel interessierte sich damals für Programm-Battles im Speicher. Also Programme, die laufen, und sich verschieben dürfen, sich reparieren
im Beitrag #1696062: > Wenn Du bedenkst, dass ein 486ger noch mehr als 10 > Taktzyklen für eine 32x32->32 Multiplikation braucht ist das schon recht > gut. der AVR braucht dafür auf jeden Fall länger.
-
Thread
Projektvorstellung: µMk64 - 2-MHz Heimcomputer aus 5 AVRs
80-Zeichen (480x192 Pixel), 160x192 Pixel, 15 verschiedene Modi, teilweise mit RasterIRQ, 32 Sprites, Softscrolling - PS/2-Tastatur, FAT16-SD-Karte mit 32MB-VirtualDisk, über 600kB/s netto Lesegeschwindigkeit - 4-Kanal-ADSR-Synthesizer, wahlweise C64-SID-Registerkompatibel - Eigene Betriebssysteme
Arcadespiele, her betrachtet kann man auf µMk64 insgesamt sogar mehr machen, als auf dem C64 (bspw. horizontaler Splitscreen, VideoStreaming von SD etc.), aber im Detail gibt es viele Unterschiede. Bspw. die 32 statt 40 Zeichen schränken einerseits
-
Thread
Sd-Card Spec
jetzt genau die Unterschiede zwischen den L, und normalen AVRs sind. Reichelt hat nämlich den mega32-L nur als DIP, und atmega64 ist vermutlich zu groß. Aber ich denke, dann kann man den normalen Typen trotzdem mit <16Mhz @ 3V laufen lassen(?). VLSI habe ich gefragt, ob sie für die in "Audio Porduct
hat normalerweise die Grösse eines Sektors, also 512 byte. Man kann die grösse aber auch auf z.b. 32 byte stellen, um so nur immer 32 bytes aufs Mal lesen zu müssen. MFG Nik
-
Thread
Besitz Arduino einen RTC?
avr schrieb im Beitrag #4493895: > Wenn man Zeiten in µCs häufiger braucht, dann braucht man sie als > 32-/64-Bit Variablen. Das ist nicht bei jedem so. Ich könnte mir vorstellen, dass nicht jeder auf einem 8-bitter das ganze in einer 64-bit Unixzeit umrechnet (32-bit ist ja nicht besonders zukunftssicher).
-
Thread
Servosteuerung 30 A - H-Brücke verstärken?
darf also annehmen, daß die Kommunikation zwischen Programmer und MCU funktioniert. [code] ~/test/AVR/hello/timer$ man avarice .... avarice currently has support for the following devices: at90can128 at90can32 (o) at90can64 (o) .... * - Only supported
Wolfgang R. schrieb im Beitrag #4937603: > ~/test/AVR/hello/timer$ man avarice > .... > avarice currently has support for the following devices: > at90can128 > at90can32 (o) > at90can64 (o) > .... >