Svenska ElektronikForumet

hcb: Endast för de skickliga med bra nerver. Jag skulle knappast gå iland med ett sådant projekt.

Jag tror inte jag skulle göra det heller men att hantera klockor i GHz-området tror jag inte heller är helt trivialt.

Jag är gald att jag ställde frågan, att mäta direkt id en hastigheten kändes lurigt och så verkar det ju vara uppenbarligen. Jag har tittat på http://ww1.microchip.com/downloads/en/A ... 01375a.pdf. Det är ju en analogfunktion som finns direkt i procesorn mer eller mindre. Det bästa av två världar, jag tror att jag kan få till en tillräckligt bra lösning med detta. Någon som har erfarenhet?

(Från PDFen du länkade till)
"Using the edge trigger pins (CTEDn) on the CTMU, time can be measured precisely to a resolution of under a nanosecond."

Det låter ju som exakt det du vill göra

Jahaja, då får man alltså sluta ignorera PIC32.

Länge har det varit så att det enda jag gillar från Microchip är linjärt och minnen.

CTMU modulen finns även i de lite enklare 8 bitarna som t.ex PIC18F26K22
http://www.microchip.com/wwwproducts/De ... e=en547748.
28-pin DIP, 5V matning o.s.v gör det enkelt att labba med...

Någon måtta på lidandet får det väl ändå vara!
PIC32MX250F128D kostar bara USD3,42 i hundratal på DigiKey. Inte en ARM men en MIPS iallafall.

Egentligen finns det ingen anledning att kommentera korkade inlägg, men...

Det beror ju lite på vad man har kört eller är van med från tidigare.
Men det var just för att minska "lidandet", som du kallar det, som jag
pekade på en relativt enkel processor att komma igång med. En mer
komplex processor som t.ex. PIC32 tillför enbart just komplexitet
utan andra egentliga fördelar.

Ifall man väljer en analog lösning blir det inte väldigt viktigt att man har exakt rätt värden på komponenter?

Vad händer om t.ex ett mostånd är 10% off, då kanske någon ström till en kondensator blir 10% fel?

Och då kanske det tar 10% längre tid att ladda något?

Försöker inte förespråka en digital lösning utan bara nyfiken.

Läs "19.3 Calibrating the CTMU Module" i databladet.

sodjan: I dina ögon må det vara ett korkat inlägg.

Själv har jag lidit tillräckligt med PIC10, PIC16, PIC18, PIC24 och dsPIC i eget bolag och åt kunder. PIC12 har jag inget minne av.
De första vi använde var PIC16C52 (OTP och EPROM). Då var det fortfarande kul.

Nu känns det som om livet är för kort för att batta med arkitekturer som får 8086 att framstå som vacker.

Men jag vet att du och många andra gillar PIC och har ingen åsikt om det.

Det har ingenting med "vacker" arkitektur att göra. Enbart med att
inte göra saker och ting mer komplexa än vad som är nödvändigt.
Arkitekturen, hur den nu än ser ut, döljs i princip av (C) kompilatorn.

Som sagt, det beror även på bakgrunden hos den som ska göra det.
Om man inte har tidigare erfarenhet av någon relevant arkitektur, så är det
inte fel att använda den med lägst ingångströskel, om den löser problemet.

Det gäller generellt helt oavsett vad som diskuteras...

I just det aktuella fallet så är det inte speciellt komplext. En relativt tydlig
uppgift som ska lösas och med en väl definierad enhet i processorn.

sodjan: Du gillar PIC. Jag avskyr deras egna arkitekturer. Du använder PIC. Jag använder inte PIC. Båda är nöjda. Bra, eller hur?

Det är ju fullständigt skit samma om *du* eller *jag* är nöjda!
Enbart barnsligt...

Den enda viktiga är att det finns en lämplig hårdvarumodul
i den aktuella modellerna som löser problemet.