Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > Hallo Günni, > > > nachdem wieder was von Dir zu lesen ist, möchte ich mal meine neueren Erfahrungen mit diversen > > swcom-Problemen aus dem neuen V1.4 Modul melden: > > > > 1.) die neue receive Funktion hat bei mir Probleme verursacht. Und zwar wollte ich 32 Byte lange > > Datenpakete empfangen. Diese waren jedoch nur ca. 1/3 gefüllt, dann hat die Funktion schon > > gemeldet, dass alle Bytes empfangen sind. > > Seltsam. So etwas kann eigentlich nicht vorkommen, da swcom und hwcom identische Routinen > benutzen. Das Problem müsste dann bei beiden auftreten. > Hier der betreffende Ausschnitt des Systemtreibers sys0002.asm: > <asm> > ;****************************************************** > ;hwcom.c2 & swcom.c2 > ;****************************************************** > comget proc near > ; uses R1, R2, R3, R4, R6, R8, R12, R13, R14, R15 > ;R12=0 :hwcom. R12=0x36 :swcom > MOV R13, #0F938h > ADD R13, R12 > MOV R14, R13 > ADD R14 ,#02Ah > MOV R1 ,[R14] > JMPR cc_Z, hw_1 ; jmp if no Data > MOV R15, R13 > ADD R15, #028h > MOV R8, [R15] > MOV R1, [R13+#020h] > MOV R2, [R13+#022h] > MOV R3, R8 > ADD R8, #1 > ADD R1, R3 > EXTS R2, #1 > MOVB RL6, [R1] > MOV R1, [R13+#024h] > EXTS #0, #1 > MOV 0FE0Eh, R8 > DIVU R1 > EXTS #0, #1 > MOV R8, 0FE0Ch > MOV [R15], R8 > MOV R13, [R14] > SUB R13, #1 > MOV [R14], R13 > CMP R12, #0 > JMPR cc_NZ, hw_2 > BCLR CLKOUT ; RTSenable = true > hw_2: > MOVB RL1, RL6 > JMPR cc_UC, hw_3 > hw_1: > MOVB RL1, #0 > hw_3: > RETN > comget endp > > comsrec proc near > _13: > EXTS #0, #1 > MOV R14, 0F962h > ADD R14 ,R12 > CMP R14, #0 > JMPR cc_EQ, _12 > > CMPD1 R5 ,#0 > JMPR cc_Z,_14 > > CALLR comget > > EXTS #8 ,#1 > MOVB [R7], RL1 > ADD R7, #1 > JMPR cc_UC, _13 > _14: > ADD R5, #1 > _12: > MOV R12, R5 > CALLS OSsegment,PUSH_R12 > RETN > comsrec endp > > hwrec proc far > CALLR comdta > MOV R12,#0 > CALLR comsrec > POP R1 > POP R1 > RETS > hwrec endp > > hwreca proc far > CALLR comadta > MOV R12,#0 > CALLR comsrec > POP R1 > POP R1 > RETS > hwreca endp > > swrec proc far > CALLR comdta > MOV R12,#036h > CALLR comsrec > POP R1 > POP R1 > RETS > swrec endp > > swreca proc far > CALLR comadta > MOV R12,#036h > CALLR comsrec > POP R1 > POP R1 > RETS > swreca endp > > comdta proc near > CALLS OSsegment,POP_R4 ; Length > MOV R5,R4 > CALLS OSsegment,POP_R4 ; Data-Buffer > MOV R7,R4 > RETN > comdta endp > > comadta proc near > CALLS OSsegment,POP_R4 ; Length > MOV R10,R4 > CALLS OSsegment,POP_R4 ; Data-Buffer / String > ADD R10,R4 > CALLS OSsegment,POP_R4 ; Pos > MOV R5,R4 > SUB R10,R4 > MOV R7,R10 > RETN > comadta endp > </asm> > > Da aber swcom rein softwareemuliert ist (aber Interruptgesteuert) kann aber > evtl. das Timing etwas darunter leiden. Auch hat swcom fast immer eine Baudratenabweichung. > Wenn ich etwas Zeit habe, werde ich das etwas näher untersuchen. > > > 2.) flush() löscht scheinbar auch den Sende-Buffer oder stört ihn zumindest. Kannst Du das mal im OS > > verifizieren? > > Hmm. Das konnte ich bisher nicht beobachten. > Das könnte aber evtl. auch ein Timing-Problem sein. > Wie äußert sich dieses Problem denn genau ? > Denn, einen Sendepuffer gibt es weder bei hwcom noch bei swcom. > Es gibt nur ein "Sendebyte", welches entweder per put() oder per send() > (und davon abhängige Funktionen) gefüllt wird. > Bei send() wird der übergebene Datenrahmen einfach als Datenpuffer verwendet und > Byte für Byte in das "Sendebyte" kopiert. Dies geschieht Interruptgesteuert im Hintergrund. > > MfG André H.