Svenska ElektronikForumet

Här är ett exempel ur referens-boken:
http://www.mikroe.com/en/books/picbasicbook/09.htm#9.1

Varför inte köra i interuptrutinen? Då hoppar den automagiskt in i rutinen direkt när något händer samt när ett nytt tecken mottas.

Tex kan man ju sålla bort allt irelevant till "rätt" tecken eller sekvens uppenbarar sig.

Mikrodatorns serieport har fått en D-sub via max232. Där ansluts en F-bus kabel till mobilen.

F-bus kabeln innehåller ju elektronik som strömsätts via PC'n. Hur har du löst det via PIC'en?

> Här är ett exempel ur referens-boken:

Lite av ett exempel utan värde för det aktuella problemet.
Det är ju bara en enkel echo-rutin. Ingen mening i att fördjupa sig
mer i det, det är ju ganska uppenbart att hela applikationsdesignen
nog bör bör omarbetas från grunden.

Jag undrar fortfarande hur det var tänkt att den där while/wend
logiken skulle fungera i praktiken. Det är ju uppenbart att det
inte kommer att fungera.

Om man jämför det vitala ur netrunners kod: Med det vitala ur bokens kod: Så framkommer ju en tydlig skillnad.
Boken kollar inte värdet på USART_Data_Ready i while-loopens kontrolldel, som netrunner gör.
En spekulation från min sida gällande netrunners kod, är att bufferten fylls upp med två tecken, som tas emot av USART_Read varefter bufferten töms.
När while-loopen då ska köra nästa iteration så är USART_Data_Ready inte längre 1 eftersom bufferten inte har hunnit fyllas med data än.
Därför tas bara två tecken emot av PICen.

Förmodligen är det därför som boken föreslår att man kollar USART_Data_Ready med if-sats innanför while-loopen istället.

Det är i alla fall enkelt för netrunner att testa om det verkligen förhåller sig på det sättet.

Jag tycker att det är mer eller uppenbart att det är exakt så som du säger.
Exempelkoden kan verifiera det, men den löser inte problemet. Det gör
bara en hel omdesign av applikationen.

Kan du förklara varför du anser att en hel omdesign av applikationen krävs?
Han har ju inte visat hela programmet, åtminstone inte i den här tråden, och så vitt jag vet, inte i någon annan tråd heller.

Sedan undrar jag varför du först sågar det solklara exemplet med mikroBasic som jag letade upp, med kommentaren att det är "utan värde för det aktuella problemet", för att sedan när jag tydliggör varför jag postade exemplet, istället kommentera "Jag tycker att det är [...] uppenbart att det är exakt så som du säger"?

Jag får nästan uppfattningen att du vill att netrunner ska lägga ner och inte fortsätta.

Exempelkoden har samma grundproblem som originalkoden, alltså löser den inte problemet.
På sin höjd är det en test av ett lite annorlunda sätt att läsa, men det är också allt.
Det går inte att lösa detta innan man har en rutin som bygger på att man avslutar
läsningen först när man vet att ett helt paket är mottaget. Alltså måste man
antingen räkna tecken eller söka efter något i teckenströmmen som anger att
paketet är slut. Att bara kolla om det finns tecken i USART'ens in buffert
fungerar inte.

Visst har du rätt i din analys, men det gör ju inte den kod du postade mer "rätt".
Så där finns det ingen samband.

Och det behövs inte mer kod, det är ju tydligt angivet att problemet är att bara
två tecken mottas. Kanske den visade koden skulle kunna fungera om det fanns
annan kod som hela tiden anropar den igen, men det är nog inte heller en
speciellt bra metod. En interruptdriven rutin som flyttar tecken från USART
till en buffer och samtidigt kollar efter "paket-slut" skulle fungera. Alternatvit
(om det bara är ett visst fält i paketet som ör intressant) att interruptkoden
bara kastar tecken tills rätt "fält" startar (om man kan se det, det finns ingen
spec över hur själva dataströmmen ser ut) och bara då lagrar det aktuella datat.

Hur som helst, grundfrågan var problemet med att enbart två tecken sparas,
och det faller sig nog naturligt med den kod som har vistats, som fler här har
skrivit.

> Jag får nästan uppfattningen att du vill att netrunner ska lägga ner och inte fortsätta.

Absolut inte!
Men det är meningslöst att fortsätta med den visade lösningen...

Ja, han säger ju att han ska ta emot 40 tecken långa meddelanden, och han visar ju i sitt kod-exempel att han vill läsa tills han har 40 tecken.
Jag kan ärligt talat inte följa logiken i den biten av koden, men det ser ganska felaktigt ut.
Jag har dessutom ingen basic-vana, så jag kan inte föreslå någon bättre metod i det språket.

I Perl skulle jag göra så här, concatenate inputen till variabeln tills variabelns längd är 40 tecken: Men det är ju nästa steg i problemet, så om det första steget är löst nu, så har man ju kommit en bit på vägen, alltså är det väl inte bortkastat?

Jag tror att vi har en ganska intressant fråga här om seriekommunikation i allmänhet.

Kan troligen vara intressant för många här på forumet då Nokia 3310 (och likande) tillverkades i stor volym och idag är billiga. Begagnad telefon och seriell datakabel för kanske 150kr. Kontantkort är ju billigt och smidigt.

Nya telefoner med USB-port är mycket svåra att prata med och dedikerade GSM-moduler har samma krav som Nokia 3310 men är mycket dyrare.

I mitt fall finns det saker som jag inte kan ändra på, tex hastigheten 115.2k och den data som Nokia-mobilen skickar är som den är.

Med alla respekt till sodjan men att man måste bygga en rutin som vet att inkommande text måste innehålla ett "stop" för att man ska veta att "nu är det slut" ... det känns inte som riktigt rätt grej. Rimligen måste man ju kunna taemot data som man inte vet hur eller när den slutar.

Jag har försökt att läsa snabbare, och även när den ska vara tom ... och då är den även tom.

Mitt första försök här har ju misslyckats: det var att bara ta emot data från laptopen (som jag ju har direkt kontroll på). Inte så stora krav, bara att det ska funka alls.

Steg två, att ta emot data från mobilen får ju vänta till steg ett funkar. Här är det betydligt mer data än 40 tecken, det kan ju variera.

Det är alltså så att mikrodatorn ska kunna kolla Nokia mobilen om det har kommit ett SMS "med order" och där efter tanka hem det och kontrollera vad som står i. Troligen med lösenord. Kan ju även vara bra att mikrodatorn kan svara tillbaka med ett SMS.

F-bus kabeln får ström från status signalerna på laptopen. Det sker ingen flödesreglering alls från laptopen, det har jag kollat genom att köra ett "spion program" mot COM1: samtidigt som jag skickar ett sms från ett program i laptopen.

> Rimligen måste man ju kunna taemot data som man inte vet hur eller när den slutar.

Nej, det kan man inte, generellt sätt. Man måste alltid på något sätt veta när
man är klar med läsningen. Hur 17 skulle det annars fungera ?

> Jag har försökt att läsa snabbare, och även när den ska vara tom ... och då är den även tom.

Ja, självklart, det är ju just det som är problemet/felet med ditt sätt att läsa.
Om jag inte missuppfattar allt så slutar din rutin att läsa så fort det är "tomt".
Och det kommer alltid att vara tomt en kort stund mellan varje tecken, d.v.s från
att du har läst ett tecken tills nästa finns "hemma" i sin helhet.

> Här är det betydligt mer data än 40 tecken, det kan ju variera.

OK, för att rellatera till första punkten ovan, hur vet du *då* när det är "slut" ?

Jag har kollat F-bus protokollet och det bygger alltså på variabel packetlängd
där längden finns med som en del i början på paketet. Har du tänkt att
använda det för att avgöra när läsningen är klar ? Eller vad är planen ?

EDIT (till första punken ovan):
Det är klart att man rent tekniskt kan läsa utan att veta när det är klart,
men i praktiken så vet man ju då inte när det är klart, så att säga, och
när det är dags att "agera" på det som man har mottagit.

Det finns egentligen två sätt att hantera data på en serieport. Antingen som en ström av data eller som paket. När man kör som en ström av data så behöver man inte veta något om start, stopp och liknande utan allting är en flytande ström av tecken, oavsett om det skulle vara långa pauser mellan tecken t.ex. Precis som en terminal. Skall man däremot hantera data i paket så måste det finnas något sätt att avgränsa paketen från varandra. T.ex någon form av start och/eller sluttecken.

I sin enklaste textform så kan det vara sluttecken bestående av CR eller CR/LF och däremellan data i någon form av textformat. Det gäller från början att få koll på hur denna avgränsning sker och bygga upp sin pakethantering efter det. Ett av dom vanligaste felen i början är att man förutsätter för mycket om innehållet i paketen. Fördelen med ett textformat är att det är relativt "fritt" i formatet. Nackdelen med ett textformat är att det är relativt fritt i formatet. Nackdel såtillvida att du som programmerare måste ta hänsyn till fler olika fall med t.ex olika antal mellanslag mellan olika delar etc. Man får bygga några generella funktioner som hanterar t.ex sökning till nästa avgränsare i paketet, sökning till slut på paket o.s.v.

Ursäkta, det blev lite flummigt, men ett försök att förklara lite allmänt.

Oavsett om data kommer i block eller "kontinuerligt" måste de vara märkt på ett så sätt att man kan identifiera vilka delar som är vad.

Är det bara 1 byte data som överförs är det ju enkelt men är "1 datamängd" mer än 1 byte ska man ha klart för sig att det hela på något tidpunkt _kommer_ ur synk! Alltså måste man ha ett sätt att komma tillbaka i synk.

Detta kan göras vid att ha ett slutmärke i datamängden ("data i mängder - en unik kombination som slutmärke") eller använda tid ("en datamängd - tystnad en viss tid"). Detta slutmärke kommer samtidig att vara startmärke inför nästa datamängd.

Man ska alltså tänka så att man när som helst ska kunde klippa av dataledningen, vänta en slumpmässig tid varefter man kopplar ihop igen och inget av dessa saker ska ge fel funktion. Visst, datan som överförs kan ha betydelse för vad som utförs men t.ex. ett för kort datablock får inte missuppfattas och då utlösa fel funktion liksom skräpdata inte får missuppfattas.

Själv kör jag oftast med ett starttecken (STX, 02h), sedan data i textform, en checksum och till slut ett sluttecken (ETX, 03h). Detta medför att mina projekt kan skicka ut vilken text som helst (debugutskrifter) vilket jag "sniffar" på men när kommunikationen med PC'n utförs är det alltid i blockform. STX rensar inputbuffern och ETX utlöser en "behandla inkommande data" och allt däremellan läggs bara i inputbuffern så länge det finns plats.

Detta sätt fungerar mycket bra för mig och har gjort det under åren.

För den nyfikna finns Nokia F-buss protokollet beskrivet här:
http://www.embedtronics.com/nokia/fbus.html

Jag ser ingen speciellt problem med att hantera protokollet, men
kanske inte med den kod som har presenterats här i tråden.