Svenska ElektronikForumet

chille: Vad är det för andra byggen du har sett?

Ditt bygge

Problemet med ditt är att det är på tok för hög tillverkningskostnad, FTDI är inget bra alternativ för low-cost-applikationer, även om dom är enkla och smidiga.

Ja vill påstå att RS232 fortfarande skulle funka bra... vilket skulle minska kostnaden radikalt. Är det verkligen så många som inte har COM-port eller har den upptagen?
Ser inte heller någon anledning att ha dubbelriktad kommunikation till mikrokontrollern eftersom den ändå bara ska koda RF. (Möjligtvis för bootloader iofs...)

micke: Jag har också spanat in ditt bygge, mycket nice måste jag säga, men kanske lite väl dyrt då... den där utländska varianten som-jag-inte-minns-namnet-på (såg den i minhembio-tråden) var fin också, men tyvärr ännu dyrare, typ ~50 eller nått sånt va?

Jo, dubbelriktad kommunikation är ju bra när man ska läsa tillbaka configs från µC:n till datorn, och även när man ska flasha om den.

Klart RS232 skulle funka. Men när jag bygger något vill jag ju att jag själv ska kunna använda det. Sen vore de ju nice om mina kompisar som är intresserade också skulle kunna använda den. Sen säger jag som förut, varför i helvette ska man använda en 20 gammal standard som nästan försvunnit, när man kan göra något framtidssäkert? Och sen är det ju bara ett plus att man har ström så det räcker, då behöver man inte tänka på att snåla lika mycket.

En grej som är bra med FTDI är att då kan man göra en variatn med USB och en med RS232, men ändå köra samma mjukvara utan modifikationer, både på datorn och µC:n. Är man riktigt pro skulle man kanske kunna designa ett kretskort som klarar båda alternativen, men ändå är litet och smidigt. På så vis får man ju en kostnadseffektivt lösning, då man kan beställa alla kort likadana och på så vis troligtvis få mängdrabatt.

Vad är det för configs som måste läsas tillbaka?
Med FTDI-chippen emulerar du ju en seriport över USB... känns ju bara som ett fulhack för att slippa använda DSUB!
"Ren" USB skulle ju vara fint, men det är ju klart att emulerad COM-port också funkar... USB levererar ju ström dessutom, men som sagt, det kostar också mer.

Säg att man lägger till stöd för ett nytt protokoll, då måste man ju lagra info om hur protokollet är uppbyggt. Sen kanske man till exempel vill lagra vilka lampor som är ansluta till Nexa-systemet, så man kan skicka enkla kommandon såsom "N1+" för "Nexa #1 On" eller "N4-" för "Nexa #4 Off" För man vill ju kunna styra den enkelt via ett terminalprogram? Annars kunde man ju lika gärna kört på mel's ide och bitbangat ut datat direkt till RF-sändaren. Det går ju med både serieporten och FTDI-chipet. För vad gör microcontrollern för nytta om man bara lägger ut en pytteliten del av jobbet på den?

Min personliga åsikt vad gäller hur mycket av jobbet som skall göras i mikrokontrollern, är att all timing och protokollimplementation skall ligga i uC men inget av konfigen. Då gör varje del av systemet det som den är bäst på. uC slipper hålla rätt på en massa inställningar som PC:n, eller annan master, normalt vet mera om. PC:n slipper timing och protokolldefinitioner som kan implementeras helt och hållet i uC.

Kommando typ: Tänd enhet 1, protokoll Nexa. Eller liknande om man nu har flera olika protokoll.

Sedan anser jag att det _skall_ vara dubbelriktat ändå eftersom jag vill ha riktig feedback på serielänken iallafall, även om man inte har det på radioöverföringen. Det blir lättare att felsöka vid problem ju bättre kontroll man över kommunikationslänkarna. Men det är min åsikt.

Sedan kör jag nog lika gärna binära protokoll som ASCII-protokoll. Visst är det enkelt med ett terminalprogram men det finns program som funkar motsvarande för all slags data och visar i t.ex hexkod vad som skickas.

Jo, men som sagt. Om man vill skriva ett program/script som styr sändaren är det ju väldigt smidigt om all viktig kod ligger i µC:n. På så vis slipper man ju undan onödiga drivrutiner och styrprogram. Tänk på oss som sitter i valfritt Unix-baserat system, som jag till exempel

Och jag har svårt att förstå varför binära skulle vara bättre än ASCII. ASCII är väldigt mycket enklare att koda/läsa av i C. Visst, man förlorar ju några bitar, då man är begränsad till att minsta längden på något (till exempel ett styrkommando eller en kanal) är 8 bitar.

Det är ju lite det som jag menar. All protokolldata mm för radioprotokollet ligger ju i uC så som jag säger. Däremot är det rätt skönt att slippa konfa den lilla enheten med sådana data som PC:n egentligen håller rätt på.

Skulle enheten gå sönder t.ex eller behöva bytas ut av andra skäl så är det mycket lättare om man slipper göra speciella inställningar i den. Bara byt ut och kör igen. Nu är jag iof mycket påverkad av jobbet där det skall vara lätt för vem som helst att byta en trasig enhet i fält utan att behöva konfa något m.h.a en PC t.ex. Fast jag tycker att det gäller även i våra sammanhang. Bygger man t.ex ett styrsystem för huset och allting funkar i 3 år för att sedan gå sönder, så gäller det att komma ihåg exakt vad man gjorde för 3 år sedan eller dokumentera bra! Då skall det vara så enkelt som möjligt att byta ut en pryl.

Skall man ändå ha den typen av konfigdata så kan man t.ex skicka ner detta vid uppstart, men då blir det inte lika enkelt att köra från script.

ASCII versus binärt har naturligtvis lite olika användningsområden. För mig är det precis lika enkelt att felsöka eller driftsätta ett binärt protokoll. Kör man då i t.ex små PIC eller AVR-processorer så är det enklare och tar mindre plats i den änden att lägga ut binär data. En nodadress kan t.ex lätt skrivas i en byte rakt av utan att omvadlas till ASCII-siffror.

Men det är klart att det blir enklare med ASCII om man kör script t.ex. Det håller jag fullständigt med om. Mina små projekt kör ofta också mot en Linux som master eftersom den är server hemma, men då har jag ett C-program i den änden också. Alternativt så är det två uC som pratar med varandra där båda är kodade i assembler.

Jo det stämmer som du säger, man kanske bör undvika info om vilka enheter som är "anslutna".

Vad man däremot inte slipper undan är protokollspecifikationer. För om man ska ha så man kan uppgradera och lära den ny data från ett annat protokoll, UTAN att skriva en ny firmware, så krävs det ju ändå att man kan skriva/läsa till microcontrollern. Många har säkert andra grejer än dimmers som de vill styra. Man skulle ju omöjligt få in allting. Man vill ju slippa bitbanga direkt från datorn, men vill ju kunna skicka ett kommando i stil med "relay on channel 6 on" etc.

Jag kommer inte att köra med nedladdningsbara protokollspecar. Det skulle innebära en _mycket_ genomtänkt arkitektur för protokollspecen och ändå skulle du inte kunna vara säker på att verkligen ta alla protokoll. I min sändare så implementeras dom grundprotokoll man vill använda i firmwaren och sedan får man uppgradera den om man vill lägga till något nytt. Har man väl grundprotokollen så är det bara att köra på sedan.

Nja. Min tanke var att man skulle köra en tidkodsbaserat lösning.

Säg att man börjar med hög puls. Då skickar man den och väntar en viss tid. Efter det så växlar man till låg och väntar en viss tid, sen växlar man tillbaka till hög osv.. En byte för "multiplier" och sen en byte för varje tidskod skulle ju räcka. Då får man ändå in en hel del om man har till exempel 512B EEPROM som till exempel Mega88 har.

Jag förstår din tanke och det är ju användbart för att beskriva en signal. Men för att beskriva ett protokoll så behöver man mycket mer data. Eller menar du att man skulle lagra en sådan komplett signalbeskrivning för varje kommmando man vill kunna skicka ut?

Annars måste man veta hur allting skall kodas, var adress och data ligger i framen, hur stora fälten är o.s.v. Då är man inne på en ganska komplicerad beskrivning.

jag tycker det funkar ruskigt bra att sätta ihop paketet allt eftersom med några if-satser och for-loopar.. gör en struct med alla nödvändiga parametrar och läs av dom och översätt till ett paket.. inte särskilt svårt att lösa det med få rader kod. Paketet lagras temporärt som en 1*25bits array. Sen laddar man en timer med ett värde och togglar en pinne eller dylikt, laddar med nytt värde osv. beroende på om det är en 1'a eller 0'a.. interrupt styrt alltså.. då kan microkontrollern syssla med annat samtidigt..

Jovisst, du har helt rätt. Det är ju ett enkelt sätt att dra iväg ett meddelande. Men vad har det med protokollkonfigurering att göra? Eller var det inte det du syftade på?

Det handlar ju om att på ett så generallt och kortfattat sätt som möjligt kunna beskriva hur ett protkoll fungerar, utan att skriva någon kod för just det protokollet. Det är inte helt lätt om det skall fungera med vilken typ av protokoll som helst, eller ja nästan iallafall.