-
Thread
Probleme mit Diamex ALL-AVR ISP-Programmer
, ich habe mit einen Diamex ALL-AVR ISP-Programmer gekauft und habe nun Probleme damit meinen ATmega1281 zu programmieren. Der Diamex ALL-AVR ISP-Programmer wurde unter Windows als AVRISP mkII erkannt (im Gerätemanager Jungo > AVRISP mkII) und verursacht laut Windows keine Probleme. Die orangene LED
-
Thread
sbit macro für avr-gcc
ja praktisch konstant ist. Ja, die Vektoren werden immer alle eingebunden. Sind auf einem ATmega1281 auch schon mal (56 + 1) Stück zu je 4 Bytes, also 228 Bytes allein für die Vektortabelle. Würde in den fiktiven 128-Byte- Controller also schon gar nicht mehr passen...
-
Thread
Fehler bei AVR-GCC (make all)
-------------------------------------------------------- # MCU name MCU = attiny45 #MCU = atmega1281 # Processor frequency. # This will define a symbol, F_CPU, in all source code files equal to the # processor frequency. You can then use this symbol in your source code to #
External Memory Options ---------------- # 64 KB of external RAM, starting after internal RAM (ATmega128!), # used for variables (.data/.bss) and heap (malloc()). #EXTMEMOPTS = -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff # 64 KB of external RAM, starting after internal RAM (ATmega128!),
-
Thread
Problem mit GCC Plugin
meldungen, allerdings nicht als error: [...] Build started 23.7.2007 at 16:25:47 avr-gcc.exe -mmcu=atmega1281 RZ200.o callbacks.o coord.o debounce.o device.o dis[pfad gekürzt]\RCB\mac" -ll2_rdk230_rel -o RZ200.elf uart.o: In function `UART0_Init': ../uart.c:29: multiple definition of `UART0_Init'
-
Thread
RGB Moodlight mit STM8
noch Luft. Es erstaunt mich etwas, daß der STM8 damit kaum mehr Programmspeicher verbraucht als der ATmega8. Obwohl der STM8 vergleichsweise spartanisch ausgestattet ist. Und der SDCC ein viel minimalistischerer Compiler ist als der (avr-)gcc. Happy Hacking! [0] http://www.mikrocontroller.net/topic
hätte nichts dagegen, das genau so einzubauen. [1] [code] grep '#' irmp.c | wc -l -> 1281 grep '#' irsnd.c | wc -l -> 753 grep '#' irmpprotocols.h | wc -l -> 645 grep '#' ir*.[ch] | wc -l -> 3264 [/code]
-
Thread
Barcode-Pen mit RAW-Output
einzulesen. Dazu habe ich mir in der E-Bucht günstig einen Barcode-Reader in Stiftform besorgt: Intermec 1281A02 Leider hat sich nach ein wenig Herumprobieren und Logikanalyzer quälen heraus gestellt, das der überhaupt keinen Seriellen Ausgang hat, sondern mit einem Pullup gegen 5V an der OUTPUT-Leitung
FinalProject... Naja, ob der Softwerker Wyatt Schweizer immer wusste, was er tut? Mit einem 16MHz-Atmega32 schafft er keine zuverlässigen Scans und auch nur UPC-A, bei EAN13 gibt es Probleme. Da gibt es Verbesserungspotential: Ich würde PIN-Change-Interrupt verwenden und die Timer-Ticks messen oder
-
Thread
Projekt: Bordcomputer Gesperrt
sein. Schon mal etwas von einem ATMega328 gehört? So groß wie ein ATMega8 und soviel Speicher wie ein ATMega32. Was soll da eigentlich für ein Display dran? Ursprünglich war mal von einem Touchscreen die Rede. Mit der Trennung in Haupt- und LCD-Controller tust du dir keinen Gefallen. Mit einem ATMega1281/1280/2560/2561 bedient man ein Grafikdisplay+Touch locker nebenbei. MfG Spess
-
Thread
Globale Variable wird im ISR nicht hochgezählt??
(SRW10); // 2 wait states > [/c] Hi, hab ich probiert, selbes Fehlerbild. Es ist ein Atmega64 mit einem 32KB SRAM. Die Verschaltung ist die "übliche" mit dem Latch dazwischen um Beinchen zu sparen. Ich habe auch gerade mal den Pointer des Arrays nach 0x1100 verschoben, weil ich glaube,
guck dir die Hardware an. Zinnbrücken, Verdrahtungsfehler. Das Codeschnipsel oben war für einen ATmega1281. Beim ATmega64 befindet sich das Bit SRW10 im Register MCUCR (statt in XMCRA). Hast du aus Versehen was in XMCRB reingeschrieben? Dort kann man einen Teil der Adressleitungen von Port
-
Thread
Honeywell Rondostat HR20E per AVR steuern und konfigurieren
avr-gcc -mmcu=atmega169 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=4000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT rtc.o -MF dep/rtc.o.d -c ../source/rtc.c avr-gcc -mmcu=atmega169
implemented" zurück. Den Atmega versorge ich über die Stiftleiste am Thermostat. RX und TX habe ich direkt verbunden, ohne Widerstände, PullDowns usw. Der Atmega hat einen externen 4Mhz Oszillator. Im Anhang mal das Code-Schnipsel
-
Thread
BCM flackert beim dimmen
Original Code von der verlinkten Seite, mit Änderungen an den Timer Registern (ich benutze einen ATmega1284P @ 1 MHz), und einer Änderung in der "Animation" um nur eine LED langsam herunterzufaden. Weiß da jemand Rat?
. bit 1 = 767 Taktzyklen min. 769 Taktzyklen Max. bit 2 = 1279 Taktzyklen min. 1281 Taktzyklen Max. bit 3 = 2304 Taktzyklen bit 4 = 4351 Taktzyklen bit 5 = 8449 Taktzyklen bit 6 = 16639 Taktzyklen bit 7 = 33025 Taktzyklen Muss jetzt gehen, werde später etwas genauer
-
Thread
Umbenennung von Registerbezeichnungen
29K Code... Das ist mir klar. Aber ich meine reinen Programmcode Aus einem der Listfiles: ATmega1281 memory use summary [bytes]: Segment Begin End Code Data Used Size Use% --------------------------------------------------------------- [.cseg] 0x000000 0x00ed56 10042 50682
-
Thread
Avrdude und EESAVE Fuse
Hi, Folgendes Problem. Ich habe einen Atmega bei dem das EESAVE Fuse gesetzt ist. Nun möchte ich per Avrdude ein neues eeprom file flashen. Blöderweise führt das bei gesetztem EESAVE Fuse zu einem verification missmatch error. Klar bei
so das EESAVE nicht gesetzt ist und anschließend dann flash und eeprom flashe. -c stk500v2 -p m1281 -e -PCOM7 -U lfuse:w:0xFE:m -U hfuse:w:0xD9:m -U efuse:w:0xFC:m -e -U flash:w:test.hex:i -U eeprom:w:test.eep:a Das führt zu folgendem Resultat: [c] -c: Device signature = 0x1e9704 -c: erasing
-
Thread
AVR: Pointer in Register - wie definieren?
.-2 ; 0x144 <__stop_program> [/avrasm] (Compiliert mal als Beispiel für einen ATmega1281.) ramtest() benutzt intern ausschließlich Register für den Zugriff, auf den Speicher wird nur zugegriffen, um ihn zu testen. Durch .init3 läuft das Ganze, bevor die reguläre Initialisierung
-
Artikel
AVR Bootloader FastBoot von Peter Dannegger
wenn AVR nur größere Bootloader Regionen unterstützt) gestellt werden. Beispielsweise ist für den ATMega8 der Wert 10. Bei einigen Controllern wie z. B. dem ATMega 48 wird das Flag Selfprogramming enabled gesetzt. Auf dieser Website (Fusecalc) kann man sich die Fuses elegant zusammenstellen und erhält
hardware\arduino\avr\boards.txt" nachgucken, per Fusecalc die Bootloadergröße anpassen und in den Atmega schreiben. Dann muss der Bootloader selbst in den Atmega geflashed werden. Nun wird das eigentliche Programm der Arduino-IDE durch einen Klick auf Verify kompiliert. Arduino erzeugt nun eine Projektname.cpp.hex
-
Thread
AVR Uart empfangene Daten weiterleiten
Sendepuffer verlassen haben (blockieren in einer ISR ist sowieso schlecht). Wenn ich es dem Datenblatt des Atmega1281 richtig entnommen habe besitzt die USART einen 1-Byte Eingangspuffer. Somit sollte gut eine Zeichenlänge an Zeit vorhanden sein um den Interrupt abzuarbeiten und das wird vermutlich zu knapp wenn
-
Thread
Komm net drauf :-(
$ cat foo.c #include <avr/io.h> int main(void) { return TRUE; } $ avr-gcc -mmcu=atmega1281 -c foo.c foo.c: In function 'main': foo.c:6: error: 'TRUE' undeclared (first use in this function) foo.c:6: error: (Each undeclared identifier is reported only once foo.c:6: error: for each
-
Thread
12bit, 9-Kanal Soft-PWM für LEDs auf Mega16
c2g, c2b; unsigned int c3r, c3g, c3b; unsigned int pwmCounter; unsigned char rxCounter; // Atmega IO konfigurieren DDRA = 0xFF; DDRB = 0xFF; //USART UCSRA=0x00; UCSRB=0x10; UCSRC=0x86; UBRRH=0x00; UBRRL=0x2F; //PWM while (1) { //Bei 0 alle einknipsen if (++pwmCounter==4095
Anforderung zwar erfüllen, aber weder die Platine, noch das Löten dieses Monsters trau ich mir zu. Der 1281 hat wieder nur 6 OCXn. Auch die dsPICs haben "nur" 3 DutyCycle Generatoren und könnten nur eine LED-Leiste antreiben, ich hätte aber gerne ein einziges IC :) Naja, vielleicht habt ihr noch Ideen
-
Artikel
BAE-Tutorial
rowspan=2 | ATmega8515, ATmega162 plcc PLCC44/PLCC44s fp TQFP44 rowspan=3 | at90s4434 AT90(L)S4434, AT90(L)S8535 (leer) DIL40 rowspan=2 | ATmega16, ATmega164/324/644 plcc PLCC44/PLCC44s fp TQFP44 at90usbx2 AT90USB162, AT90USB82 (leer) VQFP32 rowspan=2 | atmega103 ATmega103(L), ATmega128(L) rowspan=2 | (leer) rowspan=2 | TQFP64 ATmega1281, ATmega2561 rowspan=2 | atmega1280 ATmega640, ATmega1280, rowspan=2 | (leer) rowspan=2 | TQFP100 ATmega2560 rowspan=2
-
Thread
I2C Repeated Start klappt nicht
könnt mir helfen und sagen ob das mit meinem I2C Code überhaupt möglich ist. Ich verwende einen ATmega1281 und möchte einen VTI SCP1000 Sensor über I2C ansprechen. So versuche ich die I2C Funktionen zu nutzen: ... i2c_start(VTI,WRITE); i2c_send(0x02); // schreibe in ADDPTR i2c_send(0x29
-
Thread
Akkueinzelzellentester HET 20 von ELV
rausgekramt um meine LiFePO4, 1600mAh frisch vom Hersteller mit 1A Entladen. Ach, im HET20 werkelt ein ATmega 8. Leider werden keine LFP unterstützt, d.h. die Enladespannung liegt bei 2,7V anstatt bei 2,5V. EBC-A20 Multifunktion Li-Po Batteriekapazitätstester 5A Ladung 20A Entladung 85W https://www.ebay.de
mal meine frisch vom Hersteller bekommene 1600mAh LiFePO4-Zelle mit 1 Ampere entladen, welche noch 1281mAh an Ladung inne hatte. Der Wechselstromwiderstand mit dem *YR1030* gemessen, betrug 16,7 mOhm. Wenn meine Ladeplatinen mit dem *TP5000* angekommen sind, werde ich die Zelle mal aufladen und wieder
-
Thread
gcc bug (diesmal wirklich): "shift count is negative" Gesperrt
das erhöht die Chance, dass es jemanden bei GCC interessiert. ;-) [pre] $ avr-gcc -Os -mmcu=atmega1281 -Wall -Wextra -S foo.c foo.c: In function ‘foo’: foo.c:6:18: warning: left shift count is negative [-Wshift-count-negative] 6 | return x << shift; | ~~^~~~~
ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10809 -DARDUINO_AVR_MEGA2560 -DARDUINO_ARCH_AVR -fno-sized-deallocation -fconcepts "-IC:\\Program Files (x86)\\Arduino\\hardware\\arduino\\avr\\cores\\arduino" "-IC:
-
Thread
for(; ;) - Schleife
nicht mit "inline static void spi_out2". Wahrscheinlich deshalb: [pre] % avr-gcc -Os -mmcu=atmega1281 -S loop.c loop.c: In function 'spi_out': loop.c:8: sorry, unimplemented: inlining failed in call to 'spi_out2': recursive inlining loop.c:19: sorry, unimplemented: called from here [/pre]
-
Thread
Hobby Schaltplansoftware
THT-Pins und 301 SMD-Pads. Zum Aufpeppen würde ich dann 89C52 und 8255 durch ein Aufsteckboard mit ATmega1281 ersetzen. Das liegt mit reichlich 300 Pins/Pads schon wieder halbwegs im Rahmen dessen, was die kostenlose Diptrace-Version macht. Eins meiner größeren Projekte vor vielen Jahren war der Bau
billigste Kaufvariante mit 400 Pins. Damit ging schon deutlich mehr. Irgendwann fing ich mit dem ATmega2560 an. Dieser alleine hat schon 100 Pins. Von den meisten dieser Pins geht üblicherweise eine Leitung aus, deren anderes Ende mit einem weiteren Pin zu Buche schlägt. Das sind dann insgesamt schon
-
Artikel
AVR Typen
ATmega64 64 64 16 16 53 8 1 1 2 0 0 0 8 10 15 1 0 0 4 2048 40 85 2.7 5.5 2.7 5.5 4 8 2 7 ATmega64 ATmega128 128 64 16 16 53 8 1 1 2 0 0 0 8 10 15 1 0 0 4 4096 40 85 2.7 5.5 2.7 5.5 4 8 2 7 ATmega128 ATmega162
4 15 ATmega640 ATmega1281 128 64 16 16 54 17 3 1 2 0 0 0 8 10 15 1 0 0 8 4096 40 85 1.8 5.5 1.8 5.5 6 16 2 8 ATmega1281 ATmega2561 256 64 16 54 17 3 1 2 0 0 0 8 10 15 1 0 0 8 4096 40 85 1.8 5.5 1.8 5.5 6 16 2