;CodeVisionAVR C Compiler V1.24.3b Standard ;(C) Copyright 1998-2004 Pavel Haiduc, HP InfoTech s.r.l. ;Chip type : AT90S8535 ;Clock frequency : 8,000000 MHz ;Memory model : Small ;Optimize for : Size ;(s)printf features
SRAM-Daten langsamer zu verarbeiten sind als Da- ten in Registern. Dafür besitzt schon der zweitkleinste AVR immerhin 128 Bytes an SRAM-Speicher. Da passt schon einiges mehr rein als in 32 popelige Register. Die größeren AVR ab AT90S8515 aufwärts bieten neben den eingebauten 512 Bytes zusätzlich die Möglichkeit
( ( ( C ( ( T ( (NC = Do not connect (May be used in future devices) (2) Timer2 Oscillator 2 ATmega128CAN11 4251A–AVR–May 2003 ATmega128CAN11 Overview The ATmega128CAN11 is a low-power CMOS 8-bit microcontroller based on the AVR enhanced RISC architecture. By executing powerful instructions in a single
SRAM-Daten langsamer zu verarbeiten sind als Da- ten in Registern. Dafür besitzt schon der zweitkleinste AVR immerhin 128 Bytes an SRAM-Speicher. Da passt schon einiges mehr rein als in 32 popelige Register. Die größeren AVR ab AT90S8515 aufwärts bieten neben den eingebauten 512 Bytes zusätzlich die Möglichkeit
( ( ( C ( ( T ( (NC = Do not connect (May be used in future devices) (2) Timer2 Oscillator 2 ATmega128CAN11 4251A–AVR–May 2003 ATmega128CAN11 Overview The ATmega128CAN11 is a low-power CMOS 8-bit microcontroller based on the AVR enhanced RISC architecture. By executing powerful instructions in a single
ermöglicht die Darstellung von Farbbildern auf einem TV. Das beste daran: Die Software läuft auf einem AVR, der noch etwa 30-40% Rechenleistung frei hat um z.B. das Bild aufzubauen oder andere Sachen zu erledigen. Die Bildausgabe läuft im Hintergrund. Abgesehen von den 64kB SRAM kommt die Schaltung nur mit
man noch ne data request output haben, dass man sieht, wenn der avr grad zu tun hat....
liegt. Ich habe mit exakt den gleichen Widerständen am Mega8 direkt auf einem Videomonitor (alter C64 Monitor) ein glasklares Bild... Die Ausgangspegel sind ja eh bei beiden AVR´s gleich. Desweiteren läuft mit dem Mega16 bei mir das Bild neben den Verzerrungen durch was direkt auf einen falschen
paar Euronen. (LPC2119 für etwas mehr als 10Euronen) Was soll man zum Thema Leistung sagen: 60MHz, 128kiB Flash, 16kiB SRAM, mehr als genug IO, jede Menge Features... das einzige Problem ist bei den ARM immer das Gehäuse: LQFP-64 ... dafür muss man erstmal die Platine herstellen können. Löten dürfte
ldi wrH,Low(RamEnd) out spl,wrH ;Stack initialisiert in der DeviceDatei "...\AvrAssembler2\Appnotes\m128def.inc" habe ich die Einträge gefunden... #pragma AVRPART MEMORY PROG_FLASH 131072 #pragma AVRPART MEMORY EEPROM 4096 #pragma AVRPART MEMORY INT_SRAM SIZE 4096 #pragma
relativ leicht ausrechen über 1/(Zugriffszeit in ns * 10^-3) wenn ich mich jezt nicht vertan habe. 64kx8 SRAM= 64.000 bytes (mußt im DB gucken obs 64k bits oder 64kx8 sind, im erstenfalle vorher durch 8 teilen) Also INT_SRAM SIZE=644096
HP500 usw.) können PCL (HP-Standard), da findet mach auch die nötigen Unterlagen. Ist für einen AVR kein Problem, 2k Flash reichen da immer. Was die Datenmege angeht, siehe voriges Posting von Läubi. Gruß aus Berlin Michael
zwischenText- und Grafikmode nicht beliebig gewechselt werden kann usw. usw. Erinnert mich an C64-Zeiten. ;-) Naja, reizvoll, aber ob ich es heute nochmal so machen würde???? Gruß aus Berlin Michael
Moin! Ich hab gerade in Assembler (für AVR-Mega8535) eine Suchroutine gebastelt, die mir die Tabellenposition eines 16-Bit-Wertes heraussucht. Ich hab nur irgendwie das Gefühl, daß es etwas kompliziert geworden ist und frage mich, ob man das
Wahrscheinlich hab ich dich falsch verstanden, aber wenn du nur 128 Einträge in deiner Tabelle hast und die eventuell auch noch alle unterschiedlich sind, könntest du nicht Hashing benutzen? Kommt halt drauf an, ob man das modulo effizient hinkriegt.
Ich habe es mal auf einem AVR ausprobiert: Ein tiny2313 sendet mit 6,4kHz Samplerate die Symbole mit 64 Werten Länge. Macht also 100Baud Datenrate. Ein mega48 @22MHz digitalisiert mit 6,4kHz und erzeugt daraus wieder die Bitwerte
das ganze noch in C geschrieben ist, in Assembler wären bestimmt noch 50% mehr Bandbreite möglich. 64Werte und 6,4kHz benötigen immerhin rund 820000 Multiplikationen pro Sekunde. Das ist fürt einen AVR schonmal nicht schlecht. Das ganze funktioniert wunderbar, nur fehlt mir noch eine passende Modulatorschaltung
www.ispf.de mit UART Library und optimierter Ausgaben. Es kann gleichzeitig als Beispiel für andere AVR Systeme dienen. Neu: - UART Library - RS232 auch ohne Baudraten Quarz dafür aber mit 16MHz - optimierter Memory Dump - Speicher-Test nach Typ getrennt - Memory Bank Ausgabe - UART0 Ausgabe auf ATMega128 - WinAVR 20060421 geeignet Viel Erfolg Michael ---------------------------------------------------------------------- Bildschirm Hardcopy: Welcome to the arthernet external memory test
wo der µC selbst labert: http://www.romanblack.com/picsound.htm Ja, es ist ein PIC, auch wenn die AVR Fraktion das nicht für möglich halten würde. Aber es geht ja auch mit Atmels: http://s-huehn.de/elektronik/bbgong/bbgong.htm bye Frank
. By the way: Wo komm ich denn an günstige SD/MMC Cards ran? Gibt´s denn keine mehr mit 32 oder 64 MB? Dat würde haufig reichen. Sodele und nochwas kurzes. Die Würzburger Straßenbahn hält sich tatsächlich an Ihren Fahrplan. *gg* Für die DB AG wollen wir das Gerät nicht anbieten. (Nur für den Nahverkehr
Das ist nicht zufällig das C-File von M.Thiele? das lief bei meinem 128x64-Display fast auf Anhieb. Allerdings ist mein Command-Port auf Port C. Ich hatte Probleme mit dem Reset. Habe diesen an das System-Reset angeschlossen (MCU) und es funktionierte.
eher um ein schaltungstechnisches Problem. Welches Grafik-Display(!!!) hast Du denn angeschlossen (128x64)?
gesamte Programm (eigentlich nur TOSC2-, I2C/TWI, UART-Routinen) in die Bootloader-Sektion eines Mega128 packen kann, hätte ich doch ausreichend Platz für Daten im Programm-Flash des µC. Mit PICs soll das ja laut Sprut funktionieren, mir wäre aber ein AVR lieber, da ich die Werkzeuge inkl. Debugging einfach
Datenlogger gebaut, dafür aber einen Mega8L + 24LCXXX verwendet. Gibt's bei Reichelt bis 512kbit (64kByte) und kostet zusammen weniger als ein Mega128... Gruss, Thorsten
rechts), nur dass hier die Basis 2 ist. Dezimal: z.B. ...1000er, 100er, 10er, 1er Binär: ...128er, 64er, 32er, 16er, 8er, 4er, 2er, 1er (0b 0 0 0 0 0 0 0 0) Solange Du das nicht verstanden hast, brauchst Du mit µC-Programmierung gar nicht erst anzufangen. Bitte beschäftige
Bits übrig, die wir als "Nachkommabits" verwenden können. Wir skalieren (=multiplizieren) mit 2^7=128, d.h. wir können die Frequenz auf 1/128 Hz genau einstellen. Nun brauchen wir den Wert 2^64/180000000=102481911520,60862008889 = 0x17DC65DEE0. Der hat 37 Bits, also skalieren wir durch 2^(37-32=
sollten wir ihn mal hierher lotsen... So weit ich sehe, sind die momentanen Verbesserungen für 64-Bit gcc schon recht gut: http://gcc.gnu.org/viewcvs/trunk/libgcc/config/avr/lib1funcs.S
Hallo, das ist der Kram, den ich im Moment initialisiere (AVR-Assembler): .equ ENC_RX_BUF = $0000 .equ ENC_RX_BUF_LEN = $1000 .equ ENC_TX_BUF = $1000 .equ ENC_MAX_FRLEN = 1518 enc_init_tab: .db ERXSTL,low(ENC_RX_BUF) ; RX-Buffer Start
timern laufen, evtl. auf einen pwm3. hw: attiny2313, quarzfrequenz 4 mhz, ckdiv8 inaktiv. sw: avr-gcc 4.0.1, binutils 2.15.97, avr-libc 1.4.3 auf mandrake linux 2006. laut doku 2543h-avr-02/05 hat der timer 0 zwei unabhängige oc register. bei mir ist nur der oc0b pin verfügbar: // set oc0b
erzeugen: // set oc0b as output pin DDRD |= (1 << PD5); TCCR0A = 0x12; // mode 2 ctc on oc0b/db5 TCCR0B = 3; // prescaler = 64 OCR0B = 77; // 4 mhz / 2 * 64 * (1 + 77) = 400,64 hz mit meinem hameg 312 messe ich am oc0b 158 hz = 6,33 msec periode, unabhängig vom wert von ocr0b?????? in http
darin also keinen Platz. Wenn ich mich nicht irre, rechnet dein Compiler auch nur mit Ganzzahlen. Beim AVR-Assembler z.B. wird (vom Assembler) mit 32-Bit-Ganzzahlen gerechnet. Das Konstrukt: > OCR2 = ((XTAL/64/Timer_2_CLOCK) -1); ist übrigens was für Profis oder Mathematiker, ich habe es gern einen
leider arbeitet BasCom nur mit Auflösungen von 240x128,128x128,128x64 usw
ganze Weile herum, um eine Grafik richtig auszugeben... Ich habe die aktuellste t6963c.h für mein 128x128 Display angepasst und habe nun folgendes Problem: Wenn ich eine Linie von 0,0 bis 64,64 zeichne sieht die Ausgabe so aus, wie ich es im beiliegenden Bild gezeichnet habe, jede zweite Zeile wird
nicht unbedingt notwendig. Ich versuche das demnächst auf einem ARM, da dieser billiger ist als ein AVR mit viel SRAM und da dieser ein 16bit SPI Interface mit 8 Word FIFO hat, was erlaubt 128Pixel auf einmal zu schreiben (nennt sich SSP Interface). Pro Zeile muss der uC also nur 4x Werte nachliefern
89* sind keine AVR :) In diesen komischen Leih-Fahrrädern von der DB oder wo die her sind ist nen AVR drin. Den hat der CCC glaub geknackt :)
Also in Epson C64/C66 Originalpatronen sind Nacktchips - was für welche - unbekannt. In JetTec für den gleichen Drucker sind SOIC8-Chips, definitiv keine AVRs, da sie nicht auf RESET reagieren, wie ein AVR reagieren würde
an. Schieberegister läuft an einem Mega16 mit SPI eingeschaltet. Wenn ich nun den SPI Takt auf Fsys/128 stelle bei 16Mhz. dann hätte ich doch quasi 16000000/128=125000 Clocktakt. Bei 8Bits entspräche das 125000/8=15625 Hz Strobetakt. 1/15625Hz = 64uS. Heißt es jetzt, dass wenn das Display 40uS für
oder vielleicht sogar jemand mal drüberlesen möchte :-). Bin ja noch nicht so der Profi in gcc für AVR.
