Jag vill egentligen inte hålla på med programmering överhuvudtaget, men för att göra ett schema som jag håller på med så mycket enklare så undrar jag om någon vet om denna ekvation går att trycka in i en 16F84 - 04? Svaret skall sen också visas med 4 6 siffror, beroende på vad pic:en klarar, på enskilda LED displayer.
Ekvation:
X / 0.Y * 60 * 60 / 1000 = Z
X är ett fast tal mellan 1 och 0.01. Y är ett decimaltal med 6 decimaler.
Tror den blev rätt så. Jag har gjort schemat så att 0.X är på 6 decimaler men mindre antal går också att ordna om det blir för mycket för pic:en. Vet inte dess räknekapacitet om den klarar av detta eller om det ens går? Jag håller inte på med programmering men i detta fall skulle det löst några problem så har jag tänkt länge på om det ändå skulle vara möjligt.
Sen så har jag också en 16F84 liggande till ingen nytta.
Möjligt att beräkna detta med en 16F84?
Nog är det möjligt. Man kan ju emulera flyttal. '84 har inte ens hårdvarustöd för multiplikation, så det lär gå låååååångsamt att emulera såsdana beräkningar; det tar säkert flera millisekunder.
MikroBasic stödjer flyttal. Det gör säkert nån version av C också (om det finns någon bra till PIC16)
Ska det bli hastighetsmätare?
MikroBasic stödjer flyttal. Det gör säkert nån version av C också (om det finns någon bra till PIC16)
Ska det bli hastighetsmätare?
-
bengt-re
- EF Sponsor
- Inlägg: 4829
- Blev medlem: 4 april 2005, 16:18:59
- Skype: bengt-re
- Ort: Söder om söder
- Kontakt:
Det är ofta bättre
Att försöka anpassa värderna ut och eller in så att det går beräkna enkelt. Det går att divivera eller multiplicera med två enkelt genom att höger respektive vänsterskifta värden. Detta går mycket fort att beräkna likadant addition och subtraktion är tämligen enkelt att genomföra. Redovisa ditt problem mer exakt så skall det nog att komma på en bra lösning. Redovisa också hur snabbt detta måste ske.
Tack för era svar! 
Hastighetsmätare, i princip ja fast för objekt istället. Tex till att mäta hastigheten på kanske en kula eller andra grejer. Det är till det som varit problemet med att hitta tillräckligt snabba men ändå billiga grejer till detta projekt.
Hastigheten på uträkningen har ingen betydelse. Pic:en kommer bara att beräkna denna ekvation och sen presentera resultatet och hur lång tid detta tar är av mindre betydelse så millisekunder är fullt aceptabelt. Jag har som det är nu utan en pic en massa andra enklare kretsar istället som tar hand om allt utom beräkningen utan dom tar hand om avkodning räkning och visning på LED displayer.
Har ett schema på det som jag satt ihop för ca 2 år sedan och allt eftersom lagt på och förbättrat och till slut gjort det klart till ca 98%. Några små grejer som skall lösas och grejer som skall testas för att se om det fungerar som jag tänkt.
Det är egentligen en ganska så enkel enkel princip bakom det hela. Det hela utgår ifrån 2 optiska sensorer som har var sin IR diod som lyser på dom hela tiden. Dessa mottagare är sen kopplade till ett enkelt schema beståedne av en OP som är snabbare än en 741 för dom var bara för långsamma. Deta för att det skall bli en 1a så snabbt som möjligt och så att jag kan reglera känsligheten på mottagaren. När den första strålen bryts så triggar det en vippa som ger en 1a till en AND grind och på det andra benet ligger det konstant en 1Mhz klocksignal.
När då grinden öppnas så går klocksignalerna fram till 6 st räknare som genast börjar räkna antalet stigande flanker, med en hastighet på 1Mhz.
När sen den andra strålen bryts (oavsett om den första fortfarande är bruten eller ej) så vippar den till 0 vilket gör att AND grinden stängs och räknarna slutar få klocksignaler till sig. Samtidigt så aktiveras 6 st BCD avkodarkretsar med LED displayer, som är anslutna till dessa räknare som avkodar informationen i räknarna och visar det på displayerna. Då ser man hur många mikrosekunder som det tog för objektet att färdas den sträcka som var melllan sensorerna.
Att sen omvandla detta tal till kilometer i timmen så behövs den formeln som jag skrev om i förra inlägget. Visst det går hur bra som helst att räkna ut detta med en miniräknare men om det hade gått med en 16F84 så hade jag kanske satt dit en sådan istället, mest för skoj skull men en del nytta givetvis, sen också för att dom bara ligger och samlar damm mest för att jag inte håller på med programering. Men jag har ändå en programmerare till dom.
Hastighetsmätare, i princip ja fast för objekt istället. Tex till att mäta hastigheten på kanske en kula eller andra grejer. Det är till det som varit problemet med att hitta tillräckligt snabba men ändå billiga grejer till detta projekt.
Hastigheten på uträkningen har ingen betydelse. Pic:en kommer bara att beräkna denna ekvation och sen presentera resultatet och hur lång tid detta tar är av mindre betydelse så millisekunder är fullt aceptabelt. Jag har som det är nu utan en pic en massa andra enklare kretsar istället som tar hand om allt utom beräkningen utan dom tar hand om avkodning räkning och visning på LED displayer.
Har ett schema på det som jag satt ihop för ca 2 år sedan och allt eftersom lagt på och förbättrat och till slut gjort det klart till ca 98%. Några små grejer som skall lösas och grejer som skall testas för att se om det fungerar som jag tänkt.
Det är egentligen en ganska så enkel enkel princip bakom det hela. Det hela utgår ifrån 2 optiska sensorer som har var sin IR diod som lyser på dom hela tiden. Dessa mottagare är sen kopplade till ett enkelt schema beståedne av en OP som är snabbare än en 741 för dom var bara för långsamma. Deta för att det skall bli en 1a så snabbt som möjligt och så att jag kan reglera känsligheten på mottagaren. När den första strålen bryts så triggar det en vippa som ger en 1a till en AND grind och på det andra benet ligger det konstant en 1Mhz klocksignal.
När då grinden öppnas så går klocksignalerna fram till 6 st räknare som genast börjar räkna antalet stigande flanker, med en hastighet på 1Mhz.
När sen den andra strålen bryts (oavsett om den första fortfarande är bruten eller ej) så vippar den till 0 vilket gör att AND grinden stängs och räknarna slutar få klocksignaler till sig. Samtidigt så aktiveras 6 st BCD avkodarkretsar med LED displayer, som är anslutna till dessa räknare som avkodar informationen i räknarna och visar det på displayerna. Då ser man hur många mikrosekunder som det tog för objektet att färdas den sträcka som var melllan sensorerna.
Att sen omvandla detta tal till kilometer i timmen så behövs den formeln som jag skrev om i förra inlägget. Visst det går hur bra som helst att räkna ut detta med en miniräknare men om det hade gått med en 16F84 så hade jag kanske satt dit en sådan istället, mest för skoj skull men en del nytta givetvis, sen också för att dom bara ligger och samlar damm mest för att jag inte håller på med programering. Men jag har ändå en programmerare till dom.
Min högst ovetenskapliga mening är att CC5X, http://www.bknd.com/, med tillhörande 'math library' är bäst lämpad för jobbet. Det är en C-kompilator till bl a PIC16-familjen som är helt gratis upp till en viss mängd kod. Jag tror du klarar dig under den kodmängden.
CC5X stödjs till 100% av Microchips egna MPLAB.
EDIT: gratisversionen stödjer enbart 24-bitars flyttal, vilket i praktiken motsvarar nästan 5 decimaler.
CC5X stödjs till 100% av Microchips egna MPLAB.
EDIT: gratisversionen stödjer enbart 24-bitars flyttal, vilket i praktiken motsvarar nästan 5 decimaler.
Jag har inga lcd displayer liggande.. jo det har jag ju visserligen, dock helt utan interface så dom kan man glömma för dom orkar jag bara inte koppla in. Däremot så har jag en hel hög med LED displayer och dom skall användas så resultatet skall upp på några sådana, ingen pc kommer att vara involverad för det här med programmering är jag helt ny på.
Jag har inte tänkt på vilket sätt det skall göras men en visningskrets blir det nog inte eftersom jag tänkt använda LED displayer som jag har liggande. Jag har i schemat 6 kretsar och varje ger en BCD utgång. Alla 6 utgångarna får förstås inte plats på picen direkt eftersom det blir 24 pinar som hade behövts då och det saknas ett antal IO portar till detta. Så det kan kanske istället göras så (om den nu klarar detta) att den kollar av de olika räknarna var för sig lägger ihop de enskilda siffrorna efter varandra till ett decimaltal och räknar sen ut ekvationen och presenterar detta på aningen 7 pinnar med avkodad BCD kod direkt till några multiplexerade LED displayer eller på 4 pinnar med ren BCD kod där sen en avkodarkrets tar hand om avkodningen och multipex. Jag har ett antal avkodar kretsar inskrivna i schemat så på så sätt kan det nog bli mindre kod att skriva.
Ett test jag gjorde så gjorde jag ett schema till denna mätare där jag använde bara en avkodar krets till 6 displayer och teoretiskt så fungerar det. Det vara bara för att visa siffrorna men det kvädes 2 extra kretsar till det, men det var roligt.
Multiplexering av svaret på uträkningen är nog ett måste, tex första siffran i svaret går till den första displayen den andra till den andra osv. Och så har man samtidigt en enkel räknare tex typ 4017. Ja jag vet att dom är gamla som gatan men fungerar hur bra som helst och jag har en hög av dessa med liggande så dom skall användas. Så vid varje gång som nästa display skall få information så flyttas informationen fram till nästa display och ges information där och nästa osv tills alla har fått informationen och så repeteras det hela. Görs detta tillräckligt snabbt nån Khz eller nåt sånt så kommer det inte att flimra nånting. En enkel krets som får en synkronisering från picen borde klara en sådan multiplexering, men jag kan ju ha fel för jag har inte hållit på med programmering av 84:an eller nånting annat heller för delen. Men teoretiskt iallafall.
Ett test jag gjorde så gjorde jag ett schema till denna mätare där jag använde bara en avkodar krets till 6 displayer och teoretiskt så fungerar det. Det vara bara för att visa siffrorna men det kvädes 2 extra kretsar till det, men det var roligt.
Multiplexering av svaret på uträkningen är nog ett måste, tex första siffran i svaret går till den första displayen den andra till den andra osv. Och så har man samtidigt en enkel räknare tex typ 4017. Ja jag vet att dom är gamla som gatan men fungerar hur bra som helst och jag har en hög av dessa med liggande så dom skall användas. Så vid varje gång som nästa display skall få information så flyttas informationen fram till nästa display och ges information där och nästa osv tills alla har fått informationen och så repeteras det hela. Görs detta tillräckligt snabbt nån Khz eller nåt sånt så kommer det inte att flimra nånting. En enkel krets som får en synkronisering från picen borde klara en sådan multiplexering, men jag kan ju ha fel för jag har inte hållit på med programmering av 84:an eller nånting annat heller för delen. Men teoretiskt iallafall.
