-
Thread
Nokia 6100 Grafiklibrary die Zweite
enthält also nach ihrer Fertigstellung 256 Werte a 12Bit. Der Vorteil dabei liegt daran das man nur sehr wenige Daten an das Display senden muß, der Nachteil ist aber der Fakt das man nicht frei und beliebig ALLE 256 Werte der internen Tabelle
Hier mal eine 256 FontEditor Version. Einzigstes "Manko" ist die Auswahl der Farbe in der Farbpalette. Man muß halt umständlich scrollen. Du musst dann aber testen ob die GLCD Fontroutinen mit 256 Farben noch sauber
-
Thread
pwm auf tiny26 - hilfääää
Minimale puls Zeit von: 30µS Und Maximale Puls Zeit von: 3,9mS. Die Pause beträgt ca. 20mS. 3,9mS/256~ 15µS Schritt. Wie ich feststellen musste sprichst du eine andere Sprache(irgendein Basic?), bei mir is es only ASM. Wenn’s dich trotzdem interessiert, dann kann ich dir mein PAP oder auch den
die ich mit 1024 analogwerten synkronisieren kann is nicht gerade toll mit dem µC mit einen hc4001BF bekommme ich über poti immerhin annalog 220 hin is halt analog deswegen die diskusion um ein Prezidensfall programm für die timer 8bit danke erst mal für die vielen tollen antworten
-
Thread
pic das forum Gesperrt
und auf den man Werte mit nur einem Befehl abspeichern kann. Es gibt zwar immer noch RAM-Bänke zu je 256 Byte aber die meisten Register lassen sich direkt ansprechen. Um das Banking muss man sich da nicht mehr unbedingt den Kopf zerbrechen (wenn man ordentlich programmiert). Der direkt adressierbare
SSPBUF, w ; schreibt den Inhalt den Empfangs-Buffers in das Arbeitsregister ; btfsc SSPSTAT, BF ; gleiche Testsubtraktion nochmals; BF = Buffer Flag (Empfangs-Buffer ist voll) ; movwf PORTB ; empfangenes Byte auf PORTB schreiben btfsc PIR1, SSPIF ; synchronous serial
-
Thread
frage zu rjmp beim GCC/ATmega162
cf ef ldi r28, 0xFF ; 255 b4: d4 e0 ldi r29, 0x04 ; 4 b6: de bf out 0x3e, r29 ; 62 b8: cd bf out 0x3d, r28 ; 61 PA5_TOG; ba: dd 9b sbis 0x1b, 5 ; 27 bc: dd 9a sbi 0x1b, 5 ; 27 be: fb
Pin-Toggle anwenden? Der GCC macht aus PORTA^=1<<5; 254: 8b b3 in r24, 0x1b ; 27 256: 90 e2 ldi r25, 0x20 ; 32 258: 89 27 eor r24, r25 25a: 8b bb out 0x1b, r24 ; 27 was mindestens genauso schnell ist wie deine Lösung. BTW: Bei deinem Ansatz
-
Thread
CRC-16 Prüfsumme (serielle Übertragung)
So gehts auch: int crc16_table[256] = { 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e
now we have got our overall 2-byte CRC "Checksum" number return new byte[2] { (byte) ( Register / 256 ), (byte) ( Register % 256 ) }; } // end of CRC16S Method
-
Thread
Programmierbeispiele
Z. als ' ' oder '#': erstmal Ende dec temp2 brne bf10 ;wenn noch nicht alle 16Z. rückwärts bfret: ret ;Am Ende der Eingabe stand ein #, jetzt suchen, ob diese Ziffernkette exist. bf40: ldi r30,low(beftab*2) ldi r31,high(beftab*2) bf42: mov
,'#' breq bfound ;Vergleich stimmt ld temp3,z+ ;Pointer+1 dec temp2 brne bf41 ;noch nicht Ende der Z.-Kette bf44: lpm ld temp1,z+ mov temp3,r0 cpi temp3,'#' brne bf44 ;# n. gefu. ld temp1,z+ ld temp1,z+ lpm mov temp3,r0 cpi temp3,0xff