-
Thread
butterfly datenlogger software in Betrieb nehmen
main.cof avr-objcopy --debugging --change-section-address .data-0x800000 --change-section-address .bss-0x800000 --change-section-address .noinit-0x800000 --change-section-address .eeprom-0x810000 -O coff-ext-avr main.elf main.cof avr-objcopy: main.elf: no recognized debugging information avr-objcopy
Exit Code: 0[/code] Wenn ich im Studio nun main.cof öffne und dann im AVR-Simulator den ATmega169 wähle erscheint der Disassembler. Der C-Quellcode scheint also zu fehlen. Was habe ich falsch gemacht? Matthias
-
Thread
IRMP - Infrared Multi Protocol Decoder
Sieht besser aus: F_INTR | text | data | bss | dec | vgl. zu 16000 ---------+---------+-------+-------+---------+----------------- 5000 | 11104 | 180 | 113 | 11397 | -268 6000 | 11108 | 180 | 113 | 11401 | -264
, is ja ein fertig verbauter Gasmelder mit Atmega169 und Irda Transceiver daher kommt für mich nur zweiteres in Frage . Und ich hab mich grad riesig gefreut da du was zu dem 3/16 Dings geschrieben hast und das auch noch auf einfache weise Ich werde
-
Thread
NXP verschenkt ARM-Chips
interrupts */ ldr r1, =VICSOFTINTCLR mov r2, #0xFFFFFFFF str r2, [r1] /* zero-out the bss */ ldr r3, =__bss_start__ ldr r4, =__bss_end__ bl zeromemory /* copy initialized data from ROM to RAM */ ldr r3, =__data_load_start__ ldr r4, =__data_start__ ldr r5, =__data_end
R0, [R1], #4 STRLO R0, [R2], #4 BLO LoopRel # Clear .bss section (Zero init) MOV R0, #0 LDR R1, =_bss_start LDR R2, =_bss_end LoopZI: CMP R1, R2 STRLO R0, [R1],
-
Thread
Besteht Interesse an einfacher Experimentierplatine fuer den Xmega128a1? Gesperrt
bytes (0.4% Full) (.text + .data + .bootloader) Data: 0 bytes (0.0% Full) (.data + .bss + .noinit) -------- end -------- Olli
atmega16 atmega161 atmega162 atmega163 atmega164p atmega165 atmega165p atmega168 atmega168p atmega169 atmega169p atmega32 atmega323 atmega324p atmega325 atmega325p atmega3250 atmega3250p atmega328p atmega329 atmega329p atmega3290 atmega3290p atmega406 atmega64 atmega640 atmega644 atmega644p
-
Thread
Strombegrenzung mit Fet um Akku zu laden
Strombegrenzung mittels Fet realisieren und dabei den Ladestrom eines Akkus begrenzen. Dazu möchte ich den BSS169 verwenden. Laut Datenblatt besitzt dieser eine UGS von ~0.3V bei 150mA was einen Widerstand von 2 Ohm ergibt. Wenn ich das ganze aufbaue wird der Strom zwar begrenzt, jedoch ist dieser abhängig von meiner Versorgungsspannung und von der Akkuspannung. Sollte der BSS19 nicht ab einer Spannung von 4.5V (4.2 max. Akkuspg. + 0.3V UGS ) als Konstantstromquelle funktionieren und permanent 150mA liefern? Datenblatt ist im Anhang! Vielen Dank für die Hilfe!
-
Thread
MSP430 mspgcc Fehler bei .elf erstellen
oder manuell auf dein Elf-File, dann siehst du, wieviel Flash und RAM benutzt wird. txt ist Flash, bss und data ist RAM.
ich es eintragen musste. Sieht ohne den sdbuffer[512] folgendermassen aus: text 27454 data 64 bss 1583 dec 29101 hex 71AD Tja, da bss bereits auf 1583byte ist, denke ich, ich hab zu wenig RAM :o( Seh ich das richtig? Gruss Guest
-
Thread
C und Assembler
Assembling: PPR_TEST.S avr-gcc -c -mmcu=atmega169 -I. -x assembler-with-cpp -Wa,-adhlns=PPR_TEST.lst,-gstabs PPR_TEST.S -o PPR_TEST.o Assembling: REG_TEST.S avr-gcc -c -mmcu=atmega169 -I. -x assembler-with-cpp -Wa,-adhlns=REG_TEST.lst,-gstabs REG_TEST.S -o REG_TEST.o Assembling: ARI_TEST.S avr-gcc -c -mmcu=atmega169 -I. -x assembler-with-cpp -Wa,-adhlns=ARI_TEST.lst,-gstabs ARI_TEST.S -o ARI_TEST.o Assembling: LOGI_TEST.S avr-gcc -c -mmcu=atmega169 -I. -x assembler-with-cpp -Wa,-adhlns=LOGI_TEST.lst,-gstabs
-
Thread
Projet um die Kapazität von Akkus zu messen
AkkuTester.elf : section size addr .text 25960 0 .data 36 8388704 .bss 1316 8388740 .noinit 0 8390056 .eeprom 0 8454144 .stab 46692 0 .stabstr 17481 0 Total 91485 [/pre] und jetzt poofen!
3,74 339 68 3828 146 3898,50 85 3,73 339 73 3823 157 3898,50 90 3,73 337 78 3806 169 3875,50 95 3,72 338 77 3817 182 3887,00 Rimax = 6000 mOhm Rimittel = 1068 mOhm Ich stelle doch fest, dass Uanz durchaus mit Ubat in einem Zusammenhang steht. Die Abweichung kommt sicherlich
-
Thread
SMD-Baustein identifizieren
Die Bezeichnung "U" ist schon für allgemeine Halbleiter üblich. (CE ist im SMD-Code ein BSS 79B, natürlich nur 3Pins). Ricoh baut einige Funktionen in 5polige Gehäuse (SOT-23-5), auch wenn nicht alle Pins belegt sind: Spannungsdetectoren RN5VL-Serie, RN5VT. Spannungsregler RX5RL-Serie.
/components2/Datasheet_Sync//170/7247.pdf http://www.toshiba.com/taec/components2/Datasheet_Sync//169/21378.pdf Jetzt könnte das Partmarking allerdings auch ein "SE" sein, dann istst ein OPV, genauer ein TC75S54F/FU. Kann also einiges sein ;-)) Gruß und viel Erfolg Axelr.
-
Thread
MMC SD library FAT16 FAT32 read write
bytes (75.5% Full) (.text + .data + .bootloader) Data: 686 bytes (67.0% Full) (.data + .bss + .noinit)
bytes (43.8% Full) (.text + .data + .bootloader) Data: 1528 bytes (74.6% Full) (.data + .bss + .noinit)
-
Thread
AVR Eclipse Plugin 2.2
Zukunft Invoking: Print Size avr-size --format=berkeley -t Mega8Modul.elf text data bss dec hex filename 452 0 93 545 221 Mega8Modul.elf 452 0 93 545 221 (TOTALS) Finished building: sizedummy make: Warnung: Mit der
AtMega8 (Hardware-TWI) erfolgreich auslesen. Nun möchte ich aber gerne das Butterfly Board (AtMega169p) verwenden, um Display und Sound nutzen zu können (funktioniert auch schon halbwegs mit simulierten Druckwerten). Problem: AtMega169p kann nur USI. Warum Assembler? Eigentlich um zu lernen wie
-
Thread
AVR-Bootloader mit Verschlüsselung
include "m168def.inc" ; ATmega168 ;.include "m168Pdef.inc" ; ATmega168P ;.include "m169def.inc" ; ATmega169 ;.include "m169Pdef.inc" ; ATmega169P ;.include "m16def.inc" ; ATmega16 ;.include "m2560def.inc" ; ATmega2560 ;.include "m2561def.inc" ; ATmega2561
m1284P m128A m128 m128RFA1 m128RFR2 m162 m164A m164PA m164P m165A m165PA m165P m168A m168 m168PA m168P m169A m169PA m169P m16A m16 m16HVA m16HVB m16M1 m16U2 m16U4 m2560 m2561 m256RFR2 m324A m324PA m324P m3250A m3250 m3250PA m3250P m325A m325 m325PA m325P m328 m328PB m328P m3290A m3290 m3290PA m3290P m329A
-
Thread
Parallele Schnittstelle an AVR?
avr-objcopy.exe: there are no sections to be copied! AVR Memory Usage ---------------- Device: atmega169 Program: 4068 bytes (24.8% Full) (.text + .data + .bootloader) Data: 1055 bytes (103.0% Full) (.data + .bss + .noinit) Build succeeded with 11 Warnings...
>Data: 1055 bytes (103.0% Full) >(.data + .bss + .noinit) >Build succeeded with 11 Warnings... nicht mal eine Fehlermeldung. Nicht schlecht. MW
-
Thread
lötstation ZD-917
BSS138 was solln des sein?
Ich sage zu der Station nur: http://www.mikrocontroller.net/topic/80294#postform Gruß mark-169
-
Thread
ez430 msp340f2013 eclipse mspgcc
kein SPW. Die neuen µC habe ich mir noch gar nicht angeschaut. Bisher geht es bei mir nur um einen 169er bei meiner "Programmierung" reicht die freie Version des IAR leider nicht mehr aus. Hab auch schon den Code Composer probiert. Der Programmer funktioniert auch mit diesem aber mir gefällt das Bedienkonzept
Matej schrieb: > für Olimex MSP430F169 board und > MSP430-JTAG-TINY für meine Studenten das hört sich sehr interessant und engagiert an. Gibt es auch Support für neuere chips? Es gibt ja auch andere Teile mittlerweile mit dem neueren
-
Thread
Lichtsensor überprüfen aber wie?
Also im Augenblick wird die BPW21 mit dem Ad8571 betrieben und über den 12 BIT ADU des MSP430F169 ausgewertet. Den LTC2400 habe ich erst einmal auf Eis glelegt, da durch die Bereichsumschaltung ja eine so hohe Genauigkeit Blödsin ist. Was ich noch immer nicht verstehe, wenn ich den BS170 so betreibe
In welcher sprache hast du deinen Controller programmiert? Assembler? In C wurde der gute MSP430F169 Programmiert.
-
Thread
WinAVR Fehler ?! BITTE UM HILFE
warning: pointer targets in passing argument 2 of 'searchParameter' differ in signedness httpd.c:169: warning: pointer targets in passing argument 1 of 'searchParameter' differ in signedness httpd.c:169: warning: pointer targets in passing argument 2 of 'searchParameter' differ in signedness httpd.c
size addr .text 56828 0 .data 1586 8388704 .bss 1480 8390290 .noinit 0 8391770 .eeprom 0 8454144 .stab 876 0 .stabstr 132 0 .debug_aranges 420
-
Thread
FET SST113 Vergleichstyp ?
Es handelt sich also um einen "N-Kanal JFET". Ich habe bisher immer nur mit MOSFETs gearbeitet (BSS138, IRF5210...). Nun stellt sich die Frage welchen Typ ich als Vergleichstyp dieses Exoten hernehmen kann, am besten einen den es bei Reichelt gibt. Das wäre auch die Gelegenheit sich erklären zu lassen
Infineon nach Depletion-MOSFET suchen, die eine VGS(Off) von weniger als -2Volt haben, z.B. BSP149 oder BSS169. JFET sind normalerweise selbstleitend, d.h. mit Gate und Source kurzgeschlossen fliesst ein (relativ hoher) Strom, während die LeistungsMOSFET unter diesen Bedingungen gesperrt sind. Zur Theorie
-
Thread
MSP430 can't allocate stack
. Größe, die erzeugt wird: msp430-size --target=elf32-msp430 Test.elf text data bss dec hex filename 672 10 68 750 2ee Test.elf
msp430x1491 msp430x155 msp430x156 msp430x157 msp430x167 msp430x168 msp430x169 msp430x1610 msp430x1611 msp430x1612 msp430x2101 msp430x2111 msp430x2121 msp430x2131 msp430x311 msp430x312 msp430x313 msp430x314 msp430x315 msp430x323
-
Thread
Mehrdimensionale char-arrays
[ 4] 167 or a, a 0026 C8 [11] 168 ret Z 169 ;driver.c:29: putchar(*(k++));
_CODE .area _GSINIT .area _GSFINAL .area _GSINIT .area _DATA .area _BSEG .area _BSS .area _HEAP [/code]
-
Thread
größe von speicher und hex.file
zur Größe von hex.files und der Speichergröße von Microcontrollern. Laut Datenblatt hat der ATmega169 16K Bytes In-System Programmable Flash und derATmega8 8K Bytes In-System Programmable Flash Das sollte IMHO der Speicher sein, in dem mein Programm drin steht? Jetzt habe ich mal ein kleines, wohl
garnicht reinpasst. Versuchsweise habe ich es jetzt mal in den 16K - Speicher des Butterfly (ATmega169) geschrieben was zu meinem großen Erstaunen auch funktionierte. Das Hex-file. das ich zuvor zur Sicherheit von der Butterfly-Software gelesen und danauch auch wieder dort reingeschrieben habe war mit
-
Thread
The Siemens S65 132x176, 65536 color display with AVR
@All: Der Controller des LS020 ist ein Sharp LR38826. Die power off sequence ist vom LR38825+LH169C. Es könnte sein dass einige register miteinander komatibel sind. Ich bleibe dran.....
For led power supply used PWM output of AVR. I can't find BAT54 and BSS123, placed on circuit. Please tell me analog of these parts, or another circuit for PWM 10V-generator. Sorry for my bad English )))
-
Thread
bug in winAVR?
AVRISP. Nach dem Compilierten erhalte ich mit avr-size folgende Angaben: text data bss dec hex filename 12786 2221 169 15176 3b48 blabla.o Beim Flash-Versuch mit AVRStudio und AVRISP erhalte ich die Fehlermeldung: 'The contents of the HEX file does
wieder alles ohne Fehler: Von 'WinAVR-20050214' zurück auf 'WinAVR-20040720'. text data bss dec hex filename 13020 2221 169 15410 3c32 blabla.o Das Hex-File läßt sich jetzt wieder flashen. Hab ich was flasch gemacht, etwas nicht beachtet, das man bei der neueren
-
Thread
ATmega128, AVRISP: 'hex file does not match' ??
AVRISP. Nach dem Compilierten erhalte ich mit avr-size folgende Angaben: text data bss dec hex filename 12786 2221 169 15176 3b48 blabla.o Beim Flash-Versuch mit AVRStudio und AVRISP erhalte ich die Fehlermeldung: 'The contents of the HEX file does not
-
Thread
Fragen zu Interrupts mit (win)avr-gcc
2. Der Objektcode ist nahezu explodiert. Wenn ich o.g. Verfahren für alle Interrupts des ATmega169 einsetze, wächst der Code um ~1700Bytes: ohne isr.c: AVR Memory Usage: ----------------- Device: atmega169 Program: 462 bytes (2.8% Full) (.text + .data + .bootloader) Data: 42 bytes (4.1% Full) (.data + .bss + .noinit) mit isr.c: AVR Memory Usage: ----------------- Device: atmega169 Program: 2174 bytes (13.3% Full) (.text + .data + .bootloader) Data: 44 bytes (4.3% Full) (.data
-
Thread
AVR Bootloader
Hallo, unterstützt dieser Bootloader hier eigentlich auch den ATmega169? Gruß Thorsten
bytes (59.8% Full) (.text + .data + .bootloader) Data: 738 bytes (72.1% Full) (.data + .bss + .noinit) Die .hex-Datei ist 14kB groß. Was mache ich falsch?