Palm-Logicanalyzer
Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Dieser Artikel ist auf Grundlage des folgenden Threads entstanden:
- [1]PDA als LA
Es soll keine Konkurenz zum anderen LA-Projekt enstehen, sondern nur eine sehr einfache Variante auf Basis eines AVR-Mikrocontrollers in Verbindung mit einem Palm als Benutzerschnittstelle.
Anforderungen
- geringe Kosten
- einfach nachzubauen
- sowohl mit als auch ohne Palm benutzbar
Einschraenkungen
- serielle Anbindung mit max 115200baud
- geringe Aufloesung von 160x160px auf dem Palm(ja es gibt auch Palms mit HiRes-Display, aufgrund der einfachen Beschaffbarkeit der aelteren Modelle(ebay ca 10-30€) sollte aber grundsaetzlich von der geringen Aufloesung ausgegangen werden)
- Verzicht auf SMD-Bauteile, CPLDs, externe SRAMs usw. (evtl reicht sogar eine Lochraster-Version)
- 8 Kanaele
- geringe Samplerate(wie schnell kann ein AVR(@ca 14Mhz, wegen Baudratenquarz) einen Port abfragen und in den RAM schreiben?)
- keine erweiterung auf ein dso, da ungleich komplizierter in der beschaltung, selbst bei verwendung des internen adc
Ablauf
- zunaechst waere es wichtig zu wissen, ob überhaupt genug Leute Interesse an einem solchen Projekt haben. Deswegen bitte einfach mal in dem oben erwähnten Thread vorbeischauen und eure Meinung posten.
- allgemeines Brainstorming
- dann sollte ein Pflichtenheft erstellt werden, damit es spaeter keine Ueberraschungen gibt, und die einzelnen Arbeitsgruppen sich nicht mit nachtraeglichen Änderungen rumschlagen muessen.
- als naechstes steht die Festlegung der Schnittstellen auf dem Programm
- ab jetzt koennen die einzelnen Aspekte unabhaegig weiter bearbeitet werden
- sobald das Projekt Beta-Status erreicht, kann mit dem Nachbau begonnen werden.
Brainstorming
- ist es sinnvoll ein version-control-system (cvs oder besser svn) zu benutzen?
- plattformübergreifende PC-Software durch geeignete Toolsets(mein fav ist [2]fltk)
- wer wuerde denn einen Teilaspkekt des Projekts entwickeln wollen?
- salival-> Palmsoftware
- Hans -> AVR,PC-Soft
- wieviel Zeit kann Derjenige dann dafuer aufbringen? ich(salival) hab im moment eigentlich genug andere Sachen zu tun, die weitaus wichtiger waeren. Somit koennte sich die Entwicklung zumindest was mich betrifft durchaus laenger hinziehen
- Hans -> wenig bis weihnachten...
- welcher Controller, bzw besser gefragt, welche Speichertiefe ist sinnvoll?
- 1024 Byte --> atmega8
- 2048 Byte --> atmega32
- 4096 Byte --> atmega644(beschaffbarkeit?)
- oder doch lieber ein atmega8515 mit externem sram? damit waeren Speichertiefen bis knapp unter 64kb moeglich --> sollte mehr als ausreichend sein, um auch wirklich was mit dem LA anfangen zu koennen.
- half- und quarter-modus mit 4 respektive 2 Kanaelen um die Aufzeichnungsdauer zu verdoppeln/vervierfachen
- da ich(salival) noch nie einen LA benutzt habe, was sind die wichtigsten(unverzichtbaren) Features?
- es sollten neben den digitalen Kanälen auch ein bis ... analoge Kanäle aufgezeichnet werden können, um bspw. Schaltstufen zu analysieren
- siehe oben: es ist definitionsgemaess keine dso-erweiterung vorgesehen, da dies eine verhaeltnismaessig grosse heraussvorderung an den analogteil stellt. sollte jedoch jemand ein zusatzmodul oder eine alternative hardwareversion entwickeln wollen, steht ihm das offen. das geplante protokoll wird genug spielraum dafuer haben. auch eine erweiterung der palm-software waere denkbar, ist jedoch erstmal nicht angedacht, bevor die la-software nicht "fertig" ist.
- ich (hans) hab mir mal gedanken über die avr-soft gemacht für die voll-avr version. der avr bekommt am xmem einfach ram drangehängt und zwar so,dass er einen Überlauf bekomm wenn der ram voll ist.. mit einem st z+ geht man durch bis ein Überlauf passiert => böses flag lässt sich blicken => raus aus der sampling-loop... es wäre nun nett wenn sich jemand erbarmen könnte zu überlegen obs nicht noch schneller ginge ;)
triggerloop: in rx,PINx 1 or rx,rmask 1 sub rx,rvalue 1 brne triggerloop 1/2 nop sampleloop: in rx,PINx 1 st z+,rx 2 brcc sampleloop 1/2
das macht 5 takte zum triggern (trigger byte wird nicht gespeichert da redundant) und für jedes mal samplen nochmal 5 takte... ergibt bei 20Mhz immerhin noch 4Mhz an sampling-rate... jeder der jetzt daherkommt und mir meinen traum vom einfachen Sample-O-Mat zunichte macht bekommts mit meinem Kill-O-Zap zu tun *G*
Pflichtenheft
Realisierung
Das Projekt soll in 3 voneinander unabhaenige Teile aufgeteilt werden: