-
Thread
Eclipse, GDB, avarice, JTAGICE_mkII - Debuggen funktioniert nicht
meine Fehler doch spezifischer zu sein scheinen. Zur Vorgeschichte: Ich programmiere einen ATmega128 mit WinAVR-20100110 unter avr-g++ (C++). Als IDE kommt Eclipse zum Einsatz. Bisher hab ich das generierte elf-File mit AVR-Studio 4 geladen und versucht zu debuggen. Das hat zwar funktioniert, AVR-Studio
anzufangen: C:\WinAVR-20100110\bin>avarice -2 -I -d --jtag usb --jtag-bitrate 22 :4242 AVaRICE version 2.9, Jan 7 2010 22:42:57 Found JTAG ICE, serno: 00A0000016EF JTAG config starting. Attempting synchronisation
-
Thread
BMP085 driftet
Bereich als Höehen und eingeschränkt als Vario Sensor im Einsatz. Während der Erprobung habe ich eine WinAVR Lib für den BMP085 entwickelt, die zyklisch im 10ms Raster aufgerufen werden muss und per Funktionsaufruf die aktuellen Werte liefert. Gruß Ingo
dem MS5611 Sensor gemacht, allerdings benötigen die Umrechnungen 64bit Integer Berechnungen, was der AVR und der WinAVR aber noch meistert. Gruß Ingo
-
Thread
AM oder FM Fernbedinung Rohrmotor -> bild
mit Funksteuerung 433,92Mhz. Damit habe ich das ganze Haus bestückt. Ich kann jetzt die Rollos per AVR steuern ( Beschattung, Morgens , Abend, Urlaub usw. ). Den Sendecode habe ich mit dem AVR nachgebaut ( ATmega8) + 433,92mhz AM Sendemodul. [c] #include <avr/io.h> #include <stdio.h> #include
0xFF ADDLW 0xFF ADDLW 0xFF ADDLW 0xFF LADR_0x0370 MOVLW 0x00 SUBWF LRAM_0x28,W BTFSC STATUS,Z GOTO LADR_0x0380 MOVLW 0x01 SUBWF LRAM_0x28,W BTFSC STATUS,Z GOTO LADR_0x0381 MOVLW 0x02 SUBWF LRAM_0x28,W BTFSC STATUS,Z GOTO LADR_
-
Thread
Attiny lässt sich nicht flashen
5.8cvs *mySmartUSB* firmware 2.5 *CP210x* silabs.com for OSX (v2.9) [c] vinz$ avrdude -pm8 -c avr910 -P /dev/tty.SLAB_USBtoUART -v -e -b 19200 -U flash:w:LCD.hex:i ... avrdude: avr910_devcode selected: 0x76 avrdude: AVR device initialized and ready to accept instructions Reading | ###
: /dev/tty.SLAB_USBtoUART Using Programmer : avr910 avr910_devcode (avrdude.conf) : 0x76 Overriding Baud Rate : 19200 AVR Part : ATMEGA8 Chip Erase delay : 10000 us
-
Thread
SPI an SCK keine Frequenz
verwendet, dann sollte auch eine Buffergrösse von 256 Reichen, für nur arp und udp evt sogar 128 -Ip & Mac wird in stack.c festgelegt! -der zu verwendende Pin für /CS wird am Anfang von enc28h60.h festgelegt #################################### */ #include <avr/io.h> #include "stack.h
************* #include "global.h" //#include "timer.h" //#include "rprintf.h" #include "enc28j60.h" #include <avr/io.h> u08 Enc28j60Bank; u16 NextPacketPtr; #define ENC28J60_CONTROL_PORT PORTD #define ENC28J60_CONTROL_DDR DDRD #define ENC28J60_CONTROL_CS 4 #define F_CPU
-
Thread
Datentypen in C
Zwar nicht im Forum, aber nur drei Klicks entfernt: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Ganzzahlige_.28Integer.29_Datentypen
erweitern, muß man halt irgendwie ein bit opfern (daß das Vorzeichen enthält) und kommt dann auf ca. -128 .. +127 anstatt (+)0 .. (+)255 ps: sowas kann man auch in der Wiki nachlesen http://de.wikipedia.org/wiki/Integer_%28Datentyp%29#Maximaler_Wertebereich_von_Integer
-
Thread
avr-gcc 4.7 I/O-Zugriffe
*addhi3/1 [length = 2] adc r25,r29 pop r29 ; 25 popqi [length = 1] pop r28 ; 26 popqi [length = 1] jmp bar ; 11 *call_value_insn/4 [length = 2] [/avrasm] > Da gab es doch mal einen Hardwarefehler in den AVR, oder? Welcher denn? Ist mir nix bekannt in
>> Bugreport zu machen. Die Chance, daß er Beachtung findet, ist allerdings >> sehr klein, denn AVR ist eine "unwichtige" Plattform. >> >> AVR ist "unwichtig", weil es nicht genug Entwickler gibt, die sich um >> den AVR-Teil kümmern. Zudem hat der AVR-Teil andere Einschränkungen; so >> ist er
-
Thread
Kommunikation zwischen mehreren µC
CAN optimal. Leider ist die Auswahl an CAN-MCs bei Atmel nicht sehr üppig. Ich benutze AT90CAN128 und AT89C51CC03. Peter
Byte von A nach B bringt. Ist ja keine Raketentechnik. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART
-
Thread
Wie kann ich Libraries in AVR Studio 5 einbinden?
Du solltest in Teilschritten vorgehen. 1) Installation des AVR Studio 5 incl. der AVR Toolchain. Diese Installation sollte von Atmel perfekt beschrieben sein. Bei Fragen können dir "Tausende" AVR User weltweit helfen. Damit kannst du bereits AVR C Projekte
Error 27 expected 'char *' but argument is of type 'unsigned char *' c:\program files (x86)\atmel\avr studio 5.0\avr toolchain\bin\../lib/gcc/avr/4.5.1/../../../../avr/include/string.h 122 14 test1 Warning 28 pointer targets in passing argument 2 of 'strcat' differ in signedness c:\users\it-lab08
-
Thread
Sehr seltsames Verhalten von Arrays
dir Sorgen, ob das Lesen aus dem Flash schnell genug ist? http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29
beweist, dass es Nerds gelingt selbst den unwahrscheinlichsten Fehler zu machen. Jedoch: ATM32 AVR-Studio 4.18 WinAVR-20090313 Optimierung: -O0 [c]int main (void) { uint8_t dta[10000]; dta[0] = 64; dta[9999] = 128; }[/c] compiliert problemlos, Speicherverbrauch: [c] AVR Memory Usage
-
Thread
C++ oder C auf uc
übersetzbar. Objective-C wird zB von GCC unterstützt und einige populäre Distributionen wie WinAVR-20100110 bringen auch einen Objective-C Compiler für AVR mit. Einem barrierefreien Einstieg in die OO-Welt steht also nichts im Wege.
nicht dafür verschwendet. Soweit ich mit erinnere wird dieses Modell bei den AVRs mit mehr als 64KW/128KB Flash verwendet, die ja ein recht ähnliches Problem haben.
-
Thread
_delay_ms(1) ungenau!
Hi! Ich bin gerade am beginn meiner AVR Kariere. Ich wollte kurz testen ob das Programmieren funktioniert und wollte mal ne Soft Pwm machen. Erster Test: Einen Pin ein und ausschalten! Controller ist ein Atmega 48, an den fuses hab ich
sind nichtkonstante Argumente, die mag die Funktion nicht. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 >aber das find ich dann schon recht extrem! weil in 1ms vergehen ja >immernoch 1000 Takte! Ja und? MFG Falk
-
Thread
Entwicklungen und Forschung um den Sparmatic Comet / Zero v2 Heizungsthermostat
Wie du meinst, nur nicht weinen wenn's mit dem AVR vorbei ist... :)
Temoc schrieb im Beitrag #2848799: > Dann würden sie wohl kaum den AVR rauswerfen.. Wie jetzt?
-
Thread
GNUBLIN www.gnublin.org
darin enthaltenen i2cset und i2cget oder in C http://www.mikrocontroller.net/articles/Ports_benutzen_%28GCC%29#Der_I2C_Bus_.26_SMBus Hier ein kleines Beispiel von mir http://krumeltee.wordpress.com/2011/08/15/pcf8574-am-avr32-unter-linux/ für den PCF8574, gibt dort noch mehr. Die Linux-I2C-Geschichten
0074 i2c-0 i2c-1 root@gnublin:~# ls -l /sys/bus/i2c/devices total 0 lrwxrwxrwx 1 root root 0 Sep 28 02:32 0-0060 -> ../../../devices/platform/pnx-i2c.0/i2c-0/0-0060 lrwxrwxrwx 1 root root 0 Sep 28 02:32 1-0074 -> ../../../devices/platform/pnx-i2c.1/i2c-1/1-0074 lrwxrwxrwx 1 root root 0 Sep 28 02:
-
Thread
Bootloader ATmega 2561
es wirklich ein Zeiger ist. [c]boot_program_page( adr,data );[/c] Hast du den Flash mal mit dem AVR-Studio ausgelesen? Was steht denn in den ersten paar Adressen drinn (lauter Nullen, lauter 0xFF)? Um sicher zu gehen, könntest du ja auch (zum Test erstmal) einen festen Wert für die Daten nehmen
eor r1, r1 1f0ce: 1f be out 0x3f, r1 ; 63 1f0d0: cf ef ldi r28, 0xFF ; 255 1f0d2: d1 e2 ldi r29, 0x21 ; 33 1f0d4: de bf out 0x3e, r29 ; 62 1f0d6: cd bf out 0x3d, r28 ; 61 1f0d8: 00 e0 ldi r16, 0x00 ; 0
-
Thread
AX81 - ZX81 im AVR
Hi. Evtl. eine Alternative wäre auf den FAT16 Routinen vom AVR CPM aufzusetzen in der Weise, das nur eine 128MB Image Datei (Aufbau wie von dir beschrieben und mit den Perl Tools erzeugt) mit festem Namen auf der SD Karte lokalisiert wird. Name z.B AX81APPS.IMG
Wieder LOAD geht auch. Nach Reset auch wieder CARD und gespeicherte Programme sind da.. Mag er die 128MB SD Karte nicht, die aber z.B bei mmc2iec/sd2iec und AVR CPM einwandfrei gehen..? Auch Win$ kann mit der Karte.. Peter
-
Thread
gcc und Optimierung
, bit_nr); avr.c: avr_output_bld (operands, bit_nr); avr.c: AS2 (bld,%3,%2-1))); avr.c: AS2 (bld,r1,5) CR_TAB avr.c: return (AS2 (bst,%0,6) CR_TAB avr.c
the source and avr.c: sprintf (buf, "bst r%d, 7", rsource + tlen[1] - 1); avr.c: hadbst = 1; avr.c: if (hadbst) avr.c: sprintf (buf, "bld r%d, 7", rdest + tlen[0] - 1); avr.c:avr_output_bld
-
Thread
DDS erster Versuch
funktioniert prima. Übrigens ist hier noch Einer von Etlichen, der es so gemacht hat: http://www.avr-asm-tutorial.net/avr_de/avr_dac.html MfG Paul
Ohne Signal habe ich am oberen 1.28V und am unteren 0V. Die Widerstände sind beide 4.7k.
-
Thread
Automatische Stalltür, Sensorabfrage, Atmega8 GCC
Beautifier sind längst erfunden. ADC beim Atmega8 in C http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#ADC_.28Analog_Digital_Converter.29 [C] #define F_CPU 1000000UL #include <avr/io.h> #include <util/delay.h> // Schaltung soll bei 1,2V+-10% an ADC1 schalten // AVref = Vcc =
| | ' GND GND (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de) Gruß, Max
-
Thread
ENC28J60 liesst falsch Datenpaket aus
Takt? Schon mal andere "groessere" Programme fehlerfrei mit der Platine laufen lassen? >> enc28j60.c > wait(unsigned int time) {for (int i = 0; i < time; i++) { } Du verwendest gcc? Was meinst Du passiert damit? Du verwendest eine Library, die fuer einen AVR gemacht wurde und nun fuer eine
Du passiert damit? die Frage versteh ich nicht.... > Du verwendest eine Library, die fuer einen AVR gemacht wurde und > nun fuer eine ARM-Architektur eingesetzt wird? Damit müsste doch eine ARM auch zurechtkommen? >>>enc28j60PhyWrite >>//_nop_(); > So ein NOP koennte schon Sinn machen? >
-
Thread
ATmega8 lässt sich nicht mehr flashen
paar Pins vertauscht. Seitdem krieg ich in Eclipse immer diese Fehlermeldung: Launching C:\WinAVR-20100110\bin\avrdude -pm8 -cavr910 -PCOM3 -Uflash:w:TimerTest.hex:a Output: Found programmer: Id = "AVR ISP"; type = S Software Version = 2.5; Hardware Version = 2.0 Programmer supports auto
unknown) Device code: 0x26 = (unknown) Device code: 0x27 = (unknown) Device code: 0x28 = AT90S4414 Device code: 0x29 = (unknown) Device code: 0x2a = (unknown) Device code: 0x2b = (unknown) Device code: 0x2c = (unknown) Device code: 0x2d = (unknown) Device
-
Thread
kurze Frage zur AVR fast pwm sinus-ausgabe?!
Hallo, ich wollte in späteren Projekten die PWM des AVR (ATmega8) als DAC nutzen können. Aus diesem Grund habe ich mich mal mit der fast pwm auseinandergesetzt. Das Tastverhältnis kann ich auch über den OCR1A Wert ändern. Die PWM Frequenz liegt bei
Ich hab das jetzt ein wenig modifiziert und zwar mal 128 für positive Sinuswert und für negative Sinuswerte 128- positive Sinuswerte. sieht schon etwas mehr nach einem Sinus aus!!
-
Thread
SPI - RS-485 - CAN
Sensornummer und Sensorwert. Empfehlenswert für die Sensornodes wäre der erwähnte MCP2515 an einem kleinen AVR, weil schön einfach und recht arm an Bugs. Oder beispielsweise der PIC18F2585, wenn PICs genehm sind, denn das ist ein 28-Pinner mit einem CAN Controller an Bord, der mit dem MCP2515 eng verwandt ist
Hallo, den Avr ATMega16 gibt es auch mit CAN Bus, ansonsten wäre eine alternative der AT90CAN32.
-
Thread
WordClock mit DCF77, Photodiode und ATMega8
Kann funktionieren, muss aber nicht. http://www.mikrocontroller.net/articles/DCF77-Funkwecker_mit_AVR#DCF77-Modul_von_Reichelt MfG Falk
@Oli Ich würde es zwar vllt nicht so machen das der AVR die 20mA pro LED Treiben muß, da der AVR doch sehr viel Strom ziehen würde bzw müsste. Und die 40mA sind ja Absolute Maximum Rating. Vllt lieber noch nen Treiber für die Zeilen nehmen. Aber das ist
-
Thread
GCC makefile Problem
wurden nicht autoamtisch generiert habe mal das makefile mit anderen automatisch generierten für WinAVR verglichen und spaßeshalber mal folgende zeile geändert.. [code] #USER_OBJS: $(OBJS) $(USER_OBJS) ARMEMF32.elf: $(OBJS) $(USER_OBJS) [/CODE] jetzt passiert zumindest was und der gcc wird angeschmissen
./touchdemo.c:127: error: âGPIO_EVEN_IRQnâ undeclared (first use in this function) ../touchdemo.c:128: warning: implicit declaration of function âNVIC_EnableIRQâ ../touchdemo.c:131: error: â_GPIO_P_MODEH_MODE9_MASKâ undeclared (first use in this function) ../touchdemo.c:132: error: âGPIO_P_MODEH_MODE9
-
Thread
Gemeinsamer Hausbus
Ganz ehrlich..vergiss RS485 mit einem eigenen Protokoll...der Aufwand lohnt einfach nicht. Nimm einen AVR mit integriertem CAN controller (at90can128) und dann DeviceNet oder so als Application Layer. Das ganze ist fertig, hochstabil und man kann sich ganz um die Nodes sowie die Anwendungen kümmern.
/apps/trac/openhc/browser http://sourceforge.net/apps/trac/openhc/wiki/Unterputz-Eingangsmodul%20%28UEM%29 usw. ist halt "phc kompatibel" aber das lässt sich ja leicht ändern 10€ pro modul geht sich allerding nicht aus..
-
Thread
DOGXL Fontgenerator (SW+Graustufen)
kurz damit gespielt. Solche Beiträge sind ein sehr wohltuender Ausgleich zu manchen Anderen. avr PS: Du solltest das Programm evtl. bei den Tutorials verlinken.
Hi Dann mache ich etwas falsch. Bei mir laufen alle Dogdisplays (M132,L/M128,S102 und XL160) im SPI-Mode 0. Und das funktioniert z.B. auch mit TLC5925 und ENC28J60 , die nur Mode 0 können, am gleichen Bus. MfG Spess
-
Thread
Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)
86<\r><\n> Channel 3: ADC average value = 0 Diff = -128<\r><\n> Channel 4: ADC average value = 0 Diff = -128<\r><\n> Calibration run 3<\n><\r> Channel 1: ADC average value = 126 Diff = -2<\r><\n> Channel 2: ADC average value = 51 Diff = -
-28<\r><\n> Channel 3: ADC average value = 0 Diff = -128<\r><\n> Channel 4: ADC average value = 0 Diff = -128<\r><\n> Calibration run 6<\n><\r> Channel 1: ADC average value = 126 Diff = -
-
Thread
100kb Variablen auf ATMEGA2560
Bzw für C siehe http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29. Alternativ könntest du die Daten ja auch z.B. auf eine SD Karte o.Ä. schreiben und diese dann per SPI auslesen. Dann tuts auch ein kleinerer µC, sofern du
Der avr-gcc kann m.W. nur Felder bis 64k anlegen.
-
Thread
Ein kleiner Oberoncompiler für die C16x-Familie
die könntest Du dir mal ansehen. Und dann gab es hier ja mal jemanden, der einen Pascal-Compiler für AVR machen wollte: http://www.mikrocontroller.net/topic/140480#new Ich persönlich kann auf einem uC mit C leben -- aber eigentlich auch nur da.
Krankheit von Microsoft was auf einem uC wahrscheinlich nicht implementierbar ist (jedenfalls keinem AVR/PIC/8/16-Bitter und keine kleinen 32 Bitter). Java geht auch nur rudimentär auf nem AVR. Wobei die Interpretersprachen (also ALLE Sprachen die Bytecode erzeugen der auf einer virtuellen CPU läuft) allesamt