LPC2103 UART interrupt

[rand_althor]

Jag sitter med ett litet problem rörande interrupt på UART på NXP LPC2103...

Problemet är sådant att jag har en bakgrundsprocess som pollar ut data ur UARTens RX FIFO. Detta fungerar bra, och Line Status-koder kan jag använda för att detektera reset-sekvenser i form av break, framing error, osv. MEN då till mitt problem:
Jag behöver få till ett interrupt som sker när något Line Status-fel uppstår. T.ex när break kommer som resetsekvens. Jag enablade då RX Line Status interrupt och hanterar detta interrupt. Detta fungerar bra. Men problemet är att när en break tages emot så genererar inte det interrupt direkt, utan först när man läst ut alla databytes som låg i FIFOn sedan tidigare, dvs först när breaken ligger överst i FIFOn genereras interruptet på detta.

Någon som vet hur man löser det?

[Icecap]

Man låter bli att polla och kör det hela i interrupten. Och du skriver "Detta fungerar bra." men det är väl fel eller hur? Hade det fungerat bra behövde du inte att ha detta problem.

Att du sedan kan blanda main-loop och ISR är en annan sak: jag har "alltid" ISR som tar emot och lägger inkommande bytes i en buffer, när sedan mitt stopp-tecken detekteras av ISR behandlas de data så till vidare att ISR'n i viss mån kollar om det är giltiga data (kanske kollar längden på inkommande meddelanden eller så) och sedan sätter jag en flagga som jag oftast kallar "Valid_Block".

Denna flagga sätts till ett värde som ger kanske 500ms och räknas ner i en timer-ISR om den är större än noll.

Samtidig kollar main-loopen om den flagga är större än noll, är den det körs rutinen som tolkar och utför order och flaggan nollas efteråt. Om den flagga är icke-noll kommer UART-RX ISR'n att kasta bort alla inkommande bytes så länge det är fallet, på det vis kommer det aldrig att ske buffer-overrun, det finns kommunikations-timeout så att den inte fastnar i vinkelvolten och när en mottagen block är klar (kanske konverterat eller så) och inputbuffern kan användas igen är det bara att nolla "Valid_Block", då är det klart.

[rand_althor]

Jag avböjer mig idiotiska kommentarer, så kan de som är intresserade av att hjälpa till svara istället... Jag skrev allrig att allt fungerade bra, jag skrev att en delmångd av det fungerade bra (nämligen det som stod i texten precis före "det fungerar bra"). Sedan lade jag till vad som inte fungerade som jag ville...

Om du inte har något seriösare svar än att "inte polla, gör allt i interrupt" så kan du låta bli att svara överhuvud taget.

[Icecap]

"Jag avböjer mig idiotiska kommentarer"
Bra, samma här.

"...de som är intresserade av att hjälpa till svara..."
Men... du är ju ganska tydligt inte intresserat av fungerande lösningar så varför???

"Om du inte har något seriösare svar..."
Ja, sanningen kan göra ont...

Allvarligt talat: Jag svarade enl. mitt tycke mycket seriöst och jag tycker att du är ganska oförskämt i din attityd men du behöver inte bekymra dig mer, jag ska se till att aldrig svar i dina posteringar, du vet ju ganska tydligt hur du får det att fungera eller hur?

Lycka till, det kan du behöva!

[vfr]

Att föreslå att köra det avbrottsdrivet är i högsta grad ett seriöst svar! Det är så du ska lösa det! Sedan om du inte har vilja/ork/tid att göra det på det sättet så är det givetvis din sak. Men svaret är absolut seriöst! Så låt bli att klanka på Icecap för det! Sedan kan jag till viss del hålla med om din åsyftning på "fungerar bra". Men det är lätt att missa den syftningen och då får den delen en annan innebörd. Så tagga ner lite...

[rand_althor]

"Jag avböjer mig idiotiska kommentarer"
Bra, samma här.

Bra, då är vi överens om något...

"...de som är intresserade av att hjälpa till svara..."
Men... du är ju ganska tydligt inte intresserat av fungerande lösningar så varför???

Det är jag, men återigen tillbaka till det där med idiotiska kommentarer... Detta var också en fullkomigt idiotisk kommentar...

De flesta som har hållt på med embedded-utveckling i några år vet att det finns situationer där interrupt stup i kvarten inte är önskvärt... Detta är ett sådant fall...

Allvarligt talat: Jag svarade enl. mitt tycke mycket seriöst och jag tycker att du är ganska oförskämt i din attityd men du behöver inte bekymra dig mer, jag ska se till att aldrig svar i dina posteringar, du vet ju ganska tydligt hur du får det att fungera eller hur?

Jag kan erkänna att jag inte utryckte att jag gick ifrån det interruptdrivna av ovan nämda anledning. Alltså kan jag köpa att det är ett förslag, men ska man klanka ner på frågeställare så kan man ju iaf i en liten bråkdel av en sekund reflektera över dels hur man formulerar sig, dels om det kanske finns en enledning till varför man vill göra en del pollat och en del interruptdrivet... Gör man på det sättet bör det finnas en anledning, alltså är "kör inte pollat" inget genomtänkt förslag. Sedan köper jag så här i efterhand att jag kunde ha givit mer information om att det fanns en anledning att det kördes pollat... Något som genomsyrar det här forumet är att man förutsätter saker... Om något är otydligt, då är det bättre att fråga... Det gäller överallt i livet... I det här fallet hade det då varit bättre att i så fall fråga "finns det någon anledning till att du inte kör allt avbrottsdrivet?"

Att föreslå att köra det avbrottsdrivet är i högsta grad ett seriöst svar! Det är så du ska lösa det! Sedan om du inte har vilja/ork/tid att göra det på det sättet så är det givetvis din sak. Men svaret är absolut seriöst!

Se ovan ang. att det kan finnas anlednignar till att inte vilka köra allt avbrottsdrivet...

Lycka till, det kan du behöva!

Återigen en otroligt arrogant och korkad kommentar... Det här forumet håller nästan pinsamt låg nivå, tur att det finns seriösare internationella forum där deltagarna inte är ute efter sandlåda enbart.
Men: Nej, det behöver jag inte längre. Mha. folk på lite seriösare forum och ett par snabba frågor med NXPs tech support så har jag löst problemet - och nej lösningen var inte att köra allt i avbrott...

Överlag är det ofta ganska tråkig attityd på forumet, därför har jag länge bara läst och inte varit aktiv på forumet... Och det gäller inte enbart den här tråden, utan majoriteten av trådarna, konstigt nog är det 2-3 personer som oftast står för spydiga, onödiga kommentarer.... Tråkigt att det skall vara så.

[mri]

Era små tjurskallar där! Ni är såå söta!

Ni var inne på olika spår men båda spåren var intressanta för mig. LPC2103 används på jobbet och kommunikation i allmänhet intresserar mig.

rand_althor: Förstår inte helt frågeställningen. Var problemet att framing error och break genererar interruptet vid olika tidpunkter, eller var problemet att interruptet bubblar upp först när motsvarande tecken läses ut från fifon? Jag gissar att du vill tömma fifon omedelbart när break detekteras på linjen...?
Vad var lösningen?

Icecap: Av din beskrivning förstår jag att Valid_Block är en räknare som räknar ner till noll (tar ca 500 ms), och när den är noll är det mottagna blocket inte mera valid. Buffern töms automatiskt efter 500 ms om inte main-loopen plockat ut meddelandet? Vad är nyttan med det?

[Icecap]

mri: Jepp, säkrar att en block inte blir behandlat på ett tidpunkt där den är inaktuell. När en block har blivit mottagit och den flagga sätts nekas all ytterligare mottagning innan blocken är behandlat och utan time-out kan ett mindre programfel låsa kommunikationen helt. Självklart kan man undvara denna time-out funktion om man är säker på att ingen låsning kan ske.

Fördelen med att ha en flagga som indikerar att en block har tagits emot är att man kan behandla kommunikationen i "main-loop" vilket gör att mottagnings-ISR'n inte blir onödigt belastat.

[mri]

En feature som döljer vissa typer av buggar då alltså. Själv försöker jag programmera så att potentiella buggar skall visa sig så tidigt som möjligt.

[Icecap]

Kanske det ... eller en feature som hindrar kommunikationskollaps om kabeln blir ryckt ur ...
Denna feature visade sig mycket användbar när jag stod i Stockholm och tankade ner statistik från "Du kör för fort"-skyltar i regn...