| Ich nutze: C-Control II Unit, C164CI-ControllerBoard, CC2-Application-Board, CC2-StarterBoard, CC2-ReglerBoard, OSOPT V3.0 |
> 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:
;******************************************************
;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
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.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: swcom (von Günni - 27.08.2005 10:27)Re: swcom (von André H. - 29.08.2005 13:33)