-
Thread
Welchen µC-Typ für neues Projekt?
Anwedungen sein werden. Definiere "viel" und "zeitkritisch". Ich benutze häufig auf AVRs float und 64Bit integer ohne Probleme. Der AVR-GCC unterstützt leider kein double.
werden. Meine Möglichkeiten die > ich bis jetzt so sehe wären folgende: > > Atmel ATxmega > Atmel AVR32 > Atmel ARM > ST ARM Du kannst auch einen dsPIC33EP (140 MHz/70 MOPS, 16 Bit mit DSP-Erweiterungen) oder einen PIC32MX (32 Bit 80 MHz/80 MOPS, MIPS-Kern) verwenden. Die gibts von klein (28 Pin
-
Thread
2* UB8830D was mach ich nur mit Ihnen?
genannten Tastatursteuerungen waren sicher nach FuA 12/90 (K7669). Zwei der Leiterplatten für die 64-pol. Prozessoren hab ich sogar auch. Und sechs dieser Prozessoren sind auch noch da :-) . Das wird was für lange Wintertage.
kein Programm, .... Die Anzahl meiner Grauen Zellen ist begrenzt und wenn, mache ich das mit einem AVR. Der UB88xx war zu seiner Zeit modern. Aber heute nicht mehr.
-
Thread
Neue AVR-Tiny Generation, neue B-ATMegas, neue Entwicklungstools
Ich arbeite viel mit 32 Bittern. Oft greife ich aber immer noch zu einem AVR oder PIC. Weil ich das DIP18 oder DIP28 Gehäuse mag. Wie der rechnet ist mir egal.
Pinner. 12bit ADC wäre auch nicht schlecht. Da wir CAN (fast) immer benötigen, ist unser standard AVR notgedrungen der AT90CAN128. Ist zwar alt, aber gut beschaffbare Lagerware. Die neueren ATmega64M1 waren zum Zeitpunkt der Entscheidung immer noch nur sporadisch zu erhalten.
-
Thread
Probleme mit _delay_ AVR Atmel32
: 11 24 eor r1, r1 56: 1f be out 0x3f, r1 ; 63 58: cf e5 ldi r28, 0x5F ; 95 5a: d8 e0 ldi r29, 0x08 ; 8 5c: de bf out 0x3e, r29 ; 62 5e: cd bf out 0x3d, r28 ; 61 60: 0e 94 36 00 call 0x6c ; 0x6c <main> 64: 0c
damit so ihre Probleme haben. Heute habe ich ein reales Board (Easy AVR V6) angeschlossen und schon lief das Ganze auf Anhieb...
-
Thread
Minutengenaue 24 Stunden-Wortuhr - wer will mitbauen?
Was hat das mit "notwendig" zu tun? nix, aber mit basteln und Herbert hat ja eher einen Hang zu AVR ;-)
läuft. Ich finde es erstrebenswert, dass wir einen _gemeinsamen_ Code haben, der sich für ARM _und_ AVR compilieren lässt. Ich hatte das mal mit AtmelStudio und [c]#ifdef _AVR_IOM2560_H_ // … #ifdef _AVR_IOM328P_H_ // …[/c] gemacht. Ging super! … oder zumindest gemeinsame .h-Datei-Schnittstellen
-
Thread
AMTEL Evaluationsboard 2.0.1 von Pollin
bestellt (und auch schon im Haus): 1 x Bausatz Atmel-Evaluations-Board V2.0.1 von Pollin 1 x DIAMEX ALL AVR Programmer USB-ISP für alle AVR-Controller von Reichelt 1 x ATMEGA 88-20 PU ATMega AVR-RISC-Controller, DIL-28 von Reichelt Bevor ich nun mit dem Zusammenbau des Evaluations-Boardes beginne, habe
@ Harald Fuckar Fürs Debuggen mit der Hardware empfehle ich den AVR-Dragon.
-
Thread
Welche ARM Modelle eignen sich für Anfänger?
weiter AVR und höre mir an das ARM die Zukunft sei ^^
mit flexiblen Prioritäten, Multitasking etc. etc.). Ich hätte instinktiv sehr wenig Lust das mit dem AVR irgendwie hinzufrickeln.
-
Thread
WiFi Relais mit ESP8266 ESP-01 Modul (Bascom)
; PROVIDE ( aes_decrypt_init = 0x40008ea4 ); PROVIDE ( aes_unwrap = 0x40009410 ); PROVIDE ( base64_decode = 0x40009648 ); PROVIDE ( base64_encode = 0x400094fc ); PROVIDE ( bzero = 0x4000de84 ); PROVIDE ( cmd_parse = 0x40000814 ); PROVIDE ( conv_str_decimal = 0x40000b24 ); PROVIDE ( conv_str_hex
0x40003bbc ); PROVIDE ( uart_rx_one_char = 0x40003b8c ); PROVIDE ( uart_rx_one_char_block = 0x40003b64 ); PROVIDE ( uart_rx_readbuff = 0x40003ec8 ); PROVIDE ( uart_tx_one_char = 0x40003b30 ); PROVIDE ( wepkey_128 = 0x4000bc40 ); PROVIDE ( wepkey_64 = 0x4000bb3c ); PROVIDE ( xthal_bcopy = 0x40000688
-
Thread
warum __inline zwingend erforderlich?
Jetzt funktionierts! :-) [c] #include <avr/pgmspace.h> * * * const uint8_t PROGMEM Wave_Tab[18] = {1,2,4,8,16,32,64,128,255,128,64,32,16,8,4,2,1,0}; * * * Helligkeit = pgm_read_byte(&Wave_Tab[n]); * * * [/c] __inline ist nicht
übergibt i natürlich in R22/23, hier für ATtiny24: [avrasm] buh: push r16 push r17 push r28 push r29 in r28,__SP_L__ clr r29 subi r28,lo8(-(-18)) out __SP_L__,r28 movw r16,r24 ldi r22,0 ;; da ldi r23,0 ;; und da movw r24,r28 adiw r24,1 rcall yum ;; blabla
-
Thread
sprintf gibt zu viele hexadezimale Ziffern aus
Auf meinem Computer ist unsigned long int 32bit groß. Ich nutze 32bit Linux. Für 64bit müsste ich long long schreiben. Wenn (1<<15) als int ausgeführt wird, warum ergibt dann (1<<16) die Ausgabe 0x10000 (sowohl unter Linux als auch auf dem AVR)? [code] #include <stdio.h> #include
Formatspecifier (für hex-Ausgabe) für uint32_t dann *PRIx32* Siehe dazu auch: http://www.nongnu.org/avr-libc/user-manual/group__avr__inttypes.html PRIx32 ist demnach für den AVR gleich "lx". Unter Linux (32 oder 64 bit) ist es schlicht und einfach "x".
-
Thread
switch case optimierung
Vermutlich sogar noch mehr... http://rn-wissen.de/wiki/index.php/Assembler-Dump_erstellen_mit_avr-gcc
> Hast du da einen Disassembler? Ja, du wahrscheinlich auch ;-) > Welchen? Das Ding heißt avr-objdump und ist Bestandteil des GNU-Binutil-Pakets, das überlicherweise zusammen mit dem AVR-GCC installiert wird. Der Aufruf: [pre] avr-objdump -m avr -D ATtiny10.hex [/pre] Etwas arg viel
-
Thread
Funktion wird nicht aufgerufen
standen die "DDn" Makros drin. Verwendet wird ein ATMega8-AU. Die Fuses sind auf internen 8MHz Takt 64ms Delay gestellt, ansonsten auf Auslieferungszustand. Compiliert wurde mit dem AVR-Studio 6. Zuvor hatte ich mit Xcode in Verbindung mit AVR-GCC aus dem AVR-Crosspack gearbeitet. Das Resultat war
; 61 32: 1e d0 rcall .+60 ; 0x70 <main> 34: 20 c0 rjmp .+64 ; 0x76 <_exit> 00000036 <__bad_interrupt>: 36: e4 cf rjmp .-56 ; 0x0 <__vectors> 00000038 <susi>: #include <avr/io.h> #include <util/delay.h> void susi(void){
-
Thread
Ist das ein Bug im Compiler?
ldi r28, 0x43 ; 67 64c2: d7 e3 ldi r29, 0x37 ; 55 64c4: 6f e0 ldi r22, 0x0F ; 15 64c6: 7e e3 ldi r23, 0x3E ; 62 64c8: 41 e0 ldi
if (!mask) { mask = 1; 64ec: 41 e0 ldi r20, 0x01 ; 1 Pointerverschieben 64ee: 34 96 adiw r30, 0x04 ; 4 64f0: 24 96 adiw r28, 0x04 ; 4 64f2: 6f 5f
-
Thread
Radig NetIO Atmega644P Scannerzeile auslesen
__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__) #define ETH_INT_ENABLE EIMSK |= (1<<INT2) #define ETH_INT_DISABLE EIMSK &= ~(1<<INT2) #endif [/c] im enc28j60.c [c] #if defined
/elektronik/enc28j60.htm [c] Leider ist es nicht möglich die Software von Ulrich Radig direkt auf den AVR NET IO zu laden, da eine Signalleitung zur Steuerung des ENC28J60 anders ist ! Es handelt sich hierbei um das
-
Thread
Projekt Schublade per IR-Remote
gib mir auch hier ein Beispiel für mein Vorhaben passend. - Im Moment hab ich halt nur die Atmel AVR-Bastelplatte. Hab keine Ahnung wie man einen Controller ohne Bastelplatte programmiert, egal ob Arduino (der ja auch auf AVR basiert) oder sonst einen. Aehm... hilfe - oder so? - Ich pack in meinen
im Bereich Eingänge (Wie kommen Signale in den µC) an. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Eing.C3.A4nge_.28Wie_kommen_Signale_in_den_.C2.B5C.29 Unter dem Unterpunkt *Taster und Schater* werden Pull up und Pull down Eingangsbeschaltungen kurz angeschnitten. Kurzfassung:
-
Thread
VGA Terminal mit ATMega644
ermöglicht. Und nein, das ist definitiv nicht C... https://de.wikipedia.org/wiki/Fetischismus_%28Religion%29
PIC24FJ256DA206. 96k RAM eingebaut, Grafikcontroller drin, Grafikbeschleuniger drin. Und das alles in einem 64 Pin TQFP. Es gibt auch ein Leben nach dem AVR. fchk
-
Thread
16x2 LCD Langsamer Displayaufbau
benutzen darf. _delay_ms(dauer); MÖÖÖP! FALSCH! https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 Wenn es variabel sein soll, dann so. [c] void var_delay(uint16_t time_ms) { while(time_ms--) _delay_ms(1); } [/c]
mehrere Werte aufmitteln, notfalls schneller ! [c] ADCSRA |= (1 << ADPS2) | (1 << ADPS1); // 64 prescale for 4Mhz [/c] könnte man ja auf kleineren prescale setzen http://www.mikrocontroller.net/articles/AVR-Tutorial:_ADC Beispiel 8 MHz Prozessortakt: 8.000.000Hz / 200.000Hz = 40
-
Thread
avrdude schreibt nur bis 64 byte in den flash-speicher
mit größer werdenden Programmen kamen neue Probleme bei der Übertragung. Bei allem was größer als 64 byte ist bricht avrdude den Vorgang ab. [code] john@pc0815:~/avr/Beispielprogramme$ avrdude -c avr911 -p m8 -P /dev/ttyUSB0 -B 50 -U flash:w:timer2.hex:i Connecting to programmer: . Found programmer
allerdings auch, das avrdude zwar erkennt das der Programmer 128Byte Puffer hat, aber trotzdem nur 64 Byte sendet. Die default avr910 Programmer hatten immer nur 64 Byte. Ist der Source für den Programmer frei verfügbar? Es wundert mich auch das die stk500v2 Variante nicht klappt, woher stammt
-
Thread
Geisterbilder auf einer 8 x 8 Matrix
Zeilen mit nem N-Kanal FET... Spannungsteiler ( 1 kOhm zum Gate --> 1MOhm gegen GND ) FET: PMN28UN
einer 8x8 Matrix ist eine LED nur 1/8 der Zeit an, und ohne FETs bekommt er nur die 20mA Strom aus dem AVR, und die gilte für alle 8 LEDs einer Reihe zusammen. Also leuchtet seine LED so hell, als würde man sie mit 0.3mA betrieben.
-
Thread
RC5 Implementierung (HILFE)
vergehen x(TIMER0_COMPA_vect) um ein halbes bit zu übertragen. x = (889 us / (1/36000kHz)) * 2 = ~64 oder liege ich da falsch? Aber irgendwie ist die Dauer eines halben bits länger als 899 us so um die 1 ms laut Oszilloskop. Siehe bild (fieldbit 0 zoom) Ich weis nicht, woher das kommt. Sieht vielleicht
vergehen x(TIMER0_COMPA_vect) um ein halbes bit zu übertragen. > x = (889 us / (1/36000kHz)) * 2 = ~64 > oder liege ich da falsch? Und ich kann in deinem Code weder Timer0 noch OCR0A finden. Oder liege ich da falsch ?
-
Thread
Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega
Bei meinem Rechner mit Win10 64bit funktionierte es mit dem Treiber pl2303_64bit_installer.exe im Anhang. (Ich hoffe das ich den Treiber hochladen kann und darf) Gruß Detlef
P.S. Nutze Win10/64bit
-
Thread
Thermomix Rezeptchips
7a9f fd59 438d 5000310 d62e 537c dc77 4c7a 29bc 6fa2 9805 8920 5000320 9596 4029 fda5 429c 02fe ba28 e0f2 44b7 5000330 0765 9fc7 5b49 f18c 14be 3959 6e04 08b7 5000340 ace2 e6fc 8d9b a3e1 1c19 9c77 7b3d 6fd8 5000350 1a3e 9fb9 db41 9b64 6094 a79b ea62 9fdb 5000360 54d0 87da b14d e3f5 20a1 55a7 dea8
815a ff2d 7cda 50008f0 7106 ff4f f34b 6db8 2e96 b725 a77b e4ea 5000900 3d5d 1877 61f3 f725 903c a28e 48c1 1fcb 5000910 3392 f9d7 b081 f8b0 e03f 82ee dd6a 9eff 5000920 457b 1c20 5f59 8c00 f24e b297 4876 5ba9 5000930 ff04 b638 75fe 882d 4edf df2b 64d3 90fd 5000940 6282 175d 51f4 e231 3f82 6cdb 7c1b
-
Thread
Orange RX mit Atmega8 auslesen
die Flanke wieder fällt, aber irgendwas stimmt da nicht. #define F_CPU 16000000UL #include <avr/io.h> #include <avr/interrupt.h> volatile int flanke=0; volatile int aktuell_pwm_l=0; volatile int aktuell_pwm_h=0; ISR(TIMER1_CAPT_vect) { if (flanke==0) { TCNT1H = 0;
[c] #include <avr/io.h> #include <avr/interrupt.h> #include <util/delay.h> #include "lcd_routines.h" #define F_CPU 3686400UL volatile int flanke=0; volatile int aktuell_pwm_l=0; volatile int aktuell_pwm_h
-
Thread
Atmega/C: eine Funktion aus einer Funktions heraus aufrufen
was da jetzt für den Speicher kritisch werden sollte... Hat jemand eine Idee? [c] /* * Main_64_v01.c * * Created: 11.09.2014 14:28:26 * Author: test1 */ //Bibliotheken #include <avr/io.h> #include <stdint.h> // PINOUT - Anzeigemodul #define SCK 3 //PE3: Speichertakt
einen M64 vor sich hat.
-
Thread
Daten auf Web Sever speicher.
gute Kopiervorlage. http://stefanfrings.de/avr_io/index.html
Eine einfache > TCP-Verbindung mit einem passenden Server auf dem Rechner reicht und > belastet dem AVR nicht so. Wenn man nicht krampfhaft am AVR festhält, dann ist das auch kein Problem. Ansonsten sind Eigenentwicklungen gefragt. Klar, kann man sich per Copy & Paste erste Socket-Implementierungen
-
Thread
Analoger Sensor (LM335) mit Operationsverstärker + AVR Asm-Code
Timerinterrupt. Es werden hier 4 analoge Werte von PortC0/1 (Referenz:VCC) und PortC2/3 (Referenz 1,1V) jeweils 64x eingelesen und daraus der Durchschnitt ermittelt. Bei z.B. 200Hz Aufruffrequenz gibts dann alle 1,28 Sekunden 4 neue gemittelte Werte.
Moby AVR schrieb im Beitrag #3792290: > 16 bittig gerechnet Moby AVR schrieb im Beitrag #3792288: > Was die Höhe der Referenzspannung betrifft hab ich das als Praktiker > jetzt nicht ins letzte ausgerechnet
-
Thread
Full speed USB mit mikrocontroller
Hallo. Wie waere es mit AVR XMega (-U Versionen)? Diesen kann mit LUFA bequem USB "begebracht" werden. Z.B. zum testen: http://matrixstorm.com/avr/avrstick/. Hierfuer gibt es online modifizierbare USB-Bsp: http://matrixstorm.com/avr/avrstick/#bideavr MfG
-
Thread
Retro Fieber: Z80 oder 68000 ?
der AVR einen Z80 emuliert und der DRAM sauber angeschlossen ist, kommt man auf knapp über 2 MHz, wenn ich mich recht entsinne. > Und für richtige Projekte ist der 64K Arbeitsspeicher zu klein. War er
kommt in den Monitor rein. EEPROMs gab es zu der Zeit noch nicht. Das erste, was es gab, was der 28C64, parallel und fast 6264/27C64-pinkompatibel. Oder eben batteriegepuffertes RAM. Und wenn seriell: SPI ist deutlich einfacher zu implementieren. fchk
-
Thread
[AVR] _delay_ms() funktioniert nicht mehr (vom Compiler ignoriert?)
(Auf Arch Linux und/oder anderen PCs ist das gleiche Problem) IDE: Codeblocks 13.12-3 Compiler: avr-gcc 1:4.8-2.1 libc: avr-libc 1:1.8.0-4.1 binutils: binutils-avr 2.23.1-2.1 avr: attiny2313 (ist aber egal welcher) Ich hab ein Programm mal auf das nötigste heruntergebrochen damit der Fehler
Bei mir kommt mit [code]avr-gcc (GCC) 4.8.2-2[/code] [code]avr-binutils 2.24-1[/code] [code]avr-libc 1.8.0-5[/code] [code]avr-gcc -Os -g3 -o main.elf -mmcu=attiny2313 main.c[/code] unter ArchLinux folgendes heraus: [
-
Thread
3x LED-PWM-Faden
liegen dass sich alles zu schnell ändert... [c] #include <stdint.h> #include <string.h> #include <avr/io.h> #include <avr/interrupt.h> #include <util/delay.h> uint16_t values[32] = { 0, 1, 2, 2, 2, 3, 3, 4, 5, 6, 7, 8, 10, 11, 13, 16, 19, 23, 27, 32, 38, 45, 54, 64, 76, 91, 108, 128, 152
10, 10, 11, 11, 12, 12, 13, 13, 14, 15, 15, 16, 17, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 31, 32, 33, 35, 36, 38, 40, 41, 43, 45, 47, 49, 52, 54, 56, 59, 61, 64, 67, 70, 73, 76, 79, 83, 87, 91, 95, 99, 103, 108, 112, 117, 123, 128, 134, 140, 146, 152, 159, 166, 173, 181, 189
-
Thread
Funktionsgenerator 7706 - Sweep reparieren
4.74 bzw 4.73kOhm. Bei dem heilen Board jedoch 4.95 und 7.43. Messfehler? Abweichung bei + Pin 28 Ladesignal zu U610 + Pin 30 Pin nicht im Plan zu finden + Pin 42 Rückführsignal Zeitbasis von U603B + Pin 45 D/P-Steuersignal Eingangspin + Pin 59 Clocksignal für U606 + Pin 61 + Pin 64
auch Pin 61 und 64 sind Bus-Pins.
-
Thread
Wlan2Serial Modul für 5 euro
will. https://github.com/cnlohr/wi07clight http://www.youtube.com/watch?v=oh4ZDkBHFYM Das AVR Projekt setzt dabei auf den UART. Eingehender WIFI Command ( TCP / UDP ) wird an den UART weitergegeben. Der AVR setzt die Message um und schaltet Pins auf dem AVR. An den Pins sind LED / Relais
Hi Holger Die bin Datei sollte exact 244 KB gross sein ( 64+180 ) 0x01000-0x10FFF (64KB) flash1.bin 0x11000-0x3DFFF (180KB) irom0text1.bin Wenn die flash1.bin kleiner ist als 64 kb, dann muss aufgefüllt werden, da ja ab 0x11000 der irom0text1.bin erwartet
-
Thread
Seriennummernproblem
> Kostet halt 1,50€ bei Reichelt kosten die bloss 29 Cent: 24AA02E64-I/SN und Du bekommst sogar 2-wire ;)
schrieb im Beitrag #3768903: >> Kostet halt 1,50€ > > bei Reichelt kosten die bloss 29 Cent: 24AA02E64-I/SN und Du bekommst > sogar 2-wire ;) D.h. nur 14,5 cent pro Wire!!
-
Thread
Adressierung über Bus
Frank K. schrieb im Beitrag #3766252: > Bei einem AVR wäre das noch ein extra Baustein mit extra Quarz, Selbst wenn man MCP2515 statt AT90CANxx einsetzt kann man dennoch ohne doppeltem Quarz arbeiten. Der vom AVR wird dann oft überflüssig.
nehmen, aber der ist im >> QFN-Gehäuse und damit schwerer zu verarbeiten. >> ... > > Den AT90CAN32/64/128 kennst Du anscheinend nicht? Doch, aber der ist für viele Anwendungen zu groß und zu teuer. Im Bereich 20 bis 28 Pins hat Atmel nichts anzubieten. Macht aber auch nichts, Microchip hat da eine
-
Thread
Zeitbasis nichtlinear, Jitter HM1005
122 10 21 133 11 22 145 12 23 156 11 24 167 11 25 178 11 26 190 12 27 200 10 28 211 11 29 222 11 30 233 11 31 244 11 32 255 11 33 267 12 34 278 11 35 289 11 36 299 10 37 310 11 38 321 11 39 333 12 40 344 11 41 355 11 42 366 11 43 377
520 11 57 531 11 58 542 11 59 553 11 60 564 11 61 575 11 62 586 11 63 596 10 64 608 12 65 619 11 66 630 11 67 641 11 68 652 11 69 663 11 70 674 11 71 684 10 72 695 11 73 706 11 74 717 11 75 728 11 76 739 11 77 750 11 78 761 11 79 772
-
Thread
8051 - Programm und Daten in einem 128kB Chip ohne Overlap
zu packen. Dafür gibt es ja schon diverse Projekte und Schaltpläne, die allerdings alle die 64kB gemeinsam nutzen (Overlap). Ich möchte jedoch separat 64kB Code und 64kB Daten. Die naheliegende Lösung wäre ja, das Adressbit A16 zu benutzen, um zwischen zwei "Speicherbänken" umzuschalten. Das
habe ich eine Experimentierschaltung auf Platine Sieht gut aus, aber nur zur Info, für grade mal 28 EUR gibt es ein aktuelles 8051 Board mit 64K Flash, 4K RAM, USB, J-Link Debugger drauf und Keil kostenlos ohne Codebegrenzung. Und EMIF da kann man 64K RAM extern anlöten falls gewünscht. http: