Jätteskumt UART problem

[Virror]

Har ett skumt problem när jag försöker skicka en byte med UART.

Har ett kort som skickar ett antal bytes till min UART, dessa läses in, verifieras att dom är rätt, och sedan skickar jag tillbaka 0x06 för att verifiera att jag tagit emot datat. Problemet är att det andra kortet inte känner av att jag skickar min byte, har testat med flera andra bytes och då känner kortet av trafik på UART, men inte om jag skickar just 0x06. Men om jag skickar det via terminalen på en PC så fungerar det bra. Skumt.

Och ja, jag måste skicka just 0x06 då protokollet säger att det ska vara så.

[sodjan]

Vad är det för "UART" ?
Är det en lös UART eller in inbyggd i en AVR/PIC eller liknande ?

> och sedan skickar jag tillbaka 0x06

Alltså en "ACK" med andra ord (?)

> Men om jag skickar det via terminalen på en PC så fungerar det bra. Skumt.

Alltså skickar till "kortet" eller skickar vartdå ?

Kan du skicka hex '06' från UART'en till "terminalen på en PC" ?

Men annars är det väl som vanligt, bara att testa olika kombinationer
till du hittar "felet"...

[Virror]

Jag skickar från et AT91SAM7XC till nån gammal Fujitsu MB90F546GS µC.

Jo, det är ett ACK

Om jag skickar 0x06 från PC till det andra kortet så fungerar det, men inte om jag skickar från mitt kort. Men det är bara 0x06 som inte fungerar att skicka från mitt kort (har inte testat alla 256 olika, men dom andra jag testat har funkat).

Vet inte riktigt vilka kombinationer du tänker på att jag skall prova?
Måste ju skicka från kort till kort och måste skicka 0x06.

[sodjan]

> Vet inte riktigt vilka kombinationer du tänker på att jag skall prova?

"AT91SAM7XC " => "terminalen på en PC".

Det var väl den kombinationen som saknades, var det inte ?

Helt avgörande här är ju om det är ditt kort som inte *sänder* 0x06
eller om det är det där andra kortet som inte *tar imot* 0x06.
Eller vet du det ? Det framgick inte av din beskrivning...

[vfr]

Jag håller fullständigt med Sodjan! Det gäller att ta reda på vilken ände som blir fel, sändande eller mottagande. Du kan även koppla ihop sändare och mottagare och samtidigt lyssna med en annan mottagare, t.ex en PC med Realterm. Då ser du direkt om det som sänds blir fel eller inte.

Har du något annat att koppla ihop "den andra" burken med som verkligen sänder 0x06, så du kan se om den reagerar som den ska på rätt data?

[bearing]

Om du har två serieportar på datorn skulle du kunna avlyssna 2-vägs-kommunikationen mellan processorerna. Mjukvaran kan vara t.ex. två terminalprogram, eller ett hemmagjort som visar båda serieportarna ihopflätat. Dock kan det senare visa sig inte stämma helt på grund av datorns buffring.

[vfr]

Sånt ska ju Realterm kunna göra. Har inte kört just det programmet så mycket, men däremot väldigt mycket debuggning av seriekommunikation med andra liknande program.

[Virror]

Sorry, glömde nämna att jag har provat alla varianter. Har kollat så att "andra kortet" skickar rätt data, och att SAM kortet skickar en 6a med hjälp av terminalen. Har även med terminalen provat att skicka in rätt sträng i SAM kortet bara för sakens skull.

Det skumma är att en 7a tex tas emot, men inte en 6a. "andra kortet" får inte ens ett UART interupt om jag skickar en 6a. Men det funkar som sakt via från terminalen till "andra kortet".

Edit: bearing, det är exakt så jag har jobbat.

[bearing]

Kanske att "andra kortet" (Fujitsu?) har en speciell UART som är inställd att reagera på just 0x06 genom att t.ex. sätta en ACK-flagga i något register, eller något sånt.

EDIT: Fast då borde det ju inte funka från terminalen...

[sodjan]

> Sorry, glömde nämna att jag har provat alla varianter.

Right, och min spåkula är på reparation...

> och att SAM kortet skickar en 6a med hjälp av terminalen.

Du menar 0x06 ?? I så fall är det absolut *inte* "en sexa" !
Är du säker på att du skickar rätt koder ? Hur ser det t.ex ut
i terminalen på PC'n när den får en ACK ? Kan du verifiera att
är rätt tecken, antingen genom att terminalen visar det eller genom
att köra det i HEX format på något sätt ?

Det är ingen del av det hela som är inställd på att köra med "ACK/NACK"
protokoll ? I så fall skulle man kunna tänka sig att ACK'en försvinner
på en lägre nivå, så att säga. Men å andra sidan så skulle det inte
fungera när du kör "det andra kortet" från terminalen i PC'n...

Right, *nu* börjar det närma sig att bli "jätteskumt"...

[Virror]

Menar 0x06, när jag skriver 6a tänker jag på en integer 6a...

Som jag skrev har jag via terminalet kollat så att det skickas 0x06. I terminalen ser ACKet ut som en hex 6a = 06, konstigt nog : p

Det andra kortet är byggt av oss, och det är helt vanlig UART.
Har tillgång till koden där, och eftersom SAM kortet kan ta emot och verifiera datat sámt att jag i terminalen kan kolla så det är rätt, så ska ju det vara rätt konfat.

Edit: Visar sig att 0x05 inte heller funkar, men 0x04 gör det..
0x05 funkar dock via terminalen.

[sodjan]

> Edit: Visar sig att 0x05 inte heller funkar, men 0x04 gör det..

Vad betyder "inte funkar" här ?
Går det inte iväg från sändande ände, eller tas det inte imot av mottagande ände ???

I det här läget skulle jag fixa till några små testprogram som enbart kör seriekommunikationen
med kända värden. Du måste ju hitta var dina tecken "försvinner"...

> I terminalen ser ACKet ut som en hex 6a = 06, konstigt nog

Vad *är* denna "terminalen" som du använder ?
Och om den visar teckenet på ett dokumenterat sätt som värdet hex 06, vad är det
då som är konstigt ? Det är ju helt OK så vitt jag förstår...

[Virror]

Med "inte funkar" menar jag såklart att det beter sig på samma sätt som med 0x06.
Dvs att den inte tas emot.

Använder terminal, och det var en smily där som visade på en gnutta sarkasm.

Håller just nu på med att programmera om ett likadant SAM kort att agera "det andra" kortet så får vi se vad som händer..

[sodjan]

> Dvs att den inte tas emot.

OK, men du *vet* att tecknet "finns på linjen" så att säga ?

Hur drivs oscillatorerna processorerna i varje ände ?
Kristallstyrt eller interna oscillatorer ? Jag funderar på
om du eventuellt har baudrate problem...

> Använder terminal,

Vad är det ?
"HyperTerminal" ?
Något annat ?

[Jonas L]

Hum, det är inte så att du skickar iväg din ack innan det andra kortet är redo för den?

Det är lite rörigt med vad som har testats, men har man två metoder att sända som ger olika resultat finns det ett antal anledningar, varav de flesta är uteslutna i ditt fall:
* Baud rate
* Stoppbitar och liknande
* Signalnivåer
* Timing, flödeshantering