-
Thread
ATMega32 16 MHz PAL mit Farbe ohne externen Chip
Da bekomme ich dann folgende Fehlermeldung: C:\Dokumente und Einstellungen\Home\Eigene Dateien\AVR-Projekte\PAL Testbild\m32def.inc(364): error: Attempt to redefine keyword 'or' Könnte mir da jemand helfen? Grüße Chris
Ahh Du hast keine x64 Architektur, ersetze da einfach ppcx64 durch ppc386
-
Thread
16-Bit-Zahl ausgeben, nur wie?
über 500 Byte Programmcode. (Und ja, ich hab Optimierung aktiviert. Die Zahl bezieht sich auf avr-gcc und ATmega8) [c] void put_sfrac32 (int32_t frac) { if (frac < 0) { put_char2 ('-'); frac = -frac; } put_char2 ('0'); put_char2 ('.'); uint64_t frac64 = (uint32_t) frac; frac64 <<= 1; char *pbuf = buf; for (uint8_t i=0; i < 10; i++) { frac64 *= 10; *pbuf++ = '0' + (frac64 >> 32); frac64 &=
-
Thread
Lasst uns mal ein richtigen "HANDHELDEN" bauen! Gesperrt
Ich habe mir das folgendermaßen gedacht: HARDWARE: Als Hauptprozessor habe ich an einen AVR32 + SDRAM gedacht. AT32UC3A3256 66Mhz(90Mhz Overclocked) MT48LC16M16A2 256Mbit SDRAM SDHC-Connector angeschlossen am SD/MMC interface vom AVR32 2,2” Touch Display
Warum denn ein Exot (AVR32) und kein ARM?
-
Thread
Registerattribut
Peter schrieb: > Sie sind nich 32 Bit breit, sondern noch mehr. Und es sind alle 32 Stück > verbreitert worden. Schönen Schrank auch. Und dafür nimmt man sich ausgerechnet einen AVR als Original? Der GCC ist ursprünglich vor allem für 32-bit- CPUs vorgesehen gewesen, das ganze Gefummel, was der AVR-GCC als Hacks für die kleine 8-bit-CPU macht, hätte man sich hier komplett klemmen können. Von mir aus auch 64 bits. (Weiß nicht, wie
-
Thread
Rückwandbus mit I2C
USB, die gibt es mit 64/100/144 Pins in 0,5mm Pitch - also mit 64 Pins so gross wie ein Mega644. Nur, ein AVR32 ist eben kein AVR...
SPI ist dann noch schlimmer. :-) Dann überlege lieber ob Du statt dem Mega644 nicht einen 90CAN32/90CAN64/90CAN128 benutzen kannst. Oder halt wirklich mal einen AVR32 UC3C, ist zwar was ganz anderes, aber wenigstens bleibt die Entwicklungs-Umgebung komplett gleich. :-) Die Mega16M1 gibt es
-
Thread
Betriebssystemprogrammierung
N'Abend die Nachtschwärmer. Ich habe Interesse an der Betriebssystemprogrammierung auf X86/X64-Systemen. Meine erste Frage, macht es nicht eher Sinn sich mit X64-Systemen zu beschäftigen als X86 oder verstehe ich hier etwas total falsch? X64 = 64Bit, X86 = 32Bit. Meine zweite und WICHTIGERE
> N'Abend die Nachtschwärmer. Ich habe Interesse an der > Betriebssystemprogrammierung auf X86/X64-Systemen. > > Meine erste Frage, macht es nicht eher Sinn sich mit X64-Systemen zu > beschäftigen als X86 oder verstehe ich hier etwas total falsch? X64 = > 64Bit, X86 = 32Bit. Wer auf die komische
-
Thread
ATMEGA8535 tut nicht!!!
Wie und wo kann ich die FuseBits verändern? Kann ich dies nur mit CodeVisionAVR oder PonyProg?
Crystal; Startup Time 1K CK + 4ms [CKSEL=1001 SUT=00] Ext. Low Freq. Crystal; Startup Time 1K CK + 64ms [CKSEL=1001 SUT=01] Ext. Low Freq. Crystal; Startup Time 32K CK + 64ms [CKSEL=1001 SUT=10] Ext. Crystal/Resonator Low Freq; Start-up Time 258 CK + 4ms [CKSEL=1010 SUT=00] Ext. Crystal/Resonator
-
Thread
ATMEGA8 Soundgenerator/Synthizer
, daß ein SID-Player oder ein Synth mit einem ARM oder einem DSP kein großes Problem ist. Aber ein AVR ist sehr viel einfacher im Handling als ein ARM... das ist schon ein Vorteil. Preislich ist der ARM7TDMI ja fast so preiswert wie ein ATmega32... also kein Vorteil des AVR. Gruß, SIGINT
die sound.c explizit in das Projekt mit aufnehmen. Frage doch mal hier im GCC-Forumsthread bezüglich AvrStudio6 nach. Auf AvrStudio4 geht es.
-
Thread
Rust auf AVR: AVR-Rust -> So geht's
Bevor mein Spieltrieb geweckt wird eine kurze Zwischenfrage: Werden bei AVR-Rust die Typen f32 *und* f64 unterstützt?
//github.com/avr-rust/rust/issues/76#issue-258761696 Da wird auch ueber die breite von f32 und f64 diskutiert.
-
Thread
Pollin - Receiver-Mainboard mit Twin DVB-[T,C] Tuner, NXP PNX8950EH
halt u.a. für den hier vorhandenen MIPS-Prozessor (wenn ich mich nicht täusche), XP läuft nur auf 32- oder 64-Bit-Prozessoren. Linux wäre hier schon einiges interessanter :-)
> um die Bootloader-Frage vielleicht klären zu können, habe ich mal den > Flash-Baustein an einen AVR gehängt und gedumped. Hallo Stefan, vielen Dank für Deinen nützlichen Beitrag. Mit Deinem Dschungelgelöt hast Du die vollen 64MB dumpen können.
-
Thread
ESP8266 in Assembler programmieren
Da erinnerte mich an meine alte, längst vergangene Leidenschaft der Assemblerprogrammierung (der C64 hatte grade mal 3 Register und war hübsch übersichtlich) und bin zum AVR Studio und den diversen ATMEL-Prozessoren gelangt. Jetzt laufen mir die Augen über was es alle mittlerweile gibt. Raspberry,
die Verarbeitungsbreite in den > verfügbaren Rechenwerken. Und welche zählt jetzt? Gerade x86_64-CPUs können in der ALU eine Reihe verschiedener Größen verarbeiten. Was ist mit CPUs, die zwar Befehle für z.B. 64bit-Arithmetik haben, diese aber intern als 2x 32bit berechnen? Und was hat das alles
-
Thread
avrDude mit USBTinyISP
Copyright (c) 2007-2009 Joerg Wunsch System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf" Using Port : lpt1 Using Programmer : usbtiny AVR Part : ATMEGA32 Chip Erase
: usbdev_open(): Found USBtinyISP, bus:device: bus-0:\\.\libusb0-0001--0x1781-0x0c9f AVR Part : ATmega32 Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0
-
Thread
Datenpaket in Programmspeicher - C
"Configurations Optiones" zeigt, dass dort der M664 mit einem Flash Size von 0x8000 angegeben ist (32.768bytes). Also kein Wunder, dass das 60kb große Daten-Array nicht passt. Im Datenblatt findet sich oben die Beschreibung 8-Bit AVR microcontroller with 64k bytes flash und weiter unten unter AVR Memories "...the flash is organized as 32/64 x 16 ...", was bei mir den Verdacht aufwirft, dass der Flash Speicher in zwei Bereiche zu 32kb unterteilt ist.
-
Thread
Timer_Anfängerproblem
Die Register heißen beim mega103 und mega32 gleich.
Mit welcher Version Von AVR Studio arbeitest Du?
-
Thread
Stoßt man mit C an Grenzen?ASM von Vorteil?
Passt schon. Ein einheitlicher Adressraum für Data,Code,IO ist in der Controller-Branche unterhalb der 32bitter eher selten anzutreffen. MSP430, Freescale bis 64KB, aber sonst?
schrieb: > Ein einheitlicher Adressraum für Data,Code,IO ist in der > Controller-Branche unterhalb der 32bitter eher selten anzutreffen. > MSP430, Freescale bis 64KB, aber sonst? 8080, 8085, Z80 - 64 KB
-
Thread
FT232 ähnliches USB mit atmega32u4 unter C
es geht darum mit Atmega32u4 (der USB hat) unter C mit Win 7 64bit einen Sensor auszulesen. Das Verhalten soll dabei ähnlich unkompliziert sein wie der FT232 auf Arduino nano3. als Beispiel für USB mit 32u4 nutze ich das Beispiel
Matthias W. schrieb im Beitrag #6910562: > es geht darum mit Atmega32u4 (der USB hat) unter C mit Win 7 64bit einen > Sensor auszulesen. Würde man heutzutage eher via USB HID denn als serial Port machen - deutlich unkomplizierter. Insbesondere wenn es ein Sensor mit
-
Thread
Zu viele Symbole werden gestrippt (Code zu klein)
Also der Knackpunkt war, nicht das Binary Package libusb-win32-bin-1.2.6.0 zu nutzen, sodnern das Source Package libusb-win32-1.2.6.0 und aus den dortigen Quellen dann libusb.a unter Cygwin64 für den eigenen Windows-7-Rechner zu erstellen. Alle anderen Wege scheiterten
Volker schrieb im Beitrag #4051083: > Also der Knackpunkt war, nicht das Binary Package > libusb-win32-bin-1.2.6.0 zu nutzen, sodnern das Source Package > libusb-win32-1.2.6.0 und aus den dortigen Quellen dann libusb.a unter > Cygwin64 für den eigenen Windows-7-Rechner zu erstellen. > > Alle anderen
-
Thread
Einfacher und billiger Webserver mit AtMega32
=atmega32 -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=ftpd.lst -std=gnu99 ftpd.c -o ftpd.o Compiling: httpd.c avr-gcc -c -mmcu=atmega32
avr-gcc -c -mmcu=atmega32 -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=uart.lst -std=gnu99 uart.c -o uart.o Compiling: tcp.c avr-gcc
-
Thread
Double=16Bit?
Wenn in einem 8-bit Kontext programmiert wird sind 16-bittige Doubles üblich. Bei einem 32-bit-System sinds dann eben 64-bit für ein Double. bye Frank
Jörg Wunsch wrote: > Nichtdestotrotz hätte ich gern jemanden, der eine 64-bit-Gleitkomma- > Implementierung für den AVR-GCC mal angeht. Es würde auch schon viel helfen, die 4 Grundrechenarten als 64Bit einzubinden (<200 Byte). Theoretisch ist zwar long long implementiert
-
Thread
Kupferdrahtdurchmesser bei Spulen
rumbasteln möchte. Dann geht das Spiel nochmal von vorne los ;) Eine einfache Clock mit 8 RGB's + AVR läuft aber schon. Nur kann man mit dieser eben keine farbigen Grafiken oder Animationen erzeugen da der ATMega8 einfach zu wenig SRAM hat und schon jetzt mit der Ansteuerung der 8 RGB LEDs in 64 Farben
simuliert. Für deine par LEDs ist dieser Aufwand aber übertrieben. Im anderen Thread gibt es um 32-64 RGB LEDs die ca. 3-4A ziehen würden. Gruß Hagen
-
Thread
MEGA 128 verrechnet sich
double" liegt. Die Compiler, die kenne, akzeptieren das zwar, rechnen aber dennoch nur mit float, also 32bit statt 64bit.
Anwendung, die eine solche Genauigkeit braucht. Kannst Du mir eine nennen? :-) Daß double nicht mit 64-bit ausprogrammiert ist auf dem AVR ist keine Sache des Compiler. Das ist eine Sache der AVR-Libc. Du könntest ja die Routinen aus der AVR-Libc nehmen und entsprechend aufbohren. Daß sich jemand hingesetzt
-
Thread
Prinzip grafische darstellung/diagramme etc
--+-----+------+-----+------+ ------------------------------------- Die Bewegung vom 8-Bit AVR weg zu einem 32Bit Prozessor ist allein schon eine große Umstellung. Wenn Du in C programmierst, dann ist zwar einfach ein 32Bit-Typ der "natürliche" aber es gilt immer noch, das Du in C den den Daten
noch DMA und die Interrupts lassen sich, anders als beim AVR häufig noch konfigurieren, was Du vom AVR nicht kennst. Ich schlage Dir als Anfang die STM32-Prozessoren vor. Da gibt sehr günstige Boards. ------------------------------- Aber wiegesagt, schaue
-
Thread
Z80 Einplatinencomputer für Lernzwecke
Hallo Harald, Speicherbanking muß nicht zwangsläufig 64 K sein. Es gibt Z80-Systeme in denen 8, 16 oder 32 K RAM- oder ROM-Segmente jeweils über PIO-Signal eingeblendet werden. Du mußt auch festlegen wo der SP-Bereich sein soll, die SIO mit Pegelanpassung
Speicherraum durch entsprechende Steuervorgänge zu verwalten. Die CPU U880 ist in der Lage, ,aximal 64KByte Speiher direkt anzusteuern.Allein auf der Karte GRE stehen aber 64Kbyte RAM und je nach verwendetem EPROM Typ 8,16,32, oder 64KByte EPROM zur Verfügung. Nach Power On Reset bzw. externem Reset wird
-
Thread
Treiber für AVR32_UC3_CDC ?
mit den Files: - avr_uc3_cdc.cat - avr_uce_cdc.inf - installer_x64.exe - installer_x86.exe - libusb-win32-bin-readme.txt - Ordner amd64 (libusb0.dll, lisbusb0.sys) - Ordner ia64 (libusb0.dll, lisbusb0.sys) - Ordner
Installs to Windows\system32\libusb0.dll IA64 ONLY ARCHITECTURES: ia64\libusb0.sys: IA64 64-bit driver. Installs to Windows\system32\drivers\libusb0.sys ia64\libusb0.dll: IA64 64-bit library. Installs to Windows
-
Thread
AtMega32U4 Minimalbeschaltung
). > Bisher wollte ich eigentlich einen Atmega8 verwenden, tendiere jetzt > aber doch zum AtMega32U4 da der bekanntermassen nativ USB kann. Die Kinder sollen TQFP löten? Ist das für den Anfang nicht etwas viel? Nimm doch einen PIC24FJ64GB002. Das ist ein SDIP28 wie der Mega 8, hat USB und noch
Wird das nicht teuer mit atmega32u4? Wenn man so ne' kleine Armee Kinder versorgen will - 64LEDs pro Platine, die Platine selbst und der AVR - da kommt doch bissel was zusammen? (Und dann noch alles vorbesteuckt...) Wo beziehst
-
Thread
AVR64DD28 Clock Source ändern
schrieb im Beitrag #7428401: > In C gibt es die Funktion '_PROTECTED_WRITE', siehe > Beitrag "Re: AVR ATtiny Stromaufnahme" DANKE! Ich habe nur 'PROTECTED_WRITE' ausprobiert, aber nirgends gefunden. Woher weiß ich denn, dass diese Funktion existiert? Ich habe nichts im Datenblatt des AVR64DD28
/DataSheets/AVR64DD32-28-Prelim-DataSheet-DS40002315B.pdf
-
Thread
8bit-Computing mit FPGA
Machtposition der Protagonisten. Also bleibt pragmatisch, weshalb ich mir keinen neuen 8bitter antue. 6502,Z80,AVR reichen mir. Die 16bitter sind für mich out, hab mich zu oft über die Segmentbedingten Fehler im HC16 geärgert. 32bit rulez in Embedded, nach meinem Abtritt dann natürlich mal die 64bitter (PS: Das 32bit Linux/Unix Datum läuft bei Interpretation als uint32 erst im Jahr 2104 ab, da bin ich schon tot und es kann mir egal sein... Manche Kollegen wollen ja jetzt schon unbedingt auf 64bit, auch auf 32bit
-
Thread
Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus
wieder bei dem großen LCD Controller. Evtl. könnte man ein serielles FRAM (von Ramtron, gibts mit 32 kBytes, 8-pinniges Gehäuse) per SPI an den AVR anschließen. Die Schaltung wäre dann nur minimal größer, man könnte aber Grafik darstellen. Durch die Hardware-SPI im AVR könnte man das FRAM bei 16 MHz
gemacht. > Wie genau läuft die Auswertung von den Befehlen mit Parametern, was > erwartet der AVR auf dem UART bspw. für die grosse Schrift? Wenn ein Zeichen empfangen wird, dann wird geprüft, ob es ein Zeichen (Wert >=32) oder ein Befehl (<32) ist. Daten werden direkt in den Speicher geschrieben
-
Thread
SPI mit 2 Mastern und 2 Slaves entkoppeln
der zeite AVR liest das jeweils nicht gerade beschriebene FRAM aus und schreibt die 32KB mit einem SD_WRITE_MULTIPLE_BLOCKS in einem Rutsch auf die SD Karte - dies sollte hoffentlich weniger "latenzen" auf der SD-Carte
AVR öffnen. Schau hier: http://www.reichelt.de/PIC-32-Controller/32MX150F128B-ISP/3//index.html?ACTION=3&GROUPID=4509&ARTICLE=121326&SHOW=1&START=0&OFFSET=500& > Und es ist kostengünstiger 2 Mega168
-
Thread
Unable to enter programming mode.
System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf" Using Port : usb Using Programmer : avrispmkII Setting bit clk period : 64.0 avrdude: usbdev_open()
avrdude: Recv: . [01] . [00] . [0a] A [41] V [56] R [52] I [49] S [53] P [50] _ [5f] M [4d] K [4b] 2 [32] avrdude: stk500v2_getsync(): found AVRISP mkII programmer avrdude: stk500v2_program_enable(): bad STK600 connection status: Unknown (0x64) avrdude: initialization failed, rc=-1 avrdude: AVR device
-
Thread
erster Mikrocontroller programmieren -> fragen
eingelesen. ich habe folgendes vor: ich habe hier ein 4x16 Dot LCD rum liegen und möchte es mit einem ATmega32 ansteuern. Da ich VB.net gelernt habe, möchte ich den Mikrocontroller mit Bascom programmieren. ich habe mir diese Seite hier (http://www.mschrod.de/Elektronik/AVR/Atmega%20Allgemein/Display/Display.htm
ATmega32. Für mich gibt es jedenfalls keinen Grund, den alten ATmega32 einzusetzen, außer ich muss mal eine alte Schaltung reparieren, in der genau dieser µC drinsteckt.
-
Thread
Anfänger: HEX File für ATMEL 90USB162 aus vorhandenem Code erzeugen
Danke für Eure Rückmeldung. Ich finde auf meinem PC die avr-gcc.exe zweimal. 1.) C:\WinAVR\bin 2.) C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.2.1 002\avr8-gnu-toolchain\bin Verwendeter Variabelname: AVR32_HOME Ich habe jetzt beide
Downloads\msys\1.0' ALLUSERSPROFILE='C:\ProgramData' APPDATA='C:\Users\michague\AppData\Roaming' AVR32_HOME='C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.2.1 002\avr8-gnu-toolchain\bin' BASH=/bin/sh BASH_ARGC=() BASH_ARGV=() BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0
-
Thread
News aus der Atmel Gerüchteküche
Know-How zu stecken, dass dann nicht transferiert werden kann, wenn Alternativen da sind. Denn AVR und AVR32 sidn ja bereits zwei komplett verscheidene Dinge, Know-How muss also sowieso erstmal wieder beschafft werden beim Wechsel
Da lese ich doch von einem Interview mit CEO Steven Laub. Sinngemäß soll Atmel für 32 Bit primär in ARM investieren und 8 Bit AVR bleiben.
-
Thread
maßloser Speicherverbrauch bei int-Division
Bei mir sind es 534 Bytes. AVR Studio 4.19. Es findet sich eine _udivmod64 Routine sowie prologue_saves und epilogue_restores im Code, womit fast alle Register gerettet bzw. restauriert werden.
. Oder linke ne bessere 64Bit Lib hinzu: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113673 Erst nach meinem Post fand die optimierte 64Bit-Lib auch Eingang in den AVR-GCC.
-
Thread
STM32F730R8T6 top P/L, crashkurs fragen
: > Die 64k Flash dürften aber ziemlich schnell voll sein. Aber nur für Schwätzer. Wenn man bedenkt, daß ein ATmega328 nur 32 KB hat, dann ist da noch reichlich Luft nach oben ;-) STM32 schrieb im Beitrag
m.n. schrieb im Beitrag #6006780: >> Die 64k Flash dürften aber ziemlich schnell voll sein. > Wenn man bedenkt, daß ein ATmega328 nur 32 KB > hat, dann ist da noch reichlich Luft nach oben Andererseits belegt gleicher Code auf ARM Controllern
-
Thread
Tetris auf dem AtMega8
Maschine wäre die Größe des ausgeführten Programms eigentlich nur durch den Adressraum begrenzt, d.h. 64 kByte wären drin, soviel kann sonst kein AVR. Beste Grüße, Bartl
Also "beliebig viel" halte ich für unmöglich :) Die Sache ist halt die, dass eine 32-Bit Adressierung wahrscheinlich die Sache recht langsam macht. Und 64 kByte ist immerhin noch acht mal soviel wie ein Mega8, ich denke des sollte für die meisten Spiele schon reichen. Insbesondere wenn
-
Thread
Frage zu CCL-Einheit in neueren AVR-Controllern
früher(tm) in einer bestimmten bestehenden uralten Schaltung durch einen FPGA bereitgestellt wurde. Der AVR ersetzt nun einfach nur diesen FPGA, ansonsten bleibt die bestehende Schaltung unverändert. > In diesem Fall hätte ich ganz einfach einen 3-UART > AVR verwendet. Der AVR128DA64 hat sogar *SECHS
über die CCL lernen können. Volker B. schrieb im Beitrag #7251064: > Warum nimmst Du dann keinen AVR mit DMA Weil ich aus diversen Gründen einen AVR-DB nehme, ganz einfach. Der langt- es wär nur die Frage gewesen ob die CCL hier eine Hilfe wäre. > Auch der ATXMega32A4-AU, der im Markt-Bereich
-
Thread
8Bit Grafikkarte für µC
32 Farben ? Wenn du 6 Bits benutzt hast du doch 64 Farben, oder ? Anbei mal mein akademischer Versuch einer 640x480x64 Grafikkarte. Sie benutzt einen 10-15ns 512Kb SRAM, und wird mit 32MHz getaktet.
muß im CPLD als Index in die Zeichsatztabelle benutzt werden. Der Vorteil ist das man nun mit einem 32-64Kb SRAM arbeiten kann und der AVR nur noch 9Kb beackern muß. Gruß Hagen, HaReddmann AT T-Online DOT de
-
Thread
Einsteigerfragen zur Anwendung und ähnlichem(AVR)
war damals bei mir was mit der UART... Verwirrt den Threadopener mal nicht bezüglich dem besten AVR für den Einstieg. Obs ein Mega16, 32 oder 64 ist, ist doch ZIEMLICH egal. Mal davon abgesehen, dass man die 16kilobyte von dem mega16 eh nicht so schnell voll kriegt anfangs.
Simon Küppers wrote: > Obs ein Mega16, 32 oder 64 ist, ist doch ZIEMLICH egal. Mal davon > abgesehen, dass man die 16kilobyte von dem mega16 eh nicht so schnell > voll kriegt anfangs. nö.... ich hab billigst mit dem Mega8 angefangen,
-
Thread
"Eigenes USB-Gerät" für eigene Software
avr schrieb im Beitrag #4673292: > Mit Full-Speed > erreicht man 64 KB/s. Ohne speziellen Treiber, ohne großen > Softwarestack, anschließbar an so ziemlich jedes Gerät mit USB. Was nützen mir 64KB
man kaum. Es sind nichtmal 64Byte die ich übertrage, zumindest nicht im 1. Endpoint, der 0. Endpoint setzt dies ja vorraus, wird aber auch nur einmal abgefragt. Ich arbeite mit 16Byte. avr schrieb im Beitrag #4673923: > Falls
-
Thread
PonyProg installation
Ingo L. schrieb im Beitrag #7215665: > Die Datei ist aber vorhanden im Ordner C:\Windows\System32\drivers Das wäre richtig für eine 32Bit-Version, aber falsch für eine 64Bit-Version. Da gehört der Treiber und die DLL nach %windir%\SysWOW64.
Ingo L. schrieb im Beitrag #7215665: > >> Die Datei ist aber vorhanden im Ordner C:\Windows\System32\drivers > > Das wäre richtig für eine 32Bit-Version, aber falsch für eine > 64Bit-Version. Da gehört der Treiber und die DLL nach %windir%\SysWOW64. Bringt leider nichts
-
Thread
double Binärisieren und zurück
nicht sicher ob er dann nur ein Byte kopiert. By the way: Sind double und float auf jeden System 64 bzw. 32bit breit? Gruß Peter
Char-Wert. Das geht nur mit Informationsverlust. > By the way: Sind double und float auf jeden System 64 bzw. 32bit breit? Nein.
-
Thread
Gibt es einfach zu handhabende "große" Rams (16/32MB?)
Es gibt SRAMs mit 64Mbit. Sind aber bissel teuer.
klang es eher nach chronisch-pleite-Selbstbau-ist-billiger-Projekt... ;) Ich würde es mit dem STM32F429I-Discovery versuchen: 64Mbit RAM -> /16 bit = 400.000 Samples /48kHz = 83 Sek Extern müsste nur noch ein 16-Bit Audio-Codec (ADC/DAC) über seriell (SPI) ran. Start/Stop/... über die I/O Ports
-
Thread
dspic ausreichend für Audio Effekte ?
Sekunden Mono sein. Na, endlich mal eine Ansage. Du solltest mit a) mind. 16 bit und b) mind 32 kHz Sampling Rate arbeiten. Macht dann 64000 Byte RAM. Evtl. reichen dann auch 64kByte (=65536 Byte). Mir wäre es zu knapp, da man ja auch IO-Buffer braucht -> Einer kommt per DMA rein, der zweite
Zusammen ~ 6.50 €. Dazu ein PICKIT 3 zum Programmieren und Debuggen. Wenn du später mit 24 oder gar 32 Bit arbeiten willst kannst du einen PIC32 nehmen. Auch im DIL Gehäuse erhältlich mit bis zu 64 kB internem RAM für Hall oder so, und mit I2S Schnittstellen für ein 24 Bit Codec. PICKIT 3 und IDE kannst
-
Thread
PC-Synthesizer mit Cubase
Bei 64Bit Systemen muss man einigermaßen aufpassen, dass die Soundkarte nicht nur ASIO Treiber für 64Bit hat. Wenn die VST-Host Software zB. nur 32Bit ist, benötigt man einen 32Bit ASIO Treiber dafür auch auf einem 64Bit Windows. Auch können höhere Latenzen entstehen wenn VST Plugins gebridged werden. Dass passiert wenn man zB. ein 32Bit VST in einen 64Bit VST-Host lädt oder ümgekehrt. Beim Bridgen laufen nämlich
-
Thread
Suche Library ADS1220 an ATmega328 ohne Arduino
so groß, daß die paar Kilobyte, die für Float nötig sind, auch einfach nicht stören. FÜr 8-Bit-AVR gibt es allerdings standardmäßig nur 32-Bit-Float, mit 64 Bit hat sich hier mal jemand beschäftigt: https://www.mikrocontroller.net/topic/85256 Ja, es ist hier auf µC.net eine Quasi-Religion,
64-Bit double gibt es seit GCC v10 (Release 2020). https://gcc.gnu.org/gcc-10/changes.html#avr
-
Thread
MPLAB X IDE v5.40
"MPASM is a 32-bit Windows application and will not run on 64-bit operating systems. A 64-bit PIC Assembler will be available with the MPLAB XC8 toolchain but will require migration." steht bei mir ;-)
zitter_ned_aso schrieb im Beitrag #6302242: > "MPASM is a 32-bit Windows application and will not run on 64-bit > operating systems. A 64-bit PIC Assembler will be available with the > MPLAB XC8 toolchain but will require migration." > > steht bei mir ;
-
Thread
Ein µC oder auf mehrere verteilen?
Tobias N. schrieb im Beitrag #3538095: > Bei allen AVR werden die MOSI, MISO und SCK Pins verwendet, einzige > Ausnahme sind die 64 Pinner Mega128/64/103. Diese Liste ist nicht vollständig. Du vergisst 90CAN32/64/128 und Mega 1281/2561, um nur einige
Frank K. schrieb im Beitrag #3538136: > Tobias N. schrieb im Beitrag #3538095: > >> Bei allen AVR werden die MOSI, MISO und SCK Pins verwendet, einzige >> Ausnahme sind die 64 Pinner Mega128/64/103. > > Diese Liste ist nicht vollständig. Du vergisst 90CAN32/64/128 und Mega > 1281/2561, um
-
Thread
Atmel noch zukunftsfähig? Gesperrt
Atmel bestand aus DEUTLICH mehr als aus den AVRs!!! Ich könnte mir vorstellen, dass sie bei den AVR32 ziemlich draufgezahlt haben.
nicht so lange wirklich ISO CAN-FD. Aber boah, das M-CAN Modul ist schon sehr fett, vorher die alte AVR CAN-Unit die Atmel mal aus irgendweinem 8051 übernommen hat mit 6 Message-Boxen im ATMEGA16M1, jetzt zwei Empfangs FIFOs mit jeweils bis 64 Elementen, dazu 64 Empfangs-Puffer, 32 Sende-Puffer, krasses
-
Thread
avr-gcc nutzt kein "Store Indirect and Post-Inc."
Hallo, ich verstehe gerade den avr-gcc nicht. Ich habe einen Attiny841 und möchte folgendes ausführen: [c] // highest_byte_in_value wird berechnt, ist dann 0 bis 3. switch (highest_byte_in_value) { case 3 : base64_buffer
schon mancher drüber gewundert haben, denn die üblicherweise als Index verwendeten int/unsigned sind 32 Bit breit, Adressrechnungen aber 64 Bit. Weshalb das ähnlich mies aussieht wie oben beim AVR: [code] movq %rsi, %rdx movl %edi, %eax shrq $24, %rdx movb