-
Thread
[V] Diverse Dinge
Sockel ATSTK600-TQFP144. Selten gebraucht voll funktionsfähig. Zusätzlich zu dem enthaltenem ATMEGA32L-DIP und ATMEGA2560 lege ich noch 3x AT32UC3A3256 bei. Foto: atstk600.jpg Referenzen: http://www.reichelt.de/AVR-STK-600/3/index.html?&ACTION=3&LA=446&ARTICLE=84348&artnr=AVR+STK+600&SEARCH=stk600
entwicklungskits-prozessor-mikrocontroller/7153678/ http://www.hdwireless.se/index.php/products/wi-fi-products Foto: Atmel-EVK1104-AVR32.jpg Preis: 100,- ---------------------------------------------------------------------------------------------------------------------------------- 8.0" LCD von Sharp Referenzen: http
-
Thread
PID-Regler: Wie schnell ist schnell genug?
/controller->taFactor) * controller->lastError 08008846: vadd.f32 s14, s14, s14 0800884a: vneg.f32 s12, s15 0800884e: vdiv.f32 s8, s14, s9 100 + (controller->kpFactor+controller->kiFactor+controller->kdFactor/controller->taFactor
vcmpe.f32 s15, #0.0 [/code] wichtig ist noch das man auch alles in float und nicht in double macht. Beim AVR wird da nicht unterschieden, aber beim ARM ist eine Konstante '0.8' ein double und dann werden
-
Thread
Modernes "Z80 Klein-Computer"-Analogon für Jugendliche/Kinder?
oder Lochraster. Und mit demselben Programmer und der gleichen IDE könnt ihr dann bis zum 300MHz 32 Bit MIPS PIC32MZ alles machen. fchk
interessehalber der Weg weiter Richtung Gigatron & co. (einzelne Gatter) oder Richtung Apple-][,C=64,NKC,RC2014,CP/M (komplexe Funktionsbausteine) geht zeigt sich dann. Jedenfalls sehe ich das etwa so als Vorstufe von 1-Chip-uC-Systeme wie Arduino,PIC,68HC05/-08/-11/-12,683XX,STM32, uva.
-
Thread
uC mit FPU und wenig Pins
@ Klaus (Gast) >Das sehe ich anders. Beispielsweise sind auf einem ATmega 32Bit-float >Rechnungen schneller als 64Bit-Integer (IAR als Compiler). Wirklich? Sind die FLoat-Rechungen so gut optimiert oder die 64 Bit so schlecht? Wobei 64 Bit auf dem avr gcc bisher sehr schlecht
AT32UC3C - bis 64 Pins runter
-
Thread
Image-Grabber für CVBS (bzw. FBAS) per STM32F103C8T6
sparen.) #### Bildauflösung Das schwächste Glied ist nicht der ADC sondern der USB. Mit dem STM32F103 ("USB Full Speed") sind nur 1 MByte/s möglich, also 64 Byte pro Bildzeile. Bei 1 Byte/Pixel sind das 59 Pixel/Zeile (Netto). Wenn mehrere Frames (mit unterscheidlichem x-Offset) zu einem Bild zusammengefasst
wählbar: [code] // - Modi // 0: 2.56 s / 1880 x 576 // 1: 1.28 s / 940 x 576 // 2: 0.64 s / 940 x 576 weniger Farbtiefe // 3: 0.32 s / 940 x 576 halbe XY-Auflösung & weniger Farbtiefe, // 4: 0.32 s / 480 x 576 halbe XY-Auflösung // 5: 0.16 s / 480 x 576 halbe XY-Auflösung
-
Thread
I2C-Bus terminieren? Genauer Uhrenquarz für RTC?
[[AVR - Die genaue Sekunde / RTC]]
ist der allerdings nicht, als Uhr taugt er nicht, nur als Wecksignal. Und wenn du die RTC in den AVR einbaust, mit 32KHz asynchron, dann weckt dieser Timer ihn alle Sekunde oder alle paar Sekunden aus dem Power-Save Modus.
-
Thread
Welchen PIC für Anfängerprojekte?
Es wäre wirklich mal an der Zeit für einen umfassendes Anfängertutorial so wie das für den AVR hier.
Ingo Schick schrieb im Beitrag #3561469: > PIC18F452 Der 18F64K22 ist dem eigentlich in vielen Beziehungen überlegen: -Mehr Timer -Mehr RAM, Flash und EEPROM -Mehr UART, SPI, I2C -Mehr CCP -Mehr ADC-Kanäle -Schneller: 40MHz vs. 64MHz -Billiger (TME)
-
Thread
Tipps zur Speicheranalyse gesucht
Wert sind die reservierten Speicher auf dem PC doppelt so groß wie auf dem uC. Könnte der Unterschied 64Bit vs 32Bit sein, muss aber im Detail schauen was das bedeutet. Etwas seltsam, dass valgrind 8 allocs meldet, hier aber nur 4 stehen. Vielleicht hab ich was übersehen.
bräuchten auch eine genauere Beschreibung darüber, in welcher Weise die PC-Version läuft, ob sie auf 32 Bit beschränkt ist, oder ähnliche Datenformateinschränkungen hat wie der Mc. Hätte man einen 64Bit Raspi, könnte man auch da nachsehen, was da abgeht.
-
Thread
Programm schützen
an sicher zu werden. Man sollte sich fragen wieviel mehr nun 2^128 im Vergleich zu 2^64 ist. Einfach mal ausprobieren und auf den Zettel die Zahl 2^64 einfach 2^64 mal draufkritzeln. Ich frage dann mal in 50 Jahren nach wieweit derjenige gekommen ist. Jetzt könnte das Argument des Praktiker
Zettel die Zahl 2^64 einfach 2^64 mal draufkritzeln. Ich frage dann mal in 50 Jahren nach wieweit derjenige gekommen ist." Fertig ;) 2^64 == 18446744073709551616 2^128 == 340282366920938463463374607431768211456
-
Thread
8bit Pointer bei großen AVR's
eigentlich sind die Pointer bei den AVR's YH:YL, XH:XL, ZH:ZL 16bit breit 65536 Byte adressierbar was 64Kbyte macht
es nicht gewagt mein Absturz-schwangeres Studio 6.2 diesbezüglich > zu bemühen), nicht aber im WinAVR-2010. Im WinAVR ist es gelöst, weil darin nicht der Compiler bemüht wird, sondern der Inhalt von <avr/pgmspace.h>. Die "pointer" der "far" Funktionen sind dort dementsprechend 32-Bit gross: http
-
Thread
AVR oder STM32 für Entwicklungsprojekt
für deine Anwendung weitgehend irrelevant. Wenn du Zeit hast, würde ich Dir zum STM32 raten, und zwar einem "Nucelo 64 STM32F103RB". Denn da ist der Programmieradapter/Debugger schon dabei. Wenn du unter Zeitdruck stehst, dann greife lieber zum AVR, und zwar einem Arduino Nano compatible
programmiert, wir wollen aber etwas moderneres benutzen und > können nicht entscheiden ob wir einen AVR oder einen STM32 benutzen > sollen. Eines vorab: Weder AVR noch STM32 sind die häufigsten µCs in der industriellen Praxis. Da müssstet ihr bei Renesas schauen. Das nur deshalb, weil die grauseligen
-
Thread
Z80: Aufteilung der Aufgabenverteilung auf ROM und RAM
genutzt werden und nicht einfach beim Start des Userprogs weggeschaltet werden wie derzeit. Der C64 schwirrt mir etwas im Kopf herum. Seine 64Kb waren in RAM und ROM aufgeteilt, manches lag übereinander und konnte umgeschaltet werden. Viele Funktionen konnte man direkt nutzen wenn deren Adresse bekannt
dabei bleibt es auch. Für alles andere gibts den STM32F4 Cortex.
-
Thread
Sekunden,Minuten zählen mit der Funktion Millis()
Egal, wie man die die 32 Bit Variablen kombiniert, aber auf einen "vernünftigen" 64 Bit ms Zähler kommt man da nicht. Da muss man sich schon etwas mehr Mühe geben. Nick M. schrieb im Beitrag #6520414: > Die Bastler sind
Beitrag #6520459: > Und jetzt jammer bloß nicht rum, daß man dazu eine extra Variable > braucht! Deine 64Bit Zähler sind auch nicht kostenlos, dort steckt die > Variable vier mal drin! Keine Angst, ich weiß sogar, dass ein 64 Bit Zähler doppelt so viel Platz braucht wie ein 32 Bit Zähler! > Wer mit
-
Thread
array copy in c?
Der AVR GCC und viele andere Compiler auch werfen exakt den selben Binärcode aus.
übertreibe. Aber genau so Vorschläge wie das hier Adam P. schrieb im Beitrag #6940356: > Aufm 32Bit System könnte man es sogar noch irgendwie dem Compiler > schmackhaft machen erst alle 32Bit durch den Bus zu jagen und dann den > Rest mit Modulo und Einzelbytes. > Evtl. würde das was bringen?
-
Thread
Arbeiten mit C und H Dateien
integer int16_t #define word uint16_t #define byte uint8_t #define dword uint32_t #define qword uint64_t #define int64 int64_t [/c] Damit wird auch Deine StdTypes.h portabel und Du musst die "doofen" Typen nicht weiter im Quelltext benutzen. Sehr interessant ist
Bedeutung Prozessor-abhängig ist (Bei x86 z.B. ist damit normalweise 16 Bit gemeint, bei ARM dagegen 32 Bit). Einen vorzeichenbehafteten 32-Bit-Typ gibt es gar nicht. Bei 64 Bit heißt der Typ mit Vorzeichen int64, der ohne qword. Was ist denn das für ein bescheuertes Namensschema? Über den Sinn bzw. Unsinn
-
Thread
C oder Pascal
Windowsprogrammierung überhaupt kein Problem. Die Sachen sind alle schon (einmal) definiert worden. Win 32, Win 64 und sogar Win CE wird unterstützt. > Dazu kommt, dass Borland und Nachfolger Embarcadero sehr > "geschäftstüchtig" mit Lizenzen umgehen, mir sind durch einen Fehler bei > Embarcadero alle
Postkunde schrieb im Beitrag #4015710: > Meine Version hat leider noch kein 64bit float... Das nennt sich auch Fix64: 32Bit Zahl + 32Bit Exponent
-
Thread
Multiplikationsroutine
erzeugte Assemblercode ist bestimmt schneller und kleiner als jede C-Routine. Peter P.S.: Aufm AVR oder 8051 funktioniert Deine Routine nicht, da dort int nur 16-bittig ist, deshalb long für 32Bit nehmen.
@Mario: schreiben wir gemeinsam was? Hier von mir eine extrem kompakte und schnelle mul32x32->64: C-Code zur Verdeutlichung und Erklärung: http://www.mikrocontroller.net/forum/read-1-343046.html#350551 und die Umsetzung in AVR-Asm (68HC08 hab ich schon auf meinem anderen PC, kommt
-
Thread
USB to TTL mit CH340
könntest, mag ich nicht raten. Unter Tools in der Arduino IDE ist folgendes eingetragen: Generic STM32F103C Series STM32F103C8(20k RAM. 64k Flash) STLink 72MHz (Normal) Smallest port ausgegraut Programmer grau: No programmers available for this board > > Bei Programmierung in der Arduino-IDE
Programm mir vier Menüunkte: Boardverwalter Arduino AVR Boards STM32 boards groups (..... STM32F1 Boards (Arduino_STM32) Die von der letzten Zeile sind die Richtigen. Wenn ich dann im Untermenü den "Generic STM32F103C series" wähle, lädt Arduino das
-
Thread
DS18B20 1-Wire Implementierung - Timing-Probleme
mir einen zusätzlichen IC besorgen > müsste. Wieso solltest du das müssen? Du benutzt einenSTM32F103C8 ...
du hast einen Hardware OneWire. Eine diskreten Opendrain Eingang benötigst du nicht, denn der STM32 hat einen eingebaut.
-
Thread
Linux wird nicht wirklich akzeptiert, woran liegt das ?
einer was von Kompatiblität unter DOS/windows! Das liegt meistens nicht an Windows, sondern am AMD64 Long Mode, der keine 16 Bit Real-Mode-Programme, mehr unterstützt. https://de.wikipedia.org/wiki/X64#Betriebsmodi Installiere das ELV Programm mal unter einer 32 Bit Version von Win 7, dann könnte
Das Nachhausetelefonieren habe ich ihm auch so gut wie es möglich ist abgewöhnt. Und wo es mit W10X64 in einigen Fällen überhaupt nicht geht, umschiffe ich solche Klippen einfach mit VMWare Player mit W7X32 bzw. W-XP32 und Linux Mint für Makefile GCC Projekte, installiert. Für gewisse ältere, mir noch
-
Thread
uint32 * uint32 = neg. Zahl ?
zweier uint32-Zahlen ein negatives Ergebnis. Zuerst dachte ich an einen Überlauf, diesen kann ich aber ausschließen. Hat jemand von euch eine Idee, woran das liegen kann? MC: ATmega32 IDE: AVR-Studio 5 In Main
Die Multiplikation zweier 32bit-Zahlen ergibt eine 64bit-Zahl. Kanns sein, dass dein Problem hier her kommt? ;)
-
Thread
Pic Programmierung
------------ >die teuren PIC18 arbeiten noch mit 5V, die günstigeren mit 3.3V; alle(?) >24/30/33/32PICs arbeiten nur noch mit 3.3V versorgungsspannung (intern >arbeiten die sogar nur mit 2.5V). => Was für ein Durcheinader! Die klassischen Atmel AVR laufen alle bei 3.3V und 5V (viele sogar von
/AVR-Tutorial http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
-
Thread
Anfängerfrage zum 74hc590 Zähler
@Falk Brunner: Er schreibt von einem 32-Bit-Adresszähler. Das sieht nicht so aus, als wolle er mit dem SRAM den Datenspeicher des AVR erweitern. @martin: Hui, da fällt mir gerade auf: 32 Bit sind ja eine ganze Menge. Damit kannst du
bis zum 32. Ausgang) ein Stückchen zurück ;-). Mit AC-Typen (ca. 125ns) geht es schon besser. Wenn der AVR allerdings nichts anderes tut, als mit maximaler Geschwindigkeit den CCK zu toggeln (125ns Periodendauer
-
Thread
AVR AtMEGA328P-PU u. I2C in Arduino: Probleme mit mehrdimensionale Arrays
Zeitabstand. } void sendarr(byte led[8][8]) { Wire.beginTransmission(8); for (int i=0;i<=64; i++) { Wire.write(led[y][x]); //Das geht nicht, auch nicht wenn man versucht x++; // es auf Wire.write(led, 64); zu bringen. if (x==7) { x=0; y++;
nicht achten. Das ist ein Quick&Dirty Framework, das nur einfachen Ansprüchen genügt. Mehr als die 32 Bytes gehen halt nicht.
-
Thread
Programmspeicher beschreiben
was im RS232Buffer steht. Fängt mit dem wert 3C an ( grün ) und hört bei 3C auf ( grün ) das sind 64Byte ( 32 Wörter ) Im Bild Programm (2.) sieht mann was im Programmspeicher steht nach dem beschreiben. Hört auch mit 3C auf nach 64Byte ( 32 Wörter ) aber die ersten beiden sind weg und es steht FF
wohl so das man 1. Page löschen 2. Buffer beschreiben ( r0 und r1 sind die werte eines Worts das 32 mal= 1 Page 64 Bit) 3. Befehl für Buffer in Programmspeicher schreiben Und genau dabei fehlt auf einmal das erste Wort. wird aber gelesen. Meine frage zur fehlersuche ist unter anderem wo ist
-
Thread
Diverse Variablen remanent machen
https://ww1.microchip.com/downloads/aemDocuments/documents/DEV/ProductDocuments/UserGuides/MPLAB-XC32-Compiler-UG-PIC32M-DS-50002799.pdf Edit: Bild und Datenblattlink hinzugefügt.
und generiert einen 32 Bit Wortzugriff der dann unter Umständen unaligned ist. Dann fällt die Kuh um.
-
Thread
Atmega32 kleines Problem mit Modellservoansteuerung
<avr/io.h> #include <avr/interrupt.h> #define servo_anzahl 1 uint16_t isvalue=1000; uint16_t value[1]={1500}; uint16_t a=0,b=0; ISR (TIMER2_COMP_vect) // µs Takt { uint8_t i; isvalue++;
<avr/io.h> #include <avr/interrupt.h> #ifndef F_CPU #define F_CPU 8000000ul #endif #include <util/delay.h> #define SERVO_ANZAHL 8 #define SERVOPORT PORTA volatile uint8_t value[SERVO_ANZAHL]={128,128,128,128,128,128,128,128
-
Thread
USB MIDI Gerät
Wenn du vor hast mehrere Midi Controller zu bauen, würde ich die AVR's weglassen und stattdessen ARM's nehmen. Ich selbst habe viel mit den maple mini clones (3-4 Euro auf aliexpress, bzw. alle anderen STM32F1 dev boards) gebastelt (u.a. midi controller, synthesizer
Versandkostenfrei) = 3.63 EUR pro Stück. http://www.aliexpress.com/item/5PCS-LOT-leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/1400682373.html (ich bevorzuge die BAITE Modelle) Die Eckdaten sehen dann gleich ganz anders aus: 72MHZ 64/128kB Flash 20KB RAM 7 Timer 3x (!) USART DMA massig Pins mit PWM und
-
Thread
Atmel Studio 6.1 vs. 4.18
sein. Im Simulator funktioniert es. >Eine mögliche Abhilfe sehe ich im Umstieg auf das neueste AVR-Studio >V6.1, wo doch dann alle diese Bugs beseitigt sein sollten - oder? Dieser Bug ist behoben. >Ist es eigentlich möglich beide Versionen auf einem PC (32er XP) >parallel installiert zu
Version - vllt. ist >da ja schon der Fehler behoben worden. Nein, damit habe ich das getestet. AVR Studio 4.19 ist mW. AVR Studio 4.18 + Service Packs. MfG Spess
-
Thread
Mikroprozessorboard
vielfältigen und getrennten Adressräume grenzen ihn sehr deutlich von klassischen Mikroprozessoren ab (AVR ebenso). Da sind von-Neumann-Architekturen üblich.
64k DRam müßte ich noch haben...
-
Thread
Verzweifelt keine Anzeige am LCD
welches Bit ist damit gemeint? Die Zählung geht von 0 bis 7, es ist also das viertniederste Bit, s.a. "AVR-Tutorial: IO-Grundlagen", allgemein und umfassend das ganze "AVR-Tutorial". Näheres zum Befehl sbrc finden Sie in "Atmel AVR 8-bit Instruction Set, Instruction Set Manual".
Informatiker spinnen, sondern wegen: [pre] Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0 Wert: 128 64 32 16 8 4 2 1 oder 2^7 2^6 2^5 2^4 2^3 2^2 2^1 2^0 [/pre]
-
Thread
Compiler und Compilierte Dateien
uC dass eine ungemein komplizierte Formal enthält. Die Formel ist unter Kontrolle, würde aber bei 64 statt 32 Bit pseudo double genauere Ergebnisse liefern. Nun habe ich ein schweineteures IAR-Studio, komme damit aber überhaupt nicht klar. Der Versuch das mit WIN-AVR problemlos zu compilieren Programm
gegen die Interfaces und die nach elf32-avr konvertierten Objekte.
-
Thread
Wie I2S Datenstrom mit AVR M88 einlesen
Wandeln, analog filtern und mit dem ADC des AVR's einlesen Wenn du es rein digital machen willst denke ich kannst du das vergessen. Quadrieren von 24 bzw 32 Bit. Teilen einer 32 bzw 64 Bit Zahl durch 16 bzw 32 Bit. Wurzelziehen aus einer 32
Wenn du es rein digital machen willst denke ich kannst du das vergessen. > Quadrieren von 24 bzw 32 Bit. Teilen einer 32 bzw 64 Bit Zahl durch 16 > bzw 32 Bit. Wurzelziehen aus einer 32 Bit Zahl. Und das alles in 10-20µs > (200-400 Takte bei 20MHz pro Sample). Sehr sportlich. Es gibt auch LookUp-Tables
-
Thread
Hilfe bei AD-Wandler!
ADC_PRESCALE_8 ADC_ADPS2_0(0,1,1) #define ADC_PRESCALE_16 ADC_ADPS2_0(1,0,0) #define ADC_PRESCALE_32 ADC_ADPS2_0(1,0,1) #define ADC_PRESCALE_64 ADC_ADPS2_0(1,1,0) #define ADC_PRESCALE_128 ADC_ADPS2_0(1,1,1) // -------------------------------------------------------- // ADC Prescale //
ADC_PRESCALE_8 #elif (F_CPU / 16) <= ADC_SPEED # define ADC_PRESCALE ADC_PRESCALE_16 #elif (F_CPU / 32) <= ADC_SPEED # define ADC_PRESCALE ADC_PRESCALE_32 #elif (F_CPU / 64) <= ADC_SPEED # define ADC_PRESCALE ADC_PRESCALE_64 #else # define ADC_PRESCALE ADC_PRESCALE_128 #endif // ----
-
Thread
Problem mit make unter win7
Achja nur als Hinweis, unter Win7 64-Bit will sich WinAVR in C:\Progam Files (x86)" installieren, aber scheinbar mag GCC nicht die Klammern von "(x86)". Darum würde ich neben dem Tipp von Rufus auch daran denken (sofern x64 installiert
Hallo, ich habe die AVR_Toolchain_3.0_149 auf einem zweiten Windows 7 Rechner installiert. Diesmal mit Windows 7 Professional 32 bit. Bekomme dort genau die gleiche Fehlermeldung: avr-gcc (AVR_Toolchain_3.0_149) 4.4.3
-
Thread
long double übertragen
versteh ich dann nicht, wieso der PC die Zahl 123.1923 exakt festhalten kann, wenn in beiden Fällen mit 64bit Gleitkommazahlen gerechnet wird (long double beim PIC, XC32 Comiler; double im PC, C#). Mir gehts eigentlich gar nicht darum, irgendwelche Zahlen zum PC zu übertragen (zumindest nicht in übertriebener
Wildwuchs bezüglich Fließkommaformaten. Bei 8Bit Rechnern ist meistens double das Gleiche wie float(32bit). Beim PIC32 ist wohl long double das gleich wie double (64bit). Von wegen ist doch alles genormt wie einer hier schrieb. Und dann kommt noch die Ausgaberoutine. Wer weiß was die aus double macht
-
Thread
AVR-Frequenzzählermodul 1Hz - 40MHz
bei Axel für die Anregung und Anleitung bedanken. Ich habe das Projekt sehr ähnlich auf einem PIC32 nachgebaut. Aufgrund der anderen Hardware (z.B. zwei interne 32 Bit Counter oder 64 Bit Fließkommazahlen) war mein Projekt einfacher zu realiseren. Da ich aber neu in der PIC Welt bin, stand das Erlernen
und Anleitung bedanken. Danke für die Blumen! > Ich habe das Projekt sehr ähnlich auf einem PIC32 nachgebaut. Aufgrund > der anderen Hardware (z.B. zwei interne 32 Bit Counter oder 64 Bit > Fließkommazahlen) war mein Projekt einfacher zu realiseren. Da ich aber > neu in der PIC Welt bin, stand
-
Thread
Update von Winavr2010 auf gcc 4.8 Howto
%20%28Win32%29/ bzw. zzt. aktuellesten link http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/avr-gcc-4.8_2013-03-06_mingw32.zip/download Entpacken und kurz auf Viren
Version reingestellt. Hier der link für 4.9.2 http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/avr-gcc-4.9.2_2014-09-12_mingw32.zip/download Ich habe aber noch nix getestet, keine Zeit. Wird wohl jemand anderes schaffen ;)
-
Thread
LUFA Einsteiger: Demo VirtualSerial funktioniert nicht
full speed USB device using ehci_hcd and address 9 [ 1036.288341] usb 1-2.4: device descriptor read/64, error -32 [ 1036.464310] usb 1-2.4: device descriptor read/64, error -32 [ 1036.640153] usb 1-2.4: new full speed USB device using ehci_hcd and address 10 [ 1036.712136] usb 1-2.4: device descriptor read/64, error -32 [ 1036.888101] usb 1-2.4: device descriptor read/64, error -32 [ 1037.064190] usb 1-2.4: new full speed USB device using ehci_hcd and address 11 [ 1037.472273] usb 1-2.4: device not accepting
-
Thread
Display mit AVR
ein Cyclone I reicht schon aus um einen 8 Bit Prozessor plus VGA Controller (mit 64 Farben und 512 kByte Framebuffer) im FPGA zu implementieren. Bei grösseren FPGAs reichts dann für einen 32 Bit Prozessor und High Colour VGA Controller mit ein paar MB RAM. Es gibt Eval Boards,die das
. > Board: http://www.atmel.com/dyn/products/tools_card.asp?t... Vielleicht probierst du einen AVR32: http://www.elektronik-projekt.de/thread.php?threadid=4404&threadview=0&hilight=&hilightuser=0&page=1 5 letzter Beitrag auf der ersten Seite ( mit dem kleinen Video) Gruß, Daniel
-
Thread
Arrays, Pointer und Schleifen (avr-gcc)
maschine kann sizeof unterschiedliche Werte für dasselbe Datentyp ausgeben, meistens gilt aber auf einer 32bit maschine sizeof(char) = 8 sizeof(short) = 16 sizeof(int) = 32 sizeof(long) = 32 sizeof(long long) = 64 wenn jetzt dein Array aus 5 Elementen besteht, dann char x[5]; // 5 * sizeof(char) =
kann sizeof unterschiedliche Werte > für dasselbe Datentyp ausgeben, meistens gilt aber auf einer 32bit > maschine > sizeof(char) = 8 > sizeof(short) = 16 > sizeof(int) = 32 > sizeof(long) = 32 > sizeof(long long) = 64 Nein. sizeof(char) ist per definitionem in C immer gleich 1 -- selbst
-
Thread
µC mit viel RAM für Touch TFT mit "Wischen"
zwar lauter Komfort-Funktionen bieten, aber mal ehrlich, momentan kommt er mit einem winzigen 8-bit AVR aus. Ich habe es nicht genau angeschaut ob es funktioniert, aber würde er nicht schon alles ausreichend für seine Effekte schaffen mit bspw. folgender Kombination eines PIC32MX130F064D und einem
Leiterplatte erstellen lässt). Das sind 3.60 Euro exkl. Mwst. http://de.farnell.com/microchip/pic32mx130f064d-i-pt/ic-mcu-32bit-64kb-flash-44tqfp/dp/2097777 http://de.farnell.com/alliance-memory/as6c1008-55sin/sram-1mb-2-7v-5-5v-128kx8-sop32/dp/1562898 Will er noch USB so muss er eben etwas tiefer
-
Thread
Mikrocontroller - die Qual der Wahl, oder doch die Wahl der Qual?
STM32F0 mit 8MHz ist immer > noch um ein vielfaches schneller als ein AVR mit 16MHz. Das bezweifle ich allerdings. Er mag schneller rechnen können, aber das wär's dann auch schon.
hat. Das stimmt so auch nicht, denn es gibt durchaus kleinere µC Chips mit ARM Kern. Beispiel: STM32F0xx Der hat zwar einen 32 Bit Cortex-M0, ist dennoch mit relativ wenigen Pins ein kleiner Typ. Ich würde den eher als Ersatztyp für den AVR ansehen. Die großen wie z.B. STM32F4xx sind in der Tat
-
Thread
Ethersex mit Mega 1284p
avr5 atmega16 atmega161 atmega162 atmega163 atmega164p atmega165 atmega165p atmega168 atmega169 atmega169p atmega32 atmega323 atmega324p atmega325
atmega3250p atmega329 atmega329p atmega3290 atmega3290p atmega406 atmega64 atmega640 atmega644 atmega644p atmega645 atmega6450 atmega649 atmega6490 atmega128 atmega1280 atmega1281 atmega16hva at90can32 at90can64 at90can128
-
Thread
Möglichst stromsparend auf uSD Karte loggen
Moin, Ich möchte Daten (16bit Integer Zahlen) einigermaßen hochfrequent (16..32..64Hz, gerne auch öfter) per I2C einlesen und auf eine SD Karte Schreiben. Grundsätzlich kein großes Problem, jedoch soll das ganze auch einigermaßen Stromsparend werden, am liebsten würde ich mit
Tage durchmessen. Wenn alles ständig wach bleibt wirds wohl schwierig. Besser Controller mit 13,32,64,gern auch öfter, Hz aufwecken und Daten im RAM sammeln. Wenn RAM voll, SD-Karte wecken, Daten schreiben und alle weiterschlafen lassen.
-
Thread
avr-gcc 5.3.1: lto Problem mit Flash > 64k
(frame_name)); update_display(frame_buffer); [/c] Das funktioniert bis 64k auch ganz normal mit dem PROGMEM-Attribut. Über der 64k-Grenze sind die Daten ja nicht mehr mit 16bit adressierbar, was einen anderen Zugriff erfordert. Die avr-libc bietet dafür folgendes: [c] extern
Zugriff irgendwie fehlerhaft sein. Gibt es irgendwas, was man bei dem Zugriff auf Daten im Flash > 64k beachten muss? Oder könnte das etwa ein Bug im Compiler sein? Mit freundlichen Grüßen, N.G. Eckdaten: avr-gcc-5.3.1, binutils 2.25
-
Thread
Ein paar Fragen zum Umstieg auf die STM32 Reihe
I2S Schnittstelle nutzt mir das nichts. Auch das geht >Und dann auch nur 16Bit Timer auf einem 32Bit Controller... Hab ich schon >beim STM32F1 nicht verstanden was das soll. Die laufen doch permanent >über. Unsinn. Was haben 32bit Register mit 32bit Timern zu tun? Läuft da die Zeit 64k x schneller
hoffentlich nicht auf die Lösung mit der SPI Schnittstelle? >>Und dann auch nur 16Bit Timer auf einem 32Bit Controller... Hab ich schon >>beim STM32F1 nicht verstanden was das soll. Die laufen doch permanent >>über. > Unsinn. Was haben 32bit Register mit 32bit Timern zu tun? Läuft da die > Zeit 64k
-
Thread
AVR Bezeichnungen
ATmega103, möglicherweise fallen auch ATmega161 und ATmega163 in diese Gruppe. Danach dann ATmega16/32/64/128, die bilden die zweite Generation. Die aktuellen ATmegas bilden die dritte. Der ATmega2560/2561 ist ein wenig zwischen den letzten beiden. Der hat sein Leben mal als ATmega256 anfangen
, dass die Timer/PWM Module erweitert wurden. Ich hatte beispielsweise einen Timer auf einem ATmega64 laufen. Nach der Umstellung im AVR Studio auf einen neueren ATmega329 tauchten dann compilerfehler auf, da es von einem Register (TCCR0) früher nur ein Register und jetzt ein A und ein B Register gab
-
Thread
Gibt es für microSD >64GB ein FS für Atmel µC ?
@abc (Gast) >- ATMEL AVR µC (Modell egal) Da gibt es viele. 8051, AVR, ATXmega, dievers 32 Bit ARM. AVR32 auch noch. >- microSD >32GB lesen/schreiben Haben wir bereits durchgekaut. Wenn es standardkonform sein soll
mal wieder einkriegen ? > Ist Fön oder was ? > Mein aktuelles Problem ist die Vorgabe: > - ATMEL AVR µC (Modell egal) Dann nimm den AT32UC3A3256AU: 32-bit AVR Microcontroller, Audio version, 256KB Flash, 144-pin, SD/SDIO Card. Alles was dein Herz (oder das deines Managers) begehrt ;-) > - microSD
-
Thread
for-schleife rückwärts bis auf 0 laufen lassen probleme
sowas? Ist ne ernsthafte Frage, ich kann mir das nicht vorstellen. Benutzt man tatsächlich lieber 32 Controller aus 32 Familien mit 32 Compilern und Spezialitäten, anstatt bei einer Familie zu bleiben und die richtig von 8pin bis 144pin zu kennen? Ich mein, bei AVR, PIC und auch STM32 ist die Bandbreite
entwickeln was dann von tausenden Leuten auf verschiedensten Plattformen genutzt wird? > Ich mein, bei AVR, PIC und auch STM32 ist die Bandbreite so groß, da > findet sich sicher was. Und wenn man wechseln muss, weil es den xxx > nicht in AVR gibt, sind eh alle Codebasen Müll, weil uralt und auf 8 > statt