-
Thread
Brötje ISR Plus Kommunikation / LPB
ab 00 28 f3 24 U 78 0e 00 08 c0 02 00 14 86 05 21 04 aa f5 ca U 78 10 08 00 0c 02 00 14 87 21 05 04 aa 00 64 f3 7f U 78 0e 00 08 c0 02 00 14 a6 05 05 07 be f5 e5 U 78 10 08 00 0c 02 00 14 a7 05 05 07
min -3°C: 0xFF54 = -172, this is int16_t middle 0°C: 0x0004 = 4 max +3°C: 0x00BC = 188 6) 0xFD28FFFFFFFFXXXXCC: room temperature * 64 20°C = 0x0500 QAA50 Special messages: 0xFB4CFFFFFFFFFFXXCC: comfort mode set 0x00 = economy 0x01 = comfort 0xFE4CFFFFFFFFFFXXCC: comfort mode validate
-
Thread
[AVR] ATmega16 startet neu bei EEPROM-Zugriff auf 0x1F0?
14e6: 99 27 eor r25, r25 14e8: 82 70 andi r24, 0x02 ; 2 14ea: 90 70 andi r25, 0x00 ; 0 14ec: 00 97 sbiw r24, 0x00 ; 0 14ee: 09 f0 breq .+2 ; 0x14f2 <ee_readByte+0x28> 14f0: f8 cf rjmp .-16 ;
[pre] unsigned char ee_readByte(unsigned short address) { 5e: e1 99 sbic 0x1c, 1 ; 28 60: fe cf rjmp .-4 ; 0x5e <ee_readByte> while (!EEPROM_READY) { } EEPROM_ADDRESS(address); 62: 9f bb out 0x1f, r25 ; 31 64: 8e bb out 0x1e, r24 ;
-
Thread
Zwei ATMega8 und ein Grafikdisplay über SPI
Grafikdaten byteweise gesendet. Wie, das steht dann im Datenblatt. Manche Displays wie diese großen EA Displays haben darüberhinaus noch Befehle für Texte, Linien, Rechtecke,... fchk
, WR vorhanden sind. Jumpere das Teil auf 8 Bit 8080-Bus, nimm einen AVR mit externem Adress/Datenbus (z.B. Mega 64/128/640/641/1280/1281/2560/2561) und hänge das Display an selbigen. Wenn Du das Teil über normale IO-Pins ansteuerst, wird es etwas langsam. fchk
-
Thread
AVR Ethernet Platine
gelesen das das mit den Xilinx CPLDs zu Problemen führen kann. (war aber widersprüchlich). Falls VQFP64 kein Problem wäre dann müsste man nur noch in Erfahrung bringen wo's den XC9572XL in VQFP64 zu kaufen gibt. Das Memory Banking ist im Grund einfach. In WinAVR zb. definiert man sich einfach eigene
. Auch ich würde mit 64Kb SRAM bei weitem auskommen und sehe eigentlich nicht die Notwendigkeit für einen WEB Server auf'm AVR das er mehr bräuchte. Wichtig wäre dann das die SD/MMC Library + zugehöriger FAT Library möglichst
-
Thread
MMC/SD-Karte mit FAT16 an AVR
der Karte. Der entscheidende Teil der sd_raw_config.h sieht bei mir so aus: [c] #elif defined(__AVR_ATmega64__) || \ defined(__AVR_ATmega128__) /* Attention: all pins must be defined for correct work */ #define configure_pin_mosi() DDRB |= (1 << PB2) #define configure_pin_sck()
@Guido: Wieder mal zu schnell abgesendet. Der Code geht ja noch weiter: [c] #elif defined(__AVR_ATmega64__) || \ defined(__AVR_ATmega128__) /* Attention: all pins must be defined for correct work */ #define configure_pin_mosi() DDRB |= (1 << PB2) #define configure_pin_sck()
-
Thread
AVR MKII und avrdude keine USB Verbindung
001 Device 007: ID 0461:4d20 Primax Electronics, Ltd HP Optical Mouse Bus 001 Device 010: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light Bus 001 Device 005: ID 04f2:0116 Chicony Electronics Co., Ltd KU-2971/KU-0325 Keyboard Bus 001 Device 003: ID 0424:ec00
number 10 using dwc_otg [ 3221.903285] usb 1-1.4: New USB device found, idVendor=10c4, idProduct=ea60 [ 3221.903314] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3221.903332] usb 1-1.4: Product: myAVR - mySmartUSB MK2 [ 3221.903348] usb 1-1.4: Manufacturer: Silicon Labs
-
Thread
myAVR Board light welcher Programmer ist verbaut? für Linux
10:37:12 debian-capi kernel: [ 52.810837] usb 2-3: New USB device found, idVendor=10c4, idProduct=ea60 Nov 20 10:37:12 debian-capi kernel: [ 52.810844] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 20 10:37:12 debian-capi kernel: [ 52.810847] usb 2-3: Product: myAVR - mySmartUSB
mit Sisy auch funktioniert hat. Kann ich das irgendwie testen? [code]Bus 004 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light[/code] Gerade entdeckt: Das zeigt mir meine USB Verbindung an: http://shop.myavr.de/index.php?sp=article.sp.php&artID
-
Thread
Faktensammlung Buderus EMS
00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 crc_ist0x83 crc_soll0x85 Daten: 08 00 18 00 27 02 a3 64 00 01 01 20 00 02 52 7d 00 80 00 00 00 ff 30 59 00 00 ff 00 00 83 00 - CRC-Fehler data published UBAMonitorFast ( 08 00 18 00) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 crc_ist0x83 crc_soll0x85 Daten: 08 00 18 00 27 02 a3 64 00 01 01 20 00 02 52 7d 00 80 00 00 00 ff 30 59 00 00 ff 00 00 83 00 - CRC-Fehler data published
-
Thread
AVR-GCC 4.7.2 Bug?
Start *** buffer overflow detected ***: /tmp/hsv terminated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7ffff7b25817] /lib/x86_64-linux-gnu/libc.so.6(+0x109710)[0x7ffff7b24710] /lib/x86_64-linux-gnu/libc.so.6(+0x108b79)[0x7ffff7b23b79] /lib/x86_64-linux-gnu
@Johann Leider funktioniert bei mir unter Win7 64bit der Simulator nicht. Da kackt mir immer das AVR-Studio ab. Deswegen mache ich das ganze ja per UART, damit ich überhaupt mal was debuggen kann. Leider kann ich das ganze nicht weiter Eingrenzen wie
-
Thread
4x Nibbles auf 16 Bit Wert packen
D. schrieb im Beitrag #4615525: > Klar geht das mit schieben- dauert aber zu lange, Auf einem AVR 'inline' 24 Takte.
01 movw r24, r18 1e6: 86 2b or r24, r22 1e8: 97 2b or r25, r23 1ea: 08 95 ret [/avrasm] Das sind 16/17 Befehle (je nachdem ob man ret dazuzählt). Afaik ist jeder der enthaltenen Befehle single-cycle (OK, mul nicht), also braucht ein AVR bei 16Mhz Takt
-
Thread
Was macht bitte der GCC da?? Compilerbug?
ganz tem[1] = temp->_int % 100; //komma temp->ganz = tem[0]; temp->komma = tem[1]; 24c: 64 e6 ldi r22, 0x64 ; 100 24e: 70 e0 ldi r23, 0x00 ; 0 250: 25 d0 rcall .+74 ; 0x29c <__udivmodhi4> 252: 80 83 st Z, r24 254: 08 95 ret
Rechnung. Ich hab das auf Integer erweitert und dann die Division. Kann ich da noch was für den Avr optimieren?
-
Thread
STM32 USB Übertragungsproblem mit Code von S.F.
Bo:1:025:2 -115 1 = 72 "r" ffff9ea340ba0180 3590090000 S Bo:1:025:2 -115 1 = 6c "l" ffff9ea340ba03c0 3590090002 S Bo:1:025:2 -115 1 = 64 "d" ffff9ea340ba0300 3590090003 S Bo:1:025:2 -115 1 = 21 "!" ffff9ea340ba0900 3590090006 S
schon irgend jemand von euch reproduzieren? Ich hab die Version von temp vom 28.3. ( mit Zeile 1351 in der usb.c) jetzt mal auf einem Problemkandidaten laufen lassen: Der µC wartet ja, bis 64 chars beisammen sind, und schickt die wieder hoch. Das funktioniert auch, wenn die
-
Thread
Sinusberechnung auf Controller STM32F030
fürs > Programm. Im AVR wäre das so nicht ein Problem, weil ein 8 Bit breit, bei einem ARM dieses jedoch 32 Bit breit. Es wäre mal einen Vergleich wert, wie groß der Code auf einem AVR und wie groß der Code auf einem ARM
Die Tage habe ich auch auf einem STM32F030 für ein eichfähiges System eine interne Berechnung in int64_t statt in double durchgeführt. Plötzlich reichen auch 16k statt 32k Flash. Und int64_t war schon der Ansatz für Faule. ;)
-
Thread
Daten mit Wiz550io als TCP Client versenden
0x54} -Source Port übertragen // {0x00, 0x04, 0x2C, 0xEA, 0x60} -Socket 1 Command "OPEN" absetzen // {0x00, 0x01, 0x2C, 0x01} -100ms warten (unterschiedliche Wartezeiten ausprobiert) -Socket 1 Status lesen -> "1" (sollte es gar nicht geben) // {0x00, 0x03, 0x28, 0x00} -Socket 1 Command "CONNECT" absetzen // {0x00, 0x01, 0x2C, 0x04} -20 Byte in den TX Buffer des Socket 1 schreiben -Socket 1 Command "SEND" absetzen // {0x00, 0x01, 0x2C, 0x20} Auf PC
-
Thread
STM32 Datenrichtung (GPIOx_CRL/CRH)
Hallo zusammen, ich steige (seit Monaten) vom AVR auf STM32 um. Was ich beim AVR toll finde ist, wie einfach man beim GPIO-Pins zwischen Ein- und Ausgang umschalten kann (Datenrichtungsregister DDR). Beim STM32F10x ist es ja etwas komplizierter, da
, [r3, #4] 8002258: 4808 ldr r0, [pc, #32] ; (800227c <L_LOOPUS_127+0x60>) 800225a: ea41 0200 orr.w r2, r1, r0 800225e: 605a str r2, [r3, #4] GPIOx->CRL &= mask>>4*(8-DATA_OFFSET) | \ 8002260: 6819 ldr r1, [r3, #0] 8002262: 4807 ldr r0, [pc, #28
-
Thread
ATtiny24 - ISR wird nie gerufen __vectors> fehlt
/4.1.1/../../../../avr /sys-include" #include "..." search starts here: #include <...> search starts here: /usr/local/avr/lib/gcc/avr/4.1.1/include /usr/local/avr/lib/gcc/avr/4.1.1/../../../../avr/include
End of search list. GNU C version 4.1.1 (avr) compiled by GNU C version 3.4.4 [FreeBSD] 20050518. GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64436 Compiler executable checksum: e05a4be084b8452f07f20cde87edd4f1
-
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
Hallo Michael, danke dir für deine Arbeit! Ich habe hier einen 64 Bit Rechner und habe es mal mit make release übersetzt und nach amd64 umbenannt. Reicht das so, dass es für 64 Bit Ubuntu 12.04 geht? Kann das jemand mal testen? Gruss Benedikt
-
Thread
Fehlerhafte Adressierung von lokalen Arrays bei tinyAVR(R) 0-series
Das Programm zeigt auf einem ATmega4809 dasselbe Fehlverhalten; auf einem AVR128DB28 hingegen funktioniert es korrekt.
, SPM Z ATmega4809: ELPM, SPM, SPM Z+, EIJMP, EICALL AVR128DB28: EIJMP, EICALL https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf Aber muss man das alles wissen?
-
Thread
FT800 / FT810 Library
habe ich nur an der Oberfläche gekratzt. c-hater schrieb im Beitrag #6647994: > Unterstützung für AVR-Host-Flash >64kB) Also grundsätzlich ist das drin: [code] static inline uint8_t fetch_flash_byte(const uint8_t *data) { #if defined (__AVR_HAVE_ELPM__) /* we have an AVR with more than 64kB
bekommt. Wenn man die bei Microchip direkt kauft kosten die auf Rolle: ATSAMC20J17A-AUT €1.76 AVR128DA64T-I/PT €1.48 Aber ich würde ich eher mal bei Arrow, Avnet oder EBV anfragen, also auch gerade die AVR128DA64 wenn die für die Anwendung ausreichend sind. Zumal die ATSAMC20J15A-AUT und die
-
Thread
Timer geschickter programmieren
dass ein Blick ins Assembler Listing lohnt. [code] 000002e6 <test1>: 2e6: cf 93 push r28 2e8: df 93 push r29 2ea: e4 de rcall .-568 ; 0xb4 <jetzt> 2ec: ec 01 movw r28, r24 2ee: e2 de rcall .-572 ; 0xb4 <jetzt> 2f0: 8c 1b
2fc: 08 95 ret 000002fe <test2>: 2fe: cf 93 push r28 300: df 93 push r29 302: d8 de rcall .-592 ; 0xb4 <jetzt> 304: ec 01 movw r28, r24 306: a1 96 adiw r28, 0x21 ; 33 308: d5 de rcall .-
-
Thread
AVR Synthesizer mit ATxmega128A1
127, 119, 113, 106, 100, 95, 90, 85, 80, 76, 72, 68, 64, 61, 58, 55, 52, 50, 47, 45, 43, 41, 39, 37, 35, 33, 32, 30, 29, 28, 26, 25, 24, 23, 22, 21, 20, 19,
control A write_data(0x85); write_data(0x00); write_data(0x78); write_com(0xEA); //Driver timing control B write_data(0x00); write_data(0x00); write_com(0xED); //Power on sequence control write_data(0x64); write_data(0x03); write_data(0X12
-
Thread
GCC generiert 2 Jumptables bei Switch
anhand des etwas irreführenden Listings dass er es täte? Denn bei 676: e0 cf rjmp .-64 ; 0x638 <main+0x8> springt er natürlich nicht nach main+0x08, sondern nach 0x638 (0x676+2-64). Warum im Kommentar main+0x08 drinsteht weiss ich nicht. Aber nicht der Kommentar wird ausgeführt
ich weiß, aber 676+2-64 ist main+0x8 :) daher der kommentar main fängt bei 630 an das ergebnis ist so wie gewollt, aber ich möchte einfach nur das, der µC nicht erst 2x springen muss bevor er dann die richtige funktion
-
Thread
WS2812 Ansteuerung per Bitbanging für AVR und ARM von 4 Mhz-60 Mhz
No initialization required *Carefully optimized to use instructions which are available on all AVR cores and have the same instruction timing across all devices. *Supports standard AVR, reduced core AVR (Attiny 4/5/9/10/20/40) and XMEGA (untested) without special case handling. *New:Supports
+ asm volatile( e4: 98 e0 ldi r25, 0x08 ; 8 000000e6 <loop42>: e6: 28 bb out 0x18, r18 ; 24 e8: 87 ff sbrs r24, 7 ea: 38 bb out 0x18, r19 ; 24 ec: 88 0f add r24, r24 ee: 00 00 nop f0: 00 c0 rjmp
-
Thread
Display (HD4478099) zeigt nur Kästchen
30h,30h,30h,20h,28h,08h,01h,06h,0fh das sind die werte, so nun mal sehen, 30h b00001100 20h b00001000 28h b0010000 und danach b00001000 erst high dann low und so weiter, die Signale von RS E und RW kommand
/site/atmel/avr_lcd/pdf/LC.pdf
-
Thread
Zahl umdrehen?
z.B. links herausschieben und über das Carryflag in ein anderes Register links reinschieben. Für 64 Bit sind das allerdings 16 Register, in einem 8-Bitter wie dem AVR ist damit schon die Hälfte aller Register belegt.
Christoph db1uq K. schrieb im Beitrag #7415264: > Für 64 Bit sind das allerdings 16 Register, in einem 8-Bitter wie dem > AVR ist damit schon die Hälfte aller Register belegt. Man muss ja nicht alles um 64 Bit schieben. Je nach Architektur und Sprache
-
Thread
AVR Attiny10 External Interrupt in C
zumindest GCC auf nem Tiny versuchen, und dass es daher nicht vergemene Liebesmüh ist, den Support in avr-gcc und avr-libc weiter auszubauen, was entgegen deine Unkenrufe auch geschieht.
Support > in avr-gcc und avr-libc weiter auszubauen, was entgegen deine Unkenrufe > auch geschieht. Es ist schwer zu verstehen, dass Du nicht verstehst, ich hab' schon wesentlich bessere Posts von Dir gesehen. Es
-
Thread
Displayplatine Problem mit SPI DOGL128-6
Author: u308488 */ #define F_CPU 16000000 #include <avr/io.h> // Header-Datei f. IO-Register #include <avr/interrupt.h> // Header-Datei f. Interruptfunktion #include <stdint.h> // Header-Datei f. standard Datentypen #include <avr/pgmspace.h
eadog128_6.c * * Created: 22.01.2015 09:17:05 * Author: Dipl.- Ing. C. Graci */ #include <avr/interrupt.h> #include <avr/pgmspace.h> #include <avr/io.h> #include <stdlib.h> #include <stdarg.h> #include <ctype.h> #include <string.h> #include "eadog128-6.h" #include "font.h" #include
-
Thread
LTO und built-ins bzw libc-funktionen
int main() { int x = a % b; int y = a * b; return x + y; } [/c] führt bei AVR zu: [c] 000000e2 <main>: e2: 80 91 02 40 lds r24, 0x4002 ; 0x804002 <a> e6: 90 91 03 40 lds r25, 0x4003 ; 0x804003 <a+0x1> ea: 60 91 00 40 lds r22, 0x4000
gering, zum Beispiel sind fast alle Funktionen der libgcc eh in Assembly, außer einige Funktionen für 64-Bit double, wo der generierte Code aber auch sehr brauchbar ist (außer möglicherweise für avr-gcc v9+ wegen PR90706, aber das betrifft dann *allen* Code, nicht nur den in Libs).
-
Thread
Webasto W-Bus
zu erwecken, weiß mir aber dazu mit Bascom auch keinen Rat... Befehl an Heizgerät: F4 03 21 3C EA F4 = Wesbasto Thermo Test Software (F) sendet an Thermo Top V (4) 03 = ? 21 = Standheizen ein (21) für 3C = 59min (hex 3C = dez 60) EA = Checksum (XOR aus F4 03 21 3C)? Heizung antwortet:
Code? Hat jemand die Temperatur verfolgt die bei den QUERY_SENSORS zurückkommt? Meine geht auf MAX 64°C hoch. Andi
-
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
Knobelei: CRC Polynom / Checksummen-Algorithmus gesucht
== 19 FOUND: 7B == 7B FOUND: 6D == 6D FOUND: 57 == 57 FOUND: 41 == 41 FOUND: F4 == F4 FOUND: EA == EA FOUND: FC == FC FOUND: 38 == 38 FOUND: 02 == 02 FOUND: 14 == 14 FOUND: 25 == 25 FOUND: 90 == 90 ERROR: 86 == CA [code] #!/usr/bin/python # # crc8_custom.py # # custom crc8 calculation
0x58, 0x4D, 0x4A, 0x43, 0x44, 0x19, 0x1E, 0x17, 0x10, 0x05, 0x02, 0x0B, 0x0C, 0x21, 0x26, 0x2F, 0x28, 0x3D, 0x3A, 0x33, 0x34, 0x4E, 0x49, 0x40, 0x47, 0x52, 0x55, 0x5C, 0x5B, 0x76, 0x71, 0x78, 0x7F, 0x6A, 0x6D, 0x64, 0x63, 0x3E, 0x39, 0x30, 0x37, 0x22, 0x25, 0x2C, 0x2B, 0x06, 0x01, 0x08, 0x0F
-
Thread
STM32 Einstieg
Wenn ich die größten AVR Modelle (Xmega) mit den mittleren STM32 vergleiche, kommen sie mir gleich komplex vor. Die AVR sind aber 5x so teuer und nicht so einfach als steckbares Modul erhältlich.
komplex darzustellen ist genau so falsch, wie "die AVR" als besser geeignet darzustellen.
-
Thread
Korrupte Daten und Volatile
avr-gcc-4.4.2-2.fc12.x86_64. der bug sollte nicht das problem sein da mein gcc das volatile ja berücksichtigt. das blöde ist halt dass es egal ist was ich tue, sobald nur irgend was sich im assemblerfile
Dir den tatsächliche Wert von timer_count doch einfach mal über die UART ausgeben. Ansonsten, "avr-gcc-4.4.2-2.fc12.x86_64" sieht verdammt nach einer Default-Toolchain von Fedora aus. Wenn das tatsächlich so ist --> gaaaaaaanz schlechte Idee! Dem Teil fehlen mit ziemlicher Sicherheit etliche Patches
-
Thread
uC für 0,20€ CH552 / CH554 von WCH Billig Micro mit USB Funktion, Chip vorstellung
Jiangsu-Qin-Heng-CH563L_C87387.pdf Auch ohne Chinesischkenntnisse kann man dem folgendes entnehmen: ARM5TE, 224K Flash, 64K SRAM, 28K Dataflash, 10/100MBit-NIC, USB2.0 und die übliche Peripherie (2 16550-kompatible UARTs, 4 Timer, diverse I/Os, SPI). Im 128poligen TQFP-Gehäuse kostet der dann bei LCSC aber "richtig" Geld
) = 64 Bytes braucht ein ZLP um das Ende zu erkennen > 64 Bytes ist ein 64 Byte Transfer + Rest Das war auch beim Code von W.S. lange ein Problem.