Quatsch, das macht doch schon der CTC-Modus. > [c] > OCR3AH=0x20; //Zählgrenze=8192 --> 0d8192=0x2000 > OCR3AL=0xFF; //16Bit-Zähler --> 2*8Bit-Register nutzen (L,H) > [/c] Warum schreibst Du es so umständlich, rechnest Du so gerne in Hex um? Außerdem ist es falsch: 0x2000 - 1 = 0x1FFF und
reset. The value of the LFSR cannot be read; it must be tracked/generated in software. 0x20000000 0x2000FFFF External Memory 1 Example of a sequence: 0x30000000 0x3000FFFF External Memory 2 0x40000000 0x4000FFFF External Memory 3 1. Enter initial seed, 0xAA, in T3CLRI before starting Timer3 in watchdog
l_table_auswahl_memory table_auswahl_memory[max_table_auswahl_memory] __attribute__((section("table_auswahl"),address(0x2000))); Was mir nicht in den Sinn will, der C30 ist doch ein so moderner und leistungsfähiger Compiler, das dieser nicht selbst berechnen kann, wo ein Array mit der Größe X, angelegt wird. Gruß Siegfried
Count = 4 Repeat Count = 8 Repeat Count = 16 VREF x 4095/4096 0x3FFC 0x7FF8 0xFFF0 VREF x 2048/4096 0x2000 0x4000 0x8000 VREF x 2047/4096 0x1FFC 0x3FF8 0x7FF0 0 0x0000 0x0000 0x0000 Rev. 1.1 61 C8051F52x/F52xA/F53x/F53xA 4.3.6. Settling Time Requirements A minimum tracking time is required before an accurate
gelade wird, der ist aber dort. Das habe ich mit dem Simulator getestet, der String liegt an Adresse 0x2000, hier fängt beim Xmega das SRAM an. Das erste Byte, welches in das Usart-Datenregister kopiert wird, ist das "H" ... kommt mir irgendwie unheimlich vor :-D Ich werde das alles auch noch mal mit
angepasst - Taster Port/Pin angepasst - Flash Adresse .text in den memory Settings von 0x10000 auf 0x2000 geändert - Die Signature Bytes angepasst Danach hat das beiliegende Programm (baudrate auf 19200 geändert) auch eine Kommunikation aufgebaut, bricht dann aber später mit folgender Meldung ab
----------------------------------- pstObj->ubMOCfg |= (ubyte)((CAN_HWOBJ[ubObjNr].uwMOAMRH & 0x2000) >> 7); // set MIDE //----- get Frame Counter Value --------------------------------------- pstObj->uwCounter = CAN_HWOBJ[ubObjNr].uwMOIPRH; } // End of function CAN_vGetMsgObj
11kB groß geworden! Es gibt einen wrap-around, weil der ATmega nur 8k Flash hat. Somit wird Byte 0x2000 an Adresse 0 geschieben usw. Beim Auslesen ergibt sich dann ein Fehler.
16 isochronous endpoints, and make the 2-KB of isochronous FIFO RAM available as 8051 data RAM at 0x2000-0x27FF. Setting ISODISAB=1 is an all or nothing choice, as all 16 isochronous endpoints are disabled. An application that sets this bit must never attempt to transfer data over an isochronous endpoint
16 isochronous endpoints, and make the 2-KB of isochronous FIFO RAM available as 8051 data RAM at 0x2000-0x27FF. Setting ISODISAB=1 is an all or nothing choice, as all 16 isochronous endpoints are disabled. An application that sets this bit must never attempt to transfer data over an isochronous endpoint
Gut, geht jetzt wohl. Ich habe einfach den Speicherbereich ab 0x2000 anfangen lassen, ist ja massig Platz im Flash, wahrscheinlich ist da ein teil kaput gegangen, auf jedenfall geht es jetzt, werde es morgen noch bis zum exess Testen, auch mal mit anderer Hardware.
. */ . = ALIGN (0x10000) - ((0x10000 - .) & (0x10000 - 1)); . = DATA_SEGMENT_ALIGN (0x10000, 0x2000); /* Ensure the __preinit_array_start label is properly aligned. We could instead move the label definition inside the section, but the linker would then create the section even if
Tool (Assembler) je nachdem, in welche Variable Du die Konstante schreiben willst mal 0x20, mal 0x2000 oder mal 0x20000000 daraus macht erhöht das die Fehlerwahrscheinlichkeit enorm. Darum bin ich mir auch relativ sicher, dass diese obskure Sonderregel nur für Addressen gilt und nicht für sonstige Arithmetik
Pocket DV Camcordern erzählst die gerade mal 1280x720 schaffen (5M Pixel wären ja was um die 2500x2000 Pixel und das mal 3 ;) ) glaub ich das eher nicht?
Schaltungen übergegangen und habe die Versuche gar nicht mehr gemacht. Das Anleitungsbuch zum X1000 - X2000 ist zwar recht unterhaltsam gewesen, hat aber leider nicht alles komplett erklärt. So ist das Verstärkermodul für mich lange eine Blackbox geblieben. Wenn es auch faszinierend ist, was man damit alles
liegen und die 2x2000 pF parallel geschaltet sind?
-------+-----------o grün 0,06 µF PE o---------------------------o gelb/grün 2x2000 pF [/pre] Sehe ich das richtig, daß da intern jeweils 2000 pF von Netz (grün und schwarz) gegen PE verschaltet sind, die 0,02 µF rot/grün gegen schwarz und die 0,06 µF grün auch gegen schwarz?
> > a) Das Bild hat 3000x2000 Pixel > > Bei der Angabe hab ich aber keine Möglichkeit wieder auf die 15x10xm zu > kommen ohne die DPI Anzahl zu kennen... Aber ja doch. Die dpi-Zahl berechnet sich als Quotient aus Größe und
und > Pixelzahl. Wie groß ist denn eines der 3000x2000 Pixel des Bildes auf dem Drucker?
Linker-Script wuerde ich mir gerne ersparen): [pre]LDFLAGS += [...] -Wl,--section-start=.bigalign=0x2000[/pre] Im Map File steht nun das am Ende: [pre].bigalign 0x00002000 0x800 .bigalign 0x00002000 0x800 font.o 0x00002000 font[/pre] Ich
Compiler zur Compilezeit. Die Lösung mit der Kommandozeile -Wl,--section-start=.bigalign=0x2000 ist hölzern (weil an bestimmten AVR gebunden) aber übersichtlich. Die Angabe 0x2000 ist dabei gcc-typisch eine Byteadresse. Es geht auch eleganter über ein _zusätzliches_ Linkerskript:
bypassing the boot sequence: Execute from 16-bit external memory – Execution starts from address 0x2000 0000 with 16-bit packing. The boot ROM is bypassed in this mode. All configuration settings are set for the slowest device possible (3-cycle hold time; 15-cycle R/W access times; 4-cycle setup). Boot
:0); [--SP] = LC0; [--SP] = LT0; [--SP] = LB0; /******************************/ BOOT_DXE: R0.H = 0x2000; // R0 = start of ASYNC Bank 0 R0.L = 0x0000; P1 = 2; // Number of DXEs to jump over (CANNOT BE ZERO!!) // After first iteration, R0 will point to DXE1 // After second iteration, R0 will point to DXE2
the entire SRAM as working area $_TARGETNAME configure -work-area-phys 0x10000 -work-area-size 0x2000 ## flash configuration # only target number is needed flash bank aduc702x 0x80000 0xf800 0 0 ## If you use the watchdog, the following code makes sure that the board ## doesn't reboot when
PowerUp auch gleichzeitig auf Adresse 0x0000 0000 "gemapt". Das RAM befindet sich auf der Adresse 0x2000 0000. Nach dem Remap Befehl (ist ein einfacher toggle) wird die Adresse vom RAM auf die Adresse 0x0000 0000 "gemapt". Somit steht dann ein RAM an Adresse 0x0000 0000 zur Verfügung. Sinn macht der
Funtionsteile voneinander gekapselt (der spätere Bootloader liegt in den ersten beiden Sektoren 0x0000 - 0x2000 und die Applikationssoftware liegt ab Adresse 0x2000). Ich will die Programme erst später auftrennen, aber auch dann muss ich vom Flashbooter auf eine definierte Adresse (in meinem Fall 0x2000) springen
CR><LF>" compares 4 bytes from the RAM address 0x4000 0000 to the 4 bytes from the flash address 0x2000. 20.8.14 ISP Return codes Table 209: ISP Return codes Summary Return Mnemonic Description Code 0 CMD_SUCCESS Command is executed successfully. Sent by ISP handler only when command given by the host
resetFIFO(reset); checkFlags('1','0','0','0',empty,full,underflow,overflow); -- push once pushData(X"2000",1,0,data_in,push); checkFlags('0','0','0','0',empty,full,underflow,overflow); -- pop once popData(1,pop); checkFlags('1','0','0','0',empty,full,underflow,overflow); -- pop once more, too much popData
CR><LF>" compares 4 bytes from the RAM address 0x4000 0000 to the 4 bytes from the flash address 0x2000. 20.8.14 ISP Return codes Table 209: ISP Return codes Summary Return Mnemonic Description Code 0 CMD_SUCCESS Command is executed successfully. Sent by ISP handler only when command given by the host
Byteadressen!). Bei einem ATMega8 z.B. sind es 8KB = 8192 Bytes. In hexadezimaler Schreibweise sind das 0x2000 Bytes. Auch wenn Du links noch mehr Nullen davorhängst, und z.B. 0x0002000 schreibst, sind es immer noch nur 8192 Bytes. Du hast in deinem Makefile 0x000BC000 angegeben. Das sind 770048 Bytes = 752KB
Anfang und Ende des heaps absolut festlegen --defsym=__heap_start = 0x1000 --defsym=__heap_end = 0x2000 Mehr noch man kann sogar explizit den malloc Bereich definieren: __malloc_heap_start __malloc_heap_end Funktioniert das auch beim arm-elf-gcc, oder irgendwas anderes mit vergleichbarem Resultat
Also 5,82 gleich +8% Fehler. Bei 100x/200y wäre der unterschied 241/223,6 (+7,8%). Bei bei 1000x/2000y wäre der Fehler ähnlich 2410/2236. Also durchaus machbar.
gesamten Code aus dem Flash in den RAM und setzte dann das Remap Bit. memcpy(0x00200000,0x00100000,0x2000); AT91C_BASE_MC->MC_RCR = AT91C_MC_RCB; Das ganze mache ich in der LowLevelInit.c, welche nach den Befehlen mit dem Wort SECTION ausgeführt wird (siehe unten). Von den Speicherbereichen passt
Code aus dem Flash in den RAM und setzte dann das Remap Bit. > > memcpy(0x00200000,0x00100000,0x2000); > AT91C_BASE_MC->MC_RCR = AT91C_MC_RCB; Dem Linker wurde nicht mitgeteilt, dass ein Teil der RAM-Bereichs für Code genutzt werden soll. Wenn man alle sections in die RAM region linkt, sollte
