rs232 mottagare?
Jag är mycket skeptisk till att dina tidsfördröjjningar i VB på bara några µs fungerar. Det är därför jag ber dig skriva precis hur du har löst det för att kunna ge dig lite tips hur du kan göra för att verifiera att det fungerar.
Om du inte är säker på att dina 1-wire-rutiner fungerar är det ju ingen idé att gå vidare.
Om du inte är säker på att dina 1-wire-rutiner fungerar är det ju ingen idé att gå vidare.
Men, det står ju *bits*, så varför blanda in bytes alls?. Jag tror inte att felet ligger i databladet. Var det ligger är svårt att säga med den lilla info vi har, men sannolikt ligger mycket i att du använder ett asynkront RS232 interface och att det därför är lätt att blanda in "bytes" i det hela, fasten 1-Wire inte har någonting med det att göra.benring skrev:Om det står att hela tempen finns i 9 BITS så e det väl en jäkla skilnad mot 9 BYTES??
OK, point taken. Ber om ursäkt.benring skrev:Sen behöver man inte va så nonchalant som vissa är i denna tråd...
Visst, men där man/jag pekar mot specifika delar av databladet där svaren på dina frågor står, så svara du med att ifrågasätta om det som står i databladet är rätt. Därav min kanske lite "korta" ton förrut...benring skrev:... varför har vi denna tråd? Jo för att jag vill VETA saker och jag upplever konstigheter i detta som jag vill ha klarhet i!
Hej, ok, ska vi försöka reda ut det där med bits o bytes då?
Jo, det står BITS.
Men tempdatat ligger ju på dom första 16 bitsen, eller hur?
Dessa delas upp i 2*8 bits.
Då förstår inte jag varför man skriver att hela tempdatat finns på 9 bits?
Sen finns själva CRC´n på nionde BYTEN (så där kommer byte in)
Därav tror jag att det hellre ska stå att tempdatat finns i 9 BYTE, allt som allt, har jag fel där?!
Se databladet på elfa, fig 7 sida 9, där står oxå byte.
Detta har iaf skapat förvirring för mig.
Sen att jag längre ner ser en tabell som jag lyckades tyda som talar om hur det låg till va ju bra.
***********************************************************
Nu till frågan hur jag verifierar:
jag kör ju som sagt i VB o där finns inte microsekunder.
Jag tycker vi kan ta detta från start i så fall:
Jag vet hur jag skickar en reset, svar från sensor ska va "0" enligt nån i tråden, detta får jag.
Frågan är vad som sker om jag sänder nått fel? får jag samma svar då me?
Jag har testat att göra en loop som räknar x antal varv o på så vis göra en minimal fördröjning, ja vet, "rysslösning"
**********************************************************
Ärligt talat så börjar jag luta åt att skaffa en PIC som gör denna biten.
Som ja sen läser av me VB.
/B
Jo, det står BITS.
Men tempdatat ligger ju på dom första 16 bitsen, eller hur?
Dessa delas upp i 2*8 bits.
Då förstår inte jag varför man skriver att hela tempdatat finns på 9 bits?
Sen finns själva CRC´n på nionde BYTEN (så där kommer byte in)
Därav tror jag att det hellre ska stå att tempdatat finns i 9 BYTE, allt som allt, har jag fel där?!
Se databladet på elfa, fig 7 sida 9, där står oxå byte.
Detta har iaf skapat förvirring för mig.
Sen att jag längre ner ser en tabell som jag lyckades tyda som talar om hur det låg till va ju bra.
***********************************************************
Nu till frågan hur jag verifierar:
jag kör ju som sagt i VB o där finns inte microsekunder.
Jag tycker vi kan ta detta från start i så fall:
Jag vet hur jag skickar en reset, svar från sensor ska va "0" enligt nån i tråden, detta får jag.
Frågan är vad som sker om jag sänder nått fel? får jag samma svar då me?
Jag har testat att göra en loop som räknar x antal varv o på så vis göra en minimal fördröjning, ja vet, "rysslösning"
**********************************************************
Ärligt talat så börjar jag luta åt att skaffa en PIC som gör denna biten.
Som ja sen läser av me VB.
/B
-
Schnegelwerfer
- Inlägg: 1863
- Blev medlem: 8 november 2004, 13:46:56
"Jo, det står BITS.
Men tempdatat ligger ju på dom första 16 bitsen, eller hur?
Dessa delas upp i 2*8 bits."
Då förstår inte jag varför man skriver att hela tempdatat finns på 9 bits?"
8 bitar är själva "värdet", den nionde biten är "sign". Se figur 2 och tabell 2 sidan 4. Det är alltså 9 bitar för temp värdet. Man behöver inte läsa mer en 9-bitar för att få ett komplett temp värde.
Obs att för snabbast möjliga temp-läsning, kan man göra en "reset" efter 9-bitar. Om man inte behöver det övriga i scratchpad'en, vill säga...
> "jag kör ju som sagt i VB o där finns inte microsekunder."
OK.
> "Jag vet hur jag skickar en reset"
Hur gör du då det ? Med tanke på vad du skrev här ovan ?
Hur *VET* du att du skickar en "1-Wire reset" ?
Har du kollat med t.ex ett oscillioskop ?
Men tempdatat ligger ju på dom första 16 bitsen, eller hur?
Dessa delas upp i 2*8 bits."
Då förstår inte jag varför man skriver att hela tempdatat finns på 9 bits?"
8 bitar är själva "värdet", den nionde biten är "sign". Se figur 2 och tabell 2 sidan 4. Det är alltså 9 bitar för temp värdet. Man behöver inte läsa mer en 9-bitar för att få ett komplett temp värde.
Obs att för snabbast möjliga temp-läsning, kan man göra en "reset" efter 9-bitar. Om man inte behöver det övriga i scratchpad'en, vill säga...
> "jag kör ju som sagt i VB o där finns inte microsekunder."
OK.
> "Jag vet hur jag skickar en reset"
Hur gör du då det ? Med tanke på vad du skrev här ovan ?
Hur *VET* du att du skickar en "1-Wire reset" ?
Har du kollat med t.ex ett oscillioskop ?
Jag vet hur jag ska skicka i teorin men jag vet inte om det sker i verkligheten, pga att jag kör VB.
Nu har jag iaf tappat gnistan i detta för tillfället då det dels verkar alldeles för komplicerat o dels kostar pengar o ÄNDÅ så e det osäkert om det ens funkar.
Jag har tittat på lite PIC-lösningar och dom jag hittat har inte haft sensorer i en serie utan en på varje ben vilket lämnar mig i samma sits som jag redan sitter i när jag kör mina andra sensorer.
Så nu vet jag inte hur jag ska göra, troligen kör jag vidare med det "gamla" sättet vilket e extremt stabilt.
Jag kan bygga ut det till 8 I/O och då räcker det till.
Blir lite mer hårdvara bara.
Jag satt o funderade på om det fanns nån typ av krets som är adresserbar på annat vis än seriellt som svarar på tilltal o öppnar igenom för den sensorn jag vill läsa.
/B
Nu har jag iaf tappat gnistan i detta för tillfället då det dels verkar alldeles för komplicerat o dels kostar pengar o ÄNDÅ så e det osäkert om det ens funkar.
Jag har tittat på lite PIC-lösningar och dom jag hittat har inte haft sensorer i en serie utan en på varje ben vilket lämnar mig i samma sits som jag redan sitter i när jag kör mina andra sensorer.
Så nu vet jag inte hur jag ska göra, troligen kör jag vidare med det "gamla" sättet vilket e extremt stabilt.
Jag kan bygga ut det till 8 I/O och då räcker det till.
Blir lite mer hårdvara bara.
Jag satt o funderade på om det fanns nån typ av krets som är adresserbar på annat vis än seriellt som svarar på tilltal o öppnar igenom för den sensorn jag vill läsa.
/B
-
Schnegelwerfer
- Inlägg: 1863
- Blev medlem: 8 november 2004, 13:46:56
Alltså, det finns ju hemsidor med färdiga lösningar där folk använder serieporten för att prata med tempertursensorna. Varför inte använda sig av en av dessa beprövade lösningar?
Ex:
http://temp.unx.nu/temp_bygg.shtml
Ex:
http://temp.unx.nu/temp_bygg.shtml
Den sidan va ju bra, den beskrev ju ingående hur man löder dom olika på vad:)
Jag vill ha min egen design på programvara så den gör det JAG vill.
Jag gillar inte att använda nån annans mjukvara om jag inte måste:)
Jag vill bestämma när jag tar in tempen, hur jag lagrar det och vad jag gör med det.
Jag kör idag en helt egengjort(med en del hjälp) tempavläsning/styrning via parallellport som funkar mycket bra.
Enda felet är begränsningen på hur många sensorer jag kan ha på en port.
Idag kan jag ha 4 in o 4 ut.
Med lite kodande kan jag nog utöka detta lite.
Med lite annan hårdvara kan jag få den att köra 8 in o 8 ut.
Sen är det troligen stopp.
Om jag inte kan fåtag i en krets som är adresserbar på nått vis, annat än seriellt
EDIT: sen är det att jag måste dra kabel som ett stjärn-nät me PC i mitten.
EDIT2: Jag kör gärna annan programvara bara jag får ha eget GUI som jag kan ställa in som jag vill.
Det handlar mest om att jag vill få in värden i en databas.
Sen gör jag det jag behöver med dom.
Idag läse jag in ett värde o behandlar det direkt.
/B
Jag vill ha min egen design på programvara så den gör det JAG vill.
Jag gillar inte att använda nån annans mjukvara om jag inte måste:)
Jag vill bestämma när jag tar in tempen, hur jag lagrar det och vad jag gör med det.
Jag kör idag en helt egengjort(med en del hjälp) tempavläsning/styrning via parallellport som funkar mycket bra.
Enda felet är begränsningen på hur många sensorer jag kan ha på en port.
Idag kan jag ha 4 in o 4 ut.
Med lite kodande kan jag nog utöka detta lite.
Med lite annan hårdvara kan jag få den att köra 8 in o 8 ut.
Sen är det troligen stopp.
Om jag inte kan fåtag i en krets som är adresserbar på nått vis, annat än seriellt
EDIT: sen är det att jag måste dra kabel som ett stjärn-nät me PC i mitten.
EDIT2: Jag kör gärna annan programvara bara jag får ha eget GUI som jag kan ställa in som jag vill.
Det handlar mest om att jag vill få in värden i en databas.
Sen gör jag det jag behöver med dom.
Idag läse jag in ett värde o behandlar det direkt.
/B
Vad menar du med "adresserbar på nått vis, annat än seriellt..." ?
Async RS232 ?
1-Wire ?
Eller något annat "seriellt" gränssnitt eller protokoll ?
För övrigt kan 1-Wire ha ganska många "noder" på en linje, det gäller bara att adressera dom korrekt, d.v.s lite trevlig programmering. Jag vet inte hur de PIC lösningar du har tittat på ser ut, men de kanske kan ändras lite till att använda adressering.
Det absolut bästa måsta vara att programmera upp en extern microcontroller som "snackar" 1-Wire åt ena hållet (mot sensorerna) och (t.ex) RS232 mot datorn. Sedan fixar man något enkelt egenkonstruerat "protokoll" mellan (t.ex) VB och microcontrollern. Gör man det "rätt", så skulle det kunna bli "självkonfigurerande" (när man t.ex lägger till eller plockar bort sensorer) utan ändringar i applikationerna (VB och MCU).
Async RS232 ?
1-Wire ?
Eller något annat "seriellt" gränssnitt eller protokoll ?
För övrigt kan 1-Wire ha ganska många "noder" på en linje, det gäller bara att adressera dom korrekt, d.v.s lite trevlig programmering. Jag vet inte hur de PIC lösningar du har tittat på ser ut, men de kanske kan ändras lite till att använda adressering.
Det absolut bästa måsta vara att programmera upp en extern microcontroller som "snackar" 1-Wire åt ena hållet (mot sensorerna) och (t.ex) RS232 mot datorn. Sedan fixar man något enkelt egenkonstruerat "protokoll" mellan (t.ex) VB och microcontrollern. Gör man det "rätt", så skulle det kunna bli "självkonfigurerande" (när man t.ex lägger till eller plockar bort sensorer) utan ändringar i applikationerna (VB och MCU).
Möjligt att det är för att det är 8 "temperaturbitar" i den ena byten och att den andra byten bara kan se ut på två sätt, antingen 11111111 eller 00000000. Då blir det 8+1=9 bitar om man ser det som jag menar..benring skrev:Jo, det står BITS.
Men tempdatat ligger ju på dom första 16 bitsen, eller hur?
Dessa delas upp i 2*8 bits.
Då förstår inte jag varför man skriver att hela tempdatat finns på 9 bits?
Prova att koppla bort sensorn och se vad du får. Då borde du nämligen få en 1:a.Nu till frågan hur jag verifierar:
jag kör ju som sagt i VB o där finns inte microsekunder.
Jag tycker vi kan ta detta från start i så fall:
Jag vet hur jag skickar en reset, svar från sensor ska va "0" enligt nån i tråden, detta får jag.
Frågan är vad som sker om jag sänder nått fel? får jag samma svar då me?
Ja, verkligen. Jag skulle ha skippat den lösningen helt om jag vore du. Inte så kul med en lösning som fungerar en gång på 1000.Jag har testat att göra en loop som räknar x antal varv o på så vis göra en minimal fördröjning, ja vet, "rysslösning"
Kör med det där enkla serieportsgränssnittet istället och använd "digitemp" för att läsa av temperaturen. Det är ett vanlig "konsollprogram" som bara läser av temperaturen och sedan skriver ut temperaturen i konsollen. Jag vet inte hur det är i Windows, men i Linux är det mycket enkelt att greppa temperaturen från utskriften och sedan göra vad man vill med temperaturen i sitt eget program.Ärligt talat så börjar jag luta åt att skaffa en PIC som gör denna biten.
Som ja sen läser av me VB.
Hej igen.
Nej, den varianten tänker jag inte använda.
Däremot så har jag stött på en timer i VB (bla) som klarar mikrosekunder, sök på QueryPerformance.
Därför tänkte jag då göra ett nytt försök i detta.
Eftersom nån säkert kommer att påstå att denna timer inte är bra då den går på CPU:ns frekvens så säger jag bara att det löser jag:)
I min PC jag kör nu har jag iaf knappat in rätt värden. (hoppas jag)
Nu till frågan:
Jag får bara ut skräp ur sensorn och jag testade då att ta bort funktionen RESET och då får jag samma skräp.
Därför vill jag veta hur jag ska verifiera att jag skickat rätt o att det funkat.
Ta reset till ex, skicka en nolla i 480-960 uS, låta den gå hög i 480-960 uS.
sen ska det va klart me reset?!
hur kan ja kolla det?
/B
Nej, den varianten tänker jag inte använda.
Däremot så har jag stött på en timer i VB (bla) som klarar mikrosekunder, sök på QueryPerformance.
Därför tänkte jag då göra ett nytt försök i detta.
Eftersom nån säkert kommer att påstå att denna timer inte är bra då den går på CPU:ns frekvens så säger jag bara att det löser jag:)
I min PC jag kör nu har jag iaf knappat in rätt värden. (hoppas jag)
Nu till frågan:
Jag får bara ut skräp ur sensorn och jag testade då att ta bort funktionen RESET och då får jag samma skräp.
Därför vill jag veta hur jag ska verifiera att jag skickat rätt o att det funkat.
Ta reset till ex, skicka en nolla i 480-960 uS, låta den gå hög i 480-960 uS.
sen ska det va klart me reset?!
hur kan ja kolla det?
/B
