-
Thread
Longwert: Bits vertauschen LSB zu MSB
Auf einen Rutsch wohl blöd zu machen. In einzelnen Byte besser. Ein Byte drehen: [c]unsigned char umkehr(unsigned char n){ n=((n>>1)&0x55)|((n<<1)&0xaa); n=((n>>2)&0x33)|((n<<2)&0xcc); return (n>>4)|(n<<4); } [/c] Byte 1 mit 4 und 2 mit 3 tauschen
[1] mit dem ersten Byte. Danach füllt er den Buffer an der stelle [2] mit dem nächsten Byte... Wenn ich die Daten für eine effiziente Verarbeitung mit 32-Bit-Variablen verarbeiten will krieg ich ein riisen Problem wegen
-
Thread
Bascom GETKBD Routine ändern
dran und jetzt ist sie verkehrt herum, d.h. von PB7 bis PB0? Wenn das so ist, dann mußt Du das Byte, in das GETKBD seine Werte hinein- schmeißt, umdrehen. Dim Erwin as Byte Dim Erwin_umgedreht as Byte Erwin=Getkbd() Erwin_umgedreht.0 = Erwin.7 Erwin_umgedreht.1 = Erwin.6 . . . Erwin_umgedreht
riesen Problem wäre da ne kleine Funktion dazwischen zu klabustern ... funktion get_keyboard () as byte local z as byte local y as byte Portx =0 portx.4 = 1 z=pinx and &B11101111 y=0 if z=0 portx.4 = 0 portx.5 = 1 z=pinx and &B11011111 y=1 endif if z=0 portx.5 = 0 portx.6 = 1 z=pinx
-
Thread
8086 Beschaltung Speicherlogik (BHA A0 MR MW)
selbst ist wie folgt angeschlossen: [A1...A19] -> [A0...A18] [D0...D7] -> [D0...D7] IC1 lower Byte [D0...D7} -> [D8...D15] IC2 upper Byte Da ich den ROM in den RAM kopieren möchte, sitzt noch ein ATMega64 daneben mit folgendem Aufbau und Funktion: Alle Datenleitungen und Adressleitungen
Intel-16Bit-Architektur wählt beim Schreibzugriff A0(machmal auch als BLE bezeichnet) das gerade Byte, BHE das ungerade Byte aus, beim Lesezugriff sind beide Signale aktiv, das unerwünschte Byte wird ignoriert. Wohin diese Zugriffe gehen (Mem oder IO), wird im Minimum-Modus durch das Signal M/IO der
-
Thread
CRC16 - CCITT
Idee, was ich falsch mache? [pre] dim w as word dim txt_5_st as string[5] const crcblock as byte[100] = (48, 49, 50, 51) 'hier testweise "0123" als ASCII sub function CRC16_CCITT(dim byref localcrcblock as byte[100], dim startbyte as byte, dim endbyte as word) as word dim j, lsb as Byte dim
Frank schrieb im Beitrag #4983215: > Steck mal nur 1 Byte rein. Eigentlich sollte man sogar mit 0 Byte anfangen, um Startwert und Endbehandlung zu prüfen. Und dann bei 1 Byte zuerst mit 0 anfangen. Wenn das klappt, dann z.B. mit 0x01. Wenn das *nicht
-
Thread
von ELF nach flashbarem Format mit objcopy
der Flash bei 0x08000000 zu finden. Manche wie der STM32 können den zusätzlich an die 0-Adresse spiegeln je nach Einstellung der BOOT*-Pins und des SYSCFG Registers. An 0x08000000 zu flashen/lesen ist aber der sichere Weg, weil der Flash dort immer zu finden ist. J. V. schrieb im Beitrag #4943662:
12 Source lines: 9528 Object File ".\out.elf" successfully processed Used memory: 2352 kByte, Used disk space: 7 kByte
-
Thread
Problem mit Werteübergabe zu miener Funktion
for(i = 0; i < length; i++) // Die Schiebeoperationen der for-Schleife dienen zum Spiegeln der zu übertragenen Zeichen { // D7..D0 -> D0..D7 tByte = *(c + i); lByte = ((tByte & 0x01) << 7) | ((tByte & 0x02) << 5) | ((tByte & 0x04) << 3) | ((tByte & 0x08) << 1); hByte = ((tByte & 0x10) << 3) | ((tByte & 0x20) << 1) | ((tByte & 0x40) >> 1) |
-
Thread
EEPROM schreiben lesen
TIMSK0 2. Sind es zu viele Werte für den Speicher. (Nur die Hälfte der Sinuswerte nehmen und spiegeln!) Idee zum EEPROM: [c] OCR0A = eeprom_read_byte(counter); [/c] Setzt vorraus das die Sinuswerte ab 0x00h im EEPROM liegen, allerdings ist dieser NICHT schnell genug um die Daten in der
bytes (64.1% Full) (.data + .bss + .noinit)
-
Thread
Digitales Speicheroszilloskop UT 4042 C (z.B. von Reichelt)
nacheinander ein (Header noch nicht benutzt). Viel Spaß damit, Thomas REM file header 20 bytes REM byte1..byte6: 0xAA, 0x55, 0x00, 0x01, 0x00, 0x00 REM byte7: 0x00 = CH1, 0x01 = CH2 REM byte8: 0x00..0xA0 = y/DIV in steps, see switch-case below REM byte9: 0x00..0xFA = y-offset 0..250
= 100x, 0x03 = 1000x REM byte5..byte6: 0x00, 0x00 (unknown) REM byte7: 0x00 = CH1, 0x01 = CH2 REM byte8: 0x00..0xA0 = y/DIV in steps, see switch-case below REM byte9: 0x00..0xFA = y-offset 0..250 pixels REM y-resolution
-
Thread
KIM-1 in AVR?
Umgebung aussieht und wie die Taktung der 65xx genau aussieht. Wird da pro Takt/Doppeltakt nur 1 Byte gelesen? Das würde ja bedeuten, daß man nach Lesen des Opcodes auf diesem sitzt und erst wenn man mit Byte 2 bzw. 3 die Operanden gelesen hat die Auswertung machen kann. Das Hauptproblem dürfte
die obersten drei Bit (A15, A14, A13) zu ignorieren. So dass sich RAM, ROM und IO einfach 8 mal spiegeln im Adressbereich.
-
Thread
AVR und Modem Problem
her, um die Ausgabe ans Modem zu überprüfen. Gibt es denn keienn Trick wie man so eine Verbindung spiegeln kann, sodass ich mir den Datenfluss im Terminal angucken kann? Erstmal Danke für eure Hilfe ich werde gucken, das ich die get_str Funktion abändern werde das sie stabieler läuft. Bin offen
f95 schrieb im Beitrag #2830037: > Gibt es denn keinen Trick wie man so eine Verbindung > spiegeln kann, sodass ich mir den Datenfluss im Terminal angucken kann? Häng dich an die Leitungen zum Modem. Entweder vollduplex, dann brauchst du zwei weitere serielle Ports. Oder nutze den Umstand
-
Thread
ItoA mit Uint64_t
Wenn du den String so spiegelst [c] // den String in sich spiegeln Buffer[i--] = '\0'; for( j = 0; j < i ; j++, i-- ) { Buffer[j] ^= Buffer[i]; Buffer[i] ^= Buffer[j]; Buffer[j] ^= Buffer[i]; } [/c] sparst du dir die extra tmp variable. Das ist
Allerdings sind die Routinen nicht für jedermann geeignet, das sie wegen > der LookUp-Tabelle 200 Byte RAM zusätzlich verbrauchen. > Macht es Sinn die LookUp-Tabelle im Pgm-Space zu halten?
-
Thread
Bit-Reihenfolge bei Big/Little Endian
Motorola-Format (Big Endian) und der ARM nach dem Intel-Format (Little Endian). Das ich hier die Byte-Reihenfolge spiegeln muss, damit ein Long richtig auf der gegenüberliegenden Seite erkannt werden kann ist damit klar. Die Frage die ich mir allerdings stelle ist, ob auch die Bits im Byte gespiegelt
Der Endian bezieht sich nur auf die Abspeicherungsreihenfolge der Bytes, also Bits bleiben wiese sind.
-
Thread
Stacktiefe AVR-Controller
Das ist aber kein rcall mit Offset 0, sondern mit Offset -2 oder -1, je nachdem, ob du es lieber byte- oder wortweise betrachtest.
ausgeben und die liegt bei 0x10AC. Das dürfte weit genug weg sein von den statischen Variablen, die 2831 Bytes umfassen. Der RAM hat 4096 Bytes (644P). Es ist auch insofern verblüffend, dass meine printf-Funktion genau so aussieht, nur dass die Ausgabefunktion eine andere ist. Diese Funktion macht aber keinen
-
Thread
allgemeine PicoMite Anfängerfragen
Die Adresse hat 7 Bit und das R/W Flag ist eine anderer Parameter. Das sollte jede API so wieder spiegeln.
reset LCD_Nibble(0b0010, 0, 2000); // 4 bit mode LCD_Byte(0b00101100, 0, 600); // 4 bits, 2 lines LCD_Byte(0b00001100, 0, 600); // display on, no cursor LCD_Byte(0b00000110, 0, 600
-
Thread
Ist es möglich, etwas wie EEMEM und PROGMEM für externe RAM?
Anfang 90-er C51 in Maschinencode ohne Computer gemacht: so bequem für Menschen ist Befehlssatz. Byte für Operation, Byte oder zwei für Daten oder Adressen. Mit AVR kann das schon kaum mehr gehen: Bits von Befehl und Daten sind eigenartig durcheinander. Ohne Flasche Schnaps versteht man hier mit Code
8051 hätte man externen XRAM Das gibt es auch bei manchen AVR. Wie bei ATMega8515 (wenn man nur 512 bytes RAM hat, dann ist externe RAM schon eine Notwendigkeit!), so auch bei ATmega128A und ATMega2560.
-
Thread
externer serieller EEPROM/C
Das 2404 hat doch nur 512 Byte, richtig? Ich benutze zur Zeit ein EEPROM mit 10.000.000 Schreib- Löschzyklen. Wenn du so ein Teil nimmst, die Zugriffe mitprotokollierst, müstest du fertig sein. Der Typ heißt 24LC65 von Mikrochip.
12 Produktionslinien, die du überwachen willst. Also, angenommen 12 x unsigned long, entspricht 48 Byte. Nach 100 Tagen wechselst du auf den nächsten 48'er Block. So bekommst du in den High-Endurance Block 10 x 48 Byte, also 10 x 115 Tage. Danach stehen dir noch 7,5KByte mit 1.000.000 Schreib- Löschzyklen
-
Thread
Arduino Timerprobleme - suche programmierbaren Oszillator
werden. ?!? Es gibt pro Zeile *ein* interessantes Bit, und das ist bit7 (MSB) des höchstwertigen Bytes byte3 des jeweiligen Phasenakkumulators t_. (ich hätte ihn anderes benennen sollen, pa_ oder a_). Und das wird nicht ausmaskiert, sondern ausgewertet.
Link für alle. Bei Bedarf. :-) https://stackoverflow.com/questions/61179846/reversing-bits-in-a-byte-with-avr Kennt ihr bestimmt schon.
-
Thread
Prinzip grafische darstellung/diagramme etc
es richtig, das ein Integer in der Regel mehr als ein Bit umfasst. Ob Du nun aber ein Integer, ein Byte oder was auch immer nimmst hängt vom konkreten Display ab. Bei monochromen Displays wird in der Regel ein Byte mehrere Pixel kodieren. Ob aber nun ein Byte vertikal oder horizontal angeordneten
letztgenannte Funktion *schnell* sein muß. Deswegen wird man da kaum komplexe Transformationen wie das Spiegeln eines Bytes o.ä. drin machen wollen. > Als nächstes würde ich ja mit entsprechenden Funktionen etc. in diese > Array das Bild aufbauen. und dann würde ich jeden einzelnen Pixel ans > LCD senden
-
Thread
STM32 und 11x74HC595.
RCLK_Pin, GPIO_PIN_RESET); } void HC595writePin(uint8_t pin, uint8_t value) { int bit, byte; byte = pin / 8; bit = pin % 8; if (value == 0) { LEDdata[byte] &= ~(1 << bit); } else { LEDdata[byte] |= (1 << bit); } HC595write(
Bitmanipulation müsste ich doch eigentlich das gedreht > bekommen? Jain, man muss die Adressierung der Bytes auch spiegeln. > Wenn ich meine for-schleife nun aufif(data & (1>> j)) > > funktionierts leider nicht, Logisch. > eigentlich muss ich doch die 1 in die andere > Richtung schieben mit
-
Thread
Zahl umdrehen?
)>>2 | (b & 0x33)<<2; b = (b & 0xaa)>>1 | (b & 0x55)<<1; } void foo(void) { BYTE *pIn = (BYTE*) &DeineZahlIn; BYTE *pOut = (BYTE*) &DeineZahlOut + sizeof(DeineZahlIn); BYTE *pInEnd= pIn + sizeof(DeineZahlIn); do {*--pOut = revBYTE(*pIn++);} while(pIn <
hier, > Goodies da - nur dann muss man die Hardware kennen Mit 16 GPIO kannst Du das einzelne Byte per HW spiegeln. Mit 128 GPIO auch den ganzen Wert.
-
Thread
Pollin LCD Modul 7" Touch-monitor FT700TVGA
senden musst.. Adresse: jain, siehe oben. Data: nur ein Byte, also 0x47. Wenn nicht 0x47, dann 0xB8, das muss man ausprobieren. Das dazu negierte Byte baut IRSND automatisch dazu.
ignoriert, das kann aber auch an meinem "Schnellaufbau" des Senders > gelegen haben. Benutze nur ein Byte für den Code, das dazugehörende invertierte Byte baut IRSND selbst dazu. Also: address = 0x00FF - besteht bei Ext. NEC aus 2 Bytes command = 0xA5 - ist immer nur ein Byte, sowohl bei Std. als
-
Thread
DMX Dimmerpack bauen
'Sla register Uart_temp1 (R18) op in S-Ram variabele Dmx_count_temp STS {Dmx_byte} , Uart_byte 'Sla register Uart_byte (R17) op in S-Ram variabele Dmx_byte RJMP Asm_exit 'Relatieve sprong naar Asm_exit (einde verhaal) Asm_loop1: STS {Dmx_byte} , Uart_byte 'Sla Register Uart_byte (R17) op in S-Ram variabele Dmx_byte Asm_exit: $end Asm [/code] fehlermeldung: beim compilieren:
-
Thread
Displaysteuerung
MHz .equ WaitMS=1550 ;Wartezeit in µ-Sekunden Wait1550uS: ldi r24,low(WaitMS*AVRTakt/4) ;low-Byte der Wartezeit in r24 ldi r25,high(WaitMS*AVRTakt/4) ;high-Byte der Wartezeit in r25 WaituS: sbiw r24,1 ;Wartezeit (r25:r24) - 1 brne WaituS ;Wenn nicht 0 dann nochmal - 1 ret
dass ich meinen Code überdenken muss. Er ist durch die Hardware noch komplizierter, da ich einige Bytes erst spiegeln muss usw. Einen Fehler habe ich schon gefunden. Die Daten lagen in r18 und ich habe versucht die Taktleitung über r16 zu manipulieren. Der tipp mit dem undefinierten Zustand war
-
Thread
Pollin TIAN MA A2C00096100 LCD Modul
digitalWrite(PinRST, LOW); delay(10); Wire.begin(); Wire.beginTransmission(0x74); Wire.write(byte(0x00)); Wire.write(byte(0x20)); Wire.write(byte(0x06)); Wire.write(byte(0x0E)); Wire.write(byte(0x21)); Wire.write(byte(0x04)); Wire.write(byte(0x42)); Wire.write(byte(0x08));
=1µ sein. 100n sind hier eindeutig zu wenig. > Wire.beginTransmission(0x74); > Wire.write(byte(0x00)); > Wire.write(byte(0x20)); > Wire.write(byte(0x06)); > Wire.write(byte(0x0E)); > Wire.write(byte(0x21)); > Wire.write(byte(0x04)); > Wire.write(byte(0x42)); > Wire.write(
-
Thread
Flash-Speicher mit hoher Kapazität?
Der compilierte Code ist gut 8 kByte groß und benötigt mindstens 15 kByte RAM. Da normalerweise bei USB-Sticks 8051er verwendet werden, welche normalerweise 32+32 kByte haben, ist die der Verbrauch akzeptabel. Grüße Michelle
bzw. >ausgelesen wird) Das mag sein, aber trotzdem musst du noch von den 2kB Sektoren auf die 512Byte Sektoren mappen.
-
Thread
Sinusberechnung auf Controller STM32F030
/articles/Festkommaarithmetik Das Programm ist nur noch 540 Bytes lang.
Reinhard M. schrieb: >> cordic-32bit.c > > -> Sinusberechnung > F030 Atollic GCC: > -Os 118 Bytes > -O0 ~180 Bytes Sorry, aber nicht mit der cordic-32bit.c von oben. Da stehen 32 32bit Werte in der Tabelle. Macht 128 Byte. Da würde ich jetzt ins Grübeln kommen...
-
Thread
Hilfe bei #Define
hoffe ihr versteht mich) So eine EEProm Routine sieht so aus: void Write_SPI_EEProm (void){ BYTE HighAdress = 0; BYTE LowAdress = 0; BYTE Daten1 = 0; BYTE Daten2 = 0; BYTE Daten3 = 0; BYTE Daten4 = 0; BYTE Daten5 = 0; BYTE Daten6 = 0; BYTE Daten7 = 0; BYTE Daten8 = 0; //BYTE status =
spiTransferByte(Daten1); //data spiTransferByte(Daten2); //data spiTransferByte(Daten3); //data spiTransferByte(Daten4); //data spiTransferByte(Daten5); //data spiTransferByte(Daten6); //data
-
Thread
CRC16 - Berechnung
hi, die beiden crc16 bytes sollten anfangs 0ffh sein. ed
rcswww.urz.tu-dresden.de/~sr21/crc.html bei meinen problem mußte ich die eingangsbytes und die end-crc spiegeln, nur dann hats gestimmt.
-
Thread
Binäre Zahl drehen
Also 7->0 6->1 usw. Am schnellsten geht das mit einer Look-Up-Tabelle. Das kostet allerdings 256 Byte Flash. Ansonsten hat hier im Forum mal jemand einen passenden Code gepostet. Einfach mal nach Bit und spiegeln suchen. Matthias
Befehle*, um zwei Nibbles zu vertauschen. Damit kann man die Größe der Lookup-Table deutlich (auf 16 Bytes) reduzieren. Also: 7654 3210 Lookuptable auf untere vier Bit anwenden 7654 0123 Nibbles tauschen 0123 7654 Lookup-Table auf untere vier Bit anwenden 0123 4567 Das sollte
-
Thread
MC 6809 Adressbereich
Er meint mit kb vermutlich Kilobit, also 32kByte ERPOM, 8kByte RAM, PIO und CRTC, und richtig, da der 6809 seinen RESET-Vecor bei 0xFFFE holt, sollte dort ROM sein. Dann kann man aber die anderen Vektoren auch nicht mehr ändern. Also kann es auch
Stelle ins RAM leiten. Dort landet ein Sprungbefehl und die Sache hat sich. Deshalb irgendwie zu spiegeln oder zu tricksen lohnt nicht.
-
Thread
Polyphasen-Frequenzumrichter mit ARM
phasen sind eh immer 2 gleich also einfach den Interrupt der PWM abfangen (wenn vorhanden) und dann Spiegeln das eigentliche prob sind dann eher noch die EMV sachen und natürlich die MOSFET Treiber. Naja 9000 Einträge wären bei 8bit 9000byte (bei 16 bit 18 000byte) ob sich das wohl ausgeht beim LPC
-
Thread
Thermoducker - Density einstellen
eigentlich schon die String-Terminierung diskutiert? Wer redet denn von Strings? Wir sind bei einzelnen Bytes.
Material zu testen. (Was übrigens sehr erfolgreich war) Man könnte vielleicht mit rotierenden Spiegeln und Timing einen thermalen Laser Vektorplotter oder Pixeldrucker bauen... Gruß, Gerhard
-
Thread
Register umkehren
Soll es zügig gehen und stehen 256 Byte Festspeicher dafür zur Verfügung, bietet sich ein Table-Lookup in eine Tabelle mit "rückwärts bestückten" Bits an.
***************************************** ;* ;* mirror_fast 26 Takte (mit call/ret) / 36 Byte ;* ;* Spiegeln r16 ;* ;**************************************************************************************** .if use_mirror_fast mirror_fast: push r17
-
Thread
8Bit -DAC Für 2 sinusförmige Frequenzen Tabelle berechnen
erzeugen kann, geht es an die Details. Ich muß ja nun 2 Tabellen entwerfen, in denen ich jeweils die Bytes für die Ansteuerung des DAC ablege. Ich zerlege also meinen Sinus in kleine "delta" t. Für jedes "delta" t ist nun der zugehörige y Wert auszurechnen, wobei Zeiger senkrecht nach oben =1 (volle Ausgangsspannung Vmax). Zeiger waagerecht nach unten =0 (Ausgangspannung =0V). Auf die Bytes übertragen bedeutet =1, dann 11111111b und =0 dann 00000000b . Das war ja einfach. Jetzt muß ich die Zwischenwerte berechnene. Annahme: Bei t = 0,04ms beträgt der y-Wert vom Sinus 0,36 Bei einem
-
Thread
Wie programmiert man Grafiken "richtig" in C
Farben auf Papier > malst siehst du es vielleicht. Karriertes Papier nehmen und für jede 1 im Byte das Kästchen ausmalen. Links anfangen Bit 0, rechts Bit 7 Nächstes Byte genauso darunter. Und dann drehen und spiegeln bis ein Zeichen erkennbar ist. Nicht mit dem Leerzeichen anfangen.
#6692623: > Da bleiben aber immer noch mindestens zwei mögliche Lösungen über: > Es können entweder 5 Bytes sein, die je sieben Nutzbits enthalten oder > aber 7 Bytes, die je 5 Nutzbits enthalten. Tatsächlich sind es 3..4 mögliche Lösungen: - 5 Byte, von denen je 7 Bit genutzt werden - 7 Byte, von
-
Thread
Frequenz eines Feuchtigkeits Sensors messen
0) {}; // Do nothing until data have been received and is ready to be read from UDR ReceivedByte = UDR0; // Fetch the received byte value into the variable "ByteReceived" ReceivedByte = calculate_freq(); while ((UCSR0A & (1 << UDRE0)) == 0) {}; // Do nothing until UDR is ready for more data to be written to it UDR0 = ReceivedByte; // Echo back the received byte back to the computer } } [c]
-
Thread
ILI9320 landscape
j=0; j<f_width; j++ ){... festgelegt. Durch ändern der Laufrichtung dieser Schleifen kann man spiegeln oder drehen. Bildschirm im Querformat: //============================================= void PutChar( uint8_t ASCI) { uint16_t i, j; uint16_t tmp_char; //Fontheader auswerten //f_width= pgm_read_byte( &ptr_font[2]); //f_height=pgm_read_byte( &ptr_font[3]); //frame =pgm_read_byte( &ptr_font[4]); //vertikal_zeichnen=pgm_read_byte( &ptr_font[5]); //if (frame==1){f_width++;f_height+=2;} if(
-
Thread
OV9655 Kamera hat nur Blautöne
LA und besserem Oszi, als ich hier habe) > Ist deine Beschaltung richtig? > Ist die Cam auf 2byte RGB-565 eingestellt(Register)? Es gibt nur 2-Byte Modi (RGB555, RGB565...) > Bei mehr als 2 DMA-Streams hat der STM32F4xx Probleme. z.B.: > DMA -OV-Cam; > DMA-Display; > plus > DMA-SD Karte
, wenn die Bytes vertauscht sind. Momentan habe ich nur ein paar Fehler... mhm gaaanz komisch.
-
Thread
Frage zu Bytekonvertierung
an P5, ... D7 an P0, also gekreuzt. Gibt es eine einfache Berechnung für die "Spiegelung des Bytes", wenn ich ein Byte an das LCD schicken will ?
Hat sich erledigt. Ich bin doch noch bei der Suche fündig geworden. Man muss nur nach spiegeln "suchen" :-)
-
Thread
Hexeditor gesucht
problemlos öffnen und bearbeiten. Die Bedienung ist übersichtlich und Funktionen wie Dateivergleich oder Byte-Suche laufen reibungslos.
> Dann ist Deine Erinnerung merkwürdig selektiv. Sie ist halt subjektiv. Ich wollte damit nur spiegeln, was bei den (einem) Rezipienten hängen bleibt. Im Gegensatz zu dem Beitrag hier hast Du oben auf einen konstruktiven Beitrag vom anderen Harald etwas geschrieben, was nicht etwa das (fragwürdige
-
Thread
TTL Pegel 6x4 von Inkrementalmessystem Verarbeiten und mit XMega auswerten
bischen recheschiert und herausgefunden was ich brauche, es klappt jedoch nicht! Ich muss also 3 Bytes nacheinander auslesen und diese dann in ein uint32_t zusammenfügen. Danach muss ich ja den Wert einmal spiegeln und dann ist er theoretisch fertig. Hier mein Code: [c] /* * ATXmega16A4_AU.c
//data um 8 Bits nach links schieben data |= SPIC.DATA; //hänge ein Byte aus dem Daten-Register rechts an data an data <<= 8; //data um 8 Bits nach links schieben data |= SPIC.DATA; //hänge ein Byte aus dem Daten-Register rechts an data an return
-
Thread
ADC für Oszilloskop gesucht
Ansprüche sind kann man natürlich darüber nachdenken die Eingangsspannung in den Positiven Bereich zu spiegeln und dann einen heute üblichen Typ zu nehmen. Die notwendigen Spannungen sind ja alle da! Wenn es in erster Linie um digitale Signale geht ist das ja überhaupt kein Thema. Wenn man dann dem Ergebniss
RAM sind. Mit ADCs sehe ich nur noch Zufall - der sich nach ein paar Minuten bis halben Stunde Byte für Byte einer Geraden nähert. Deshalb die Idee mit den ADCs. Ich könnte auch mal die Ausgänge bei gezogenen ADCs mit einem Rechteck speisen, das müsste man ja dann sehen können wenn dahinter alles
-
Thread
Stabilitätsproblem oder Verständnisproblem bei Timer (PWM) ATmega88
Werte zwischen 0..255 annehmen. Macht 1 BYTE/PWM-Zyklus. >Siehst du, Sache nicht verstanden. Vielleicht habe ich auch zuviel von >dir erwartet. Du bist ja ein ganz Schlauer. Wie alt bist du? 12 1/2? > Wenn du nun rückwärts rechnest und
Bit Wert aus, denn deine PWM kann > ja wahrscheinlich Werte zwischen 0..255 annehmen. Macht 1 > BYTE/PWM-Zyklus. NÖ Meine PWM nimmt 64 Werte an (6 Bit: 0...63) Aber ich habe mich unglücklich ausgedrückt: Ich schrieb: >Meine 500Hz sind ein Sinus mit 128 Bit/Periode macht 15,625µs pro Bit.
-
Thread
Mini-Farbdisplay (+mehr) für 1 Euro
(die ersten 70 Byte) und kannst die restlichen Bytes 1:1 an das Display schicken
Genau, ich bastel mir aus dem einen Byte die passenden Bytes für das Display. Das mach ich nur, um Speicher zu sparen.
-
Thread
Uart/Itoa-Problem
#3990197: > volatile int rssi_array[500] = {0}; Das geht auf einem Controller, der gerade mal 1024 Bytes RAM hat, ziemlich gnadenlos in die Hose.
Nicht das "volatile" führt zum Fehler, sondern Dein durch Dein 1000 Byte großes Array plattgemachter Stack.
-
Thread
CP/M auf ATmega88
Zeichen + evtl. benötigte "Meta" Codes (Alt, Shift usw.) finde ich sehr > Hilfreich. OK. 20 Bytes benötigt - 400 Bytes SRAM frei 20 Bytes benötigt - 400 Bytes SRAM frei was sagt uns das? > Die visuelle Ausgabe, per FBAS, VGA or whatever, braucht dagegen schon > einige Bytes an Ram... Der
Über 5K belegen bei mir schon allein die Sprungtabellen: Ohne Prefix: 512 Bytes CB Prefix : 512 Bytes ED Prefix: 512 Bytes DD Prefix: 1024 Bytes DD CB Prefix: 1024 Bytes FD Prefix: 1024 Bytes FD CB Prefix: 1024 Bytes Was viel gegenüber meiner
-
Thread
LED_Laufschrift mit Mega 32 und MAX 7219
das kannst du in dem Font Creator machen und musst das nur spiegeln, wenn du die Zeichen mit dem Font Creator erstellst.
nein Hanns, das funktioniert nicht. Jeder 7219 beinhaltet ein 16Bit Schieberegister. Das High-Byte stellt die Adresse dar und das Low-Byte das Datum. Davon 3 hintereinander geschaltet ergeben 48 Bit, die in einem Rutsch reingeschoben werden müssen. Die Datenübergabe an die 7219 funktioniert folgendermaßen
-
Thread
Bauen oder nicht bauen ?
Detailspeicher an > Adresse 00000000000 - der Pixelzähler ist ja ein Teil der Adresse. Rechnest du in Bytes oder in Worten? In der "normalen" Darstellung listet man 16 Bit-Worte so: [pre] Byte [ Byte 01 | Byte 00 ] Bit [ 15 14 13 12 11 10 09 08 | 07 06 05 04 03 02
weil es möglicherweise gespiegelt ist - der Pixel_X-Zähler zählt ja vom höchsten Bit des (zweiten ?) Bytes abwärts. Das muss ich nochmal durchspielen - möglicherweise muss man da heftig Bitpaare spiegeln, um den richtigen Wert in das RAM zu schreiben.