PIC, USART problem *LÖST*

[Stewal]

Har lite problem vid uppstart av PIC.
Om det är ett pc-program som ligger och sänder RS232 data till en MAX232 som sen är kopplad till USART på en PIC 16f886 under uppstart så startar inte PIC´n upp, någonstans stannar den i koden.
Misstänker att det har med ISR att göra.
Om man inte sänder något data under uppstart, fungerar allt.
ISR sparar undan det processorn gör då den går in i ISR, så det bör inte vara felet.

Går det stänga av ISR och slå på den innan loop?

Kan tillägga att det ligger en delay på 5 sek innan "loop" för att vissa text på en display.

[Variosboy]

Nu kommer du snart få ett gäng svar som ber dig om mer information!

Så fundera en gång till på vilket information som kan tänkas behövas för de som vill hjälpa dig!

[jesse]

men du kanske inte ska aktivera interrupt förrän det ska användas? Och även om det är aktiverat tidigt i koden så borde väl rutinen fungera så att den inte sabbar något.

Du kanske behöver posta lite kod?

(har ingen koll på PIC, så det kanske är goddag yxskaft)

[Icecap]

När en µC initieras ska portar ställas först, sedan ska timer + deras interrupt osv. startas. Sist av allt startar man upp kommunikation med omvärlden och man ser till att rensa ut alla "gamla" data i UART-buffer om sånt finns INNAN man slår på interrupten.

[jesse]

>rensa ut alla "gamla" data i UART-buffer. Det gör man väl genom att nollställa flaggor.

[bos]

Går det stänga av ISR och slå på den innan loop?

Ja. Stäng av med GIE = 0 (i INTCON) och på med GIE = 1.

[sodjan]

> >rensa ut alla "gamla" data i UART-buffer. Det gör man väl genom att nollställa flaggor.

Nja, man läser mottagningsregistret tills det är "tomt" (enligt flaggorna).

> Om det är ett pc-program som ligger och sänder RS232 data till en MAX232 som sen är kopplad
> till USART på en PIC 16f886 under uppstart så startar inte PIC´n upp,

Låt bli att göra det då.
Å andra sidan så ska det inte vara något problem, att det beter sig som
du beskriver beror på att du gör fel, helt enkelt.

[blueint]

Låter som:
* Interrupt triggas när den ej borde det? (RS232, IRQ-on-change)
* Programmeringsmekanisk triggas?
* Seriell bootloader triggas?
* Utgång som borde vara ingång eller vice-versa?

Edit: in -> on

[Stewal]

Får börja med att ursäkta att jag inte svarat på era inlägg, men vädrets makter slog till i torsdags. Gjorde mitt inlägg lite hastigt för jag var tvungen att åka iväg till grann ön och jobba, men då kom åskvädret och drog in.
Det kom 50-60 mm regn på 1.5 timme och blixtarna slog ner runt i kring och självklart hade jag inte dragit ut några kontakter ut eluttagen.
Så två bärbara telefoner, två switchar, en router, ett nätverkskort gick åt skogen, men nu har jag fått hem nya grejer och är tillbaka på nätet.
Det värsta var att vägen ner till båtarna försvann i regnet, allt grus låg i vattnet.
Så helgen gick åt att reparera vägen, så nu är den också funktion. Dock är inte min det rygg.

Nog pratat om det.
Då Internet var nere han jag titta lite på koden och varför det inte fungera och hittade självklart lösningen.

Som nämnts i tidigare inlägg, så startade jag kommunikationen innan delayen då texten visas i 5 sek. Så buffern blev antagligen full och något hängde sig. Inte vet jag sökte inte vidare i det utan. startade kommunikationen efter delayen och då var problemet löst.

Tack för alla svar.

[Icecap]

Det som händer är att du nog inte har fel-fångare i din kod.

Om buffern blir "överfylld" flaggas ett fel som sedan ska nollas, samtidig "lyfter" detta fel interruptflaggan men då du inte rensar bort felet kommer den flagga att vara aktiv konstant varför den "låser" i interrupt-rutinen.

Ganska vanligt fel...

Tråkigt med all extrajobb för vädret...

[sodjan]

Exakt, med korrekt hantering av flaggorna för t.ex "overflow" så hade det sannolikt
fungerat helt OK även med första lösningen. Notera det som står i en av de gråa
rutorna i USART kapitlet :

Note: If the receive FIFO is overrun, no additional characters will be received
until the overrun condition is cleared. See Section 12.1.2.5 “Receive Overrun
Error” for more information on overrun errors.

Var det inte just det som hände ?

[Stewal]

Här är den del av koden som ligger i ISR och fångar upp inkommande data.

Kod: Markera allt

datain
		btfsc	RCSTA, OERR
		goto	overerror		; om 'overflow error'...
		btfsc	RCSTA, FERR
		goto	frameerror	; om 'framing error'...
;
uart_gotit
		movf	RCREG, w		; Ta emot data från UART port, spara i w.
		movwf	RX_DATA		; Spara w, i RX_DATA	
		movwf	txreg		; Skicka ut inkommande data till TX
		movwf	rx_data
		goto	done;
overerror
		banksel   RCSTA
		bcf	RCSTA, CREN	; Stäng av pulse cren
		movf	rcreg,w		; Rensa FIFO
		movf	rcreg,w		; är tre steg 
		movf	rcreg,w
		bsf	RCSTA, CREN	; Sätt cren och oerr blir låg.¨
		goto	datain		; försök igen...
;
frameerror 				
		movf	rcreg,w		; Att läsa av RCREG gör att FERR blir låg.
		goto	datain		; Försök igen..
done

>Tråkigt med all extrajobb för vädret...
Det som händer är att du nog inte har fel-fångare i din kod.

Om buffern blir "överfylld" flaggas ett fel som sedan ska nollas, samtidig "lyfter" detta fel interruptflaggan men då du inte rensar bort felet kommer den flagga att vara aktiv konstant varför den "låser" i interrupt-rutinen.

Ganska vanligt fel...

>Tråkigt med all extrajobb för vädret...
Här är en bild på vägen.

[sodjan]

> Här är den del av koden som ligger i ISR och fångar upp inkommande data.

Jaha ? Som den ser ut nu ? Eller förrut (då det hängde sig) ?

Ja, det var ju inte mycket till väg det där...

[Stewal]

>Jaha ? Som den ser ut nu ? Eller förrut (då det hängde sig) ?
ISR koden är inget ändrat, utan följande kod ligger nu efter delayen på 5 sek. Istället för innan.

Kod: Markera allt

	banksel	TXSTA
		bcf	TXSTA, TX9	;Sätt 8 bits sändning		
		bsf	TXSTA, TXEN	;Sätt sändning av data
		bcf	TXSTA, SYNC	;Async kommunikation
		bsf	TXSTA, BRGH	;Hög klock hastighet
	banksel	SPBRG
		movlw	d'25'		;Sätt Baudrate till 2400 eller 9600 beroende på BRGH, SPBRG värde = 25
		movwf	SPBRG
	banksel RCSTA		
		bsf         RCSTA, SPEN	;Sätt mottagning av data
		bcf	RCSTA, RX9	;Sätt 8 bits mottagning
		bsf	RCSTA, CREN	;Sätt konstant motaggning
		bcf	RCSTA, FERR	

[Stewal]

Var det inte just det som hände ?

Problemet var att "något" hände under delayen och texten låg kvar på displayen efter 5 sek. och blev inte släckt av koden efter delayen.