Hej!
jag tänkte knåpa ihop ett litet bygge som skall detektera droppar.
den får en triggpuls när det är tänkt att en droppe skall komma. Och därefter ger en läsgaffel en puls om droppen passerar (20us och uppåt).
jag skulle även vilja ställa in lite parametrar över ett USB interface (comporten är upptagen på PCn).
Den enhet jag kikat på är en Pro Micro arduino
http://www.kjell.com/tillbehor-till/mik ... ro-d280486
Jag behöver få ihop projektet under ganska begränsad tid.
Min bakgrund är att jag programmerat en hel del embeded mot t.ex pic16,18,14,33 ect, även en del ARM och skriver det mesta i C.
Men sedan har jag läst att arduino är ganska enkelt och användarvänligt.
Min fundering är vilken väg jag skall gå:
1. Plöja genom datablad skriva drivrutiner och stack för commandon etc i C. Jag har inte arbetat med AVR tidigare så det kan ev bli liten startsträcka.
2. Gå den enklare vägen genom Arduinos utvecklingsmiljö där en hel del av drivrutinerna är färdiga. Då blir det kanske enklare även för nästa person att förvalta koden.
Eller finns det ytterligare alternativ? Vilken väg tycker ni att jag ska ta? är det värt att sätta sig in i Arduinos utvecklingsmiljö eller är den för användarvänlig för att få bra realtidskrav på att detektera droppar?
mvh/
Daniel
[Förtydligade rubrik - hcb]
Droppdetektor
Re: Rekomendation
1: Vad tusan menar du? Det är alltid bra att ha databladet så man vet vad man har att jobba med och inte gör en Al_Bundy (blunda o veva - helt aningslös).
2: Vilka drivrutiner?
"realtidskrav på att detektera droppar"
Vad tusan menar du med detta?
Om jag förstår dig rätt:
A. Du vill kunde ge ett kommando som utlöser en droppe.
B. Du vill detektera att en droppe faktisk föll.
Detta ger ju upphov till en hel del frågor...
* Hur vill du styra att det bildas en droppe?
* Hur blandas realtid in i det hela?
2: Vilka drivrutiner?
"realtidskrav på att detektera droppar"
Vad tusan menar du med detta?
Om jag förstår dig rätt:
A. Du vill kunde ge ett kommando som utlöser en droppe.
B. Du vill detektera att en droppe faktisk föll.
Detta ger ju upphov till en hel del frågor...
* Hur vill du styra att det bildas en droppe?
* Hur blandas realtid in i det hela?
Re: Rekomendation
jag kanske var något för kortfattad.
Jag kommer inte undan med att läsa databladet och det har jag inget problem med. Men när man sätter sig in i en ny arkitektur så är det väldigt mycket nytt. Då är det skönt att ha något "fungerande" som man kan luta sig mot och koncentera sig på de modifieringar som behövs för att uppfylla mina behov.
Kretsen skall enbart läsa av droppar, dvs 2st ingångar.
en för trigg in och en för detektion av droppen.
Drivrutiner. det jag menar här är att man brukar behöva läsa genom databladet ganska noga och ställa in alla register till de perferienheter som behövös samt ytterligare register som t.ex kan vara inställningar till watchdog etc. dvs de inställningar som behövs göras för att prata med hårdvaran.
Med realtidskrav menar jag att jag vill hinna detektera triggpulsen och därefter detektionspulsen. På endel av microships processorer drar 1 instruktion 4 klockcykler.
Denna lilla chip är på 64Mhz kanske ger 16 el 32 instruktioner per us. (får läsa i databladet för detta). det blir inte särskillt många instruktioner mellan pulserna. Har man inneffektiv kod kan det bli problem.
mvh/D
Jag kommer inte undan med att läsa databladet och det har jag inget problem med. Men när man sätter sig in i en ny arkitektur så är det väldigt mycket nytt. Då är det skönt att ha något "fungerande" som man kan luta sig mot och koncentera sig på de modifieringar som behövs för att uppfylla mina behov.
Kretsen skall enbart läsa av droppar, dvs 2st ingångar.
en för trigg in och en för detektion av droppen.
Drivrutiner. det jag menar här är att man brukar behöva läsa genom databladet ganska noga och ställa in alla register till de perferienheter som behövös samt ytterligare register som t.ex kan vara inställningar till watchdog etc. dvs de inställningar som behövs göras för att prata med hårdvaran.
Med realtidskrav menar jag att jag vill hinna detektera triggpulsen och därefter detektionspulsen. På endel av microships processorer drar 1 instruktion 4 klockcykler.
Denna lilla chip är på 64Mhz kanske ger 16 el 32 instruktioner per us. (får läsa i databladet för detta). det blir inte särskillt många instruktioner mellan pulserna. Har man inneffektiv kod kan det bli problem.
mvh/D
Re: Rekomendation
Vilken trigg? Att detektera tiderna mellan pulserna är ganska enkelt men vad ska trigg-pulsen göra?
Re: Rekomendation
Den puls som säger "snart kommer det en droppe" kallar jag för triggpuls.
När detektionspulsen kommer skulle jag vilja mäta tiden mellan pulsena för att kunna få ut en hastighet.
Just tidsmätninge är mer av en "nice to have" funktion och inget direkt krav.
När detektionspulsen kommer skulle jag vilja mäta tiden mellan pulsena för att kunna få ut en hastighet.
Just tidsmätninge är mer av en "nice to have" funktion och inget direkt krav.
Re: Rekomendation
Du använder då 2 st CCP-enheter i den valda µC, de klarar det galant utan att sitta och räkna antal CPU-cyklar.
Det känns som att du har utgått från helt fel sätt att mäta på.
Det känns som att du har utgått från helt fel sätt att mäta på.
Re: Rekomendation
Det finns risk att detektorn kleggar igen eller att det kommer störningar in i systemet. Därför kommer det tillkomma lite kontroll-kod för att verifiera att pulserna är rätt. Därför tror jag att det behövs lite mer kod än att "bara" vänta på puls 1 och därefter puls 2.
Re: Rekomendation
Skulle nog inte köra Arduino i det fallet, snarare en PIC32a eller liknande.
Re: Droppdetektor
dangraf: att rekommendera Arduino är inte(!) något som ligger i min natur. Jag har svårt för att se varför man ska välja en halvtrött µC för en dyr peng när man kan få en helvass en hel del billigare.
För att ha två CCP duger en PIC18Fnånting helt fint, ska man mäta exakt ska man ha kristall och ska det gå fort ska den ha inbyggt PLL.
En PIC18FxxK22 kan vara ett punkt att starta på, en snabb sökning visar det.
För att ha två CCP duger en PIC18Fnånting helt fint, ska man mäta exakt ska man ha kristall och ska det gå fort ska den ha inbyggt PLL.
En PIC18FxxK22 kan vara ett punkt att starta på, en snabb sökning visar det.
Re: Droppdetektor
Varför rekomenderas inte Arduino? Den uppfattning jag fått efter att ha läst runt på ett gäng trådar är att man väljer bort Arduino av religösa skäl 
Man tycker det är för "enkelt"..
Finns det några prakiska skäl för att välja bort Arduino? Jag har inga erfarenheter alls från denna utvecklingsmiljö. Är det värt att lära sig?
Vad skulle microships processor ge för fördelar jämfört med denna färdiga lösning för 130:- detta pris tycker inte jag är "dyrt"
Enheten har kristall och jag skulle vara förvånad om den inte har CCP enheter.. får kolla upp detta.
Jag har även kikat på denna
https://www.elfa.se/elfa3~se_sv/elfa/in ... =0&q=stm32
Men det känns lite overkill med en ARM processor för denna applikation.
Man tycker det är för "enkelt"..Finns det några prakiska skäl för att välja bort Arduino? Jag har inga erfarenheter alls från denna utvecklingsmiljö. Är det värt att lära sig?
Vad skulle microships processor ge för fördelar jämfört med denna färdiga lösning för 130:- detta pris tycker inte jag är "dyrt"
Enheten har kristall och jag skulle vara förvånad om den inte har CCP enheter.. får kolla upp detta.
Jag har även kikat på denna
https://www.elfa.se/elfa3~se_sv/elfa/in ... =0&q=stm32
Men det känns lite overkill med en ARM processor för denna applikation.
Re: Droppdetektor
dangraf: om du ämnar att starta ytterligare en flamewar är det helt rätt fråga 
Min anledning är att ATmega µC-serien varken är speciellt ny, häftig, prisvärd eller välbestyckad. Samtidig är programmeringsspråket en egen variant av C(++).
För att blinka LED och lösa enkla uppgifter för nybörjare är Arduino enkel att komma igång med men jag har sett alldeles för många exempel på att ambitionerna är extremt mycket högre än kunnandet uti programmering för att tycka att det är annat än en "testa på"-grej.
Såklart är det en hel del Dunning-Kruger effekt i denna observation, ett specifikt forummedlem har ju detta bortom skalan.
Ingenstans i systemet ligger det en sporra till att lära förstå vad man egentligen gör, för en komplett rudis är det bara en fördel men när man vill lite mer är det ett stort hinder att ta sig genom.
Så i mitt tycke är Arduino bara en upphottat BASIC-stamp.
Min anledning är att ATmega µC-serien varken är speciellt ny, häftig, prisvärd eller välbestyckad. Samtidig är programmeringsspråket en egen variant av C(++).
För att blinka LED och lösa enkla uppgifter för nybörjare är Arduino enkel att komma igång med men jag har sett alldeles för många exempel på att ambitionerna är extremt mycket högre än kunnandet uti programmering för att tycka att det är annat än en "testa på"-grej.
Såklart är det en hel del Dunning-Kruger effekt i denna observation, ett specifikt forummedlem har ju detta bortom skalan.
Ingenstans i systemet ligger det en sporra till att lära förstå vad man egentligen gör, för en komplett rudis är det bara en fördel men när man vill lite mer är det ett stort hinder att ta sig genom.
Så i mitt tycke är Arduino bara en upphottat BASIC-stamp.
Re: Droppdetektor
Såklart att en programmeringsoförmögen person som inte klarar av en Arduino ska välja en häftig och välbestyckad uC, göra sina egna kort, sätta ihop sin egen toolchain och skriva all kod i optimerad assembler....
Re: Droppdetektor
Wedge: Din åsikt gör det onödigt svårt att få jobbet gjort, även erfarna programmörer undviker ju ASM om det inte är alldeles nödvändigt.
Men du har såklart all rätt att ha den åsikt.
Men du har såklart all rätt att ha den åsikt.
Re: Droppdetektor
flamewar var inte min avsikt. Men det känns redan som en upptrappning, microchip vs atmel och C vs arduino
Man kanske skall formulera om frågan ännu en gång.
Vad är era bra/dåliga erfarenheter kring arduino?
Nu är jag mest nyfiken. tror det lutar åt arm-varianten ändå.
Man kanske skall formulera om frågan ännu en gång.
Vad är era bra/dåliga erfarenheter kring arduino?
Nu är jag mest nyfiken. tror det lutar åt arm-varianten ändå.
