mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PDA als LA


Autor: Christoph H. (berton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe mal irgendwo was gelesen, dass jemand ein Palm zu einem kleinem
logicanalyser umgebaut hat.
Hat einer entsprechende Links oder Infos? Auch alles andere zum Thema
PALM-Modding/Hacking wäre interessant. Also ruhig alles zuschicken.

Autor: Bjoern Mueller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
www.google.de/search?q=palm+logic+analyzer --> erster treffer

im grunde keine grosse kunst, da der palm nur als benutzerschnittstelle
herhalten muss.

interessiere mich aber auch fuer alles rund um die alten palms. habe
einen Vx und einen m100. werde wohl demnaechst mit hilfe von ebay ne
kleine sammlung aufbauen.

in die programmierung von palms bin ich auch schon mit
miniprograemmchen eingestiegen. macht spass und ist als eventgesteuerte
software mal was neues fuer mich. habe im moment aber leider viel zu
wenig zeit fuer meine hobbys.

als naechstes grosses projekt ist ein kamera-modul mit gameboy-cam fuer
den palm geplant. kann aber noch eine ganze weile dauern.

gruss, bjoern.

Autor: Christoph H. (berton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nun ja. Das habe ich auch gefunden, aber irgendwie ist da nix von einem
Schaltplan geschweige denn von einem Programm zu sehen.
Scheint auch irgendwie mehr oder weniger ein geplantes Projekt zu sein
(dummerweise schon in Planung seit 2002) :)

Nen Vx habe ich auch noch hier rumliegen. Eigentlich sollten die Dinger
mit 16Mhz und mehr für alles mögliche ausreichen.

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja sind schon nette teile, vor allem wegen der langen laufzeit, bzw. dem
niedrigen stromverbrauch.

hab noch das hier gefunden:
http://www.jwardell.com/about/seniorproj/index.html
http://www.dataget.com/

wie waere es selbst ein solches projekt zu starten? hat das sinn?
immerhin ist der bildschirm mit 160x160px doch schon sehr klein.
desweiteren hat kaum noch jemand einen palm und der aufwand eine
vernuenftige software zu schreiben ist schon sehr hoch, wenn die mehr
koennen soll als nur das noetigste.

der hardwareteil sollte sich jedoch recht einfach mit einem kleinen
avr, oder wenns wirklich schnell sein muss, mit avr+cpld+sram loesen.

insgesamt waere das eine nette sache, hat aber in meinen augen keinen
grossen nutzwert.

gruss, bjoern.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, es gibt ja auch schickere Palm-Ausgaben; mein Sony Clié hat ein
320x320-Farbdisplay ... und damit könnte ein LA schon was hermachen.

Autor: Christoph H. (berton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, das sieht ja alles ganz nett aus, aber auch wieder nix richtiges
dabei. Da muß es doch irgendwas geben. Kann ich mir nicht vorstellen,
dass bisher keiner was mit den Dingern gemacht hat. Leider sieht es bei
mir Zeitlich im Moment auch mehr als mau aus. Würde mich gerne mal in
die Programmierung von den Dingern einarbeiten.
Sinnvolle Sachen kann man damit wohl eher weniger machen. Auch die
Bandbreite wird wohl kaum ausreichen um einen akzeptablen LA zu bauen.
Sei denn man geht vielleicht irgendwie direkt an den Prozessor ;)

Autor: Christoph H. (berton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo Rufus. Da hast du den SJ33, oder? Den habe ich auchnoch :)
Habe ne ganze Sammlung voll g

Autor: Mark Hämmerling (haemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Salve,

die alten Palm-Modelle haben's mir auch angetan. Da bekommt man
wirklich viel Leistung und Hardware für sehr wenig Geld. Meine
Palm-Projekte:

Open Source Fahrradcomputer:
http://veloace.sf.net
-> Sollte ursprünglich auf AVR mit LCD und CF-Karte basieren. Der Palm
bietet aber eine viel bessere Hardwarebasis (Touchscreen, GLCD, viel
RAM) und ist mit seinen 20 Euro wesentlich günstiger als jede
Selbstbaulösung. Außerdem ist der Nachbau somit denkbar einfach.

Open Source AVR In-System-Programmer:
http://palmavr.sf.net
-> Programmer-Software für AVR109- und AVR061-basierte Programmer
(STK500, Butterfly, AVR910, etc.). Bietet eine GUI zum
Up-/Downloaden/Verifizieren/Identifizieren von Images, und außerdem
einen grafischen Fuses-Editor, der mindestens so übersichtlich ist wie
der von PonyProg. ;)

Vielleicht ist das ja für den einen oder anderen Palm-User hier von
Interesse. :)

Mark

Autor: Christoph H. (berton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jep, das waren die einzigen beiden Projekte die ich bei meiner Recherche
gefunden habe.
Das AVR-Dingen ist ja inzwischen schon ein bisschen bekannter und der
Fahrradcomputer ist gut, aber nix für die Jahreszeit (wenn man mal von
den abnormalen Temperaturen absieht).
Sind aber echt gut geworden die beiden Projekte

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark Hämmerling
palmavr benutze ich auch. vielen dank an dieser stelle fuer dieses
tolle programm.

ist ja doch mehr resonanz, als ich erwartet haette. man koennte ein
solches projekt ja in 3 voneinander unabhaenige teile aufteilen:
-hardware bzw. controller-software
-palm-software
-pc-software

die hardware sollte sich wahlweise an palm oder normalen rechner
anschliessen lassen. damit wird es auch fuer nicht-palm-besitzer
interessant. desweiteren sollte eine uebertragung der auf dem palm
gesammelten daten auf den rechner moeglich sein.

zu den anforderungen:
ich bin fuer eine moeglichst nachbaufreundliche version. das bedeutet
kein cpld und kein externer ram. damit ist zwar die bandbreite stark
begrenzt, sollte aber fuer den hausgebrauch durchaus ausreichen.

genauso siehts bei der software aus:
auf dem palm wirklich nur das noetigste, auf dem pc was praktikables
ohne erweiterbare modulbauweise und sonstige spielereien.

als erstes sollten wir uns gedanken um die exakten anforderungen
machen. danach sollten die schnittstellen festgelegt werden und sich
einzelne arbeitsgruppen bilden. wenn wir es bis dahin geschafft haben,
sollte sich so ein projekt durchaus realisieren lassen.

wie waere es erstmal mit einer projektseite hier im wiki?

die wichtigste frage ist fuer mich aber immer noch, ob genug leute
interesse an einem solchen projekt haben.

gruss, bjoern.

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so, und nun nochmal die korrigierte Adresse des Artikels:
http://www.mikrocontroller.net/articles/Palm-Logicanalyzer

damit auch rechtschreibfehlersucher zufrieden sind...

gruss, bjoern.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute

Ich fände es auch ganz toll, wenn ich meinen Palm Vx als einfachen LA,
zum Beispiel für I2C benutzen könnte. Da der LA offensichtlich nur für
Hobby- und Amateur-Basteleien taugen wird, schlage ich vor, dass wir
nach dem KISS-Prinzip vorgehen (keep it simple, stupid).

Ich schlage vor, die Daten vom uC zum Palm/PC kommasepariert zu
übertragen. So kann man auf dem PC mit dem HyperTerminal
mitprotokollieren, und wenn man genug gemessen hat, das ganze z.B. in
Excel importieren und dort nach Bedarf auswerten. Was für Software es
für den Palm gibt weiss ich nicht, aber ein Terminal-Programm wird
schon verfügbar sein.

Ich würde folgende Modi implementieren:
- Timed-Modus -> Alle Eingänge werden so schnell wie möglich
ausgewertet und per RS-232 ausgegeben, das Zeitintervall ist konstant
- Change-Modus -> Sobald eine Veränderung an einem  der Ausgänge
bemerkt wurde, wird eine Übertragung gestartet.

Wenn das ganze in der Art von

 TIMESTAMP  P0 P1 P2 P3 P4 P5 P6 P7
-------------------------------------
00:00:01    L  L  H  L  L  L  L  L
00:00:02    L  H  L  L  L  L  L  L
00:00:03    L  H  H  L  L  L  L  L
00:00:04    L  H  L  L  L  L  L  L

ausgegeben wird, dann kann man den Palm zur Seite kippen und sich den
zeitlichen Verlauf schon einigermassen anschauen. Das würde IMHO für
einen ersten Prototypen schon genügen.

Für meine ersten Experimente muss bei mir ein MSP430F149 herhalten,
welcher zweifelsfrei überdimensioniert ist (IO). Das ist der einzige
uC, den ich ein wenig kenne, ich komme halt mehr aus der Software-Ecke.
Zur Beschaltung werde ich also nicht all zu viel beitragen können.

Just my 2 cents

Tom

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
übertragt doch einfach daten und einen netten header...

z.b
timebase:1m
inputs:blah-bits
...

und dann die daten als block..
ggf. auch binär und nur die änderungen damit man auch langsame
übertragungen schnell samplen kann (=>timingfehler suchen)

ist programmtechnisch kein prob...

zur pc-soft.. man schaue sich die la-soft-seite an... ;) da bei der
diskussion gibts einen netten hinweis... falls mal eine funktionierende
hardware haben sollte werde ich gtkwave anpassen...

73

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tom
natuerlich koennte man die werte auch in "sonderformaten" aus dem mc
rausschicken, allerdings ist das reinste verschwendung an bandbreite.
um ein bit zu uebertragen, waeren dann 2 ganze byte noetig. das halte
ich dann doch fuer eher unwirtschaftlich. da es aber softwaretechnisch
auf dem mc kein problem darstellt(und die maximale speichertiefe
sowieso bei 1-4k liegt) kann man das wegen mir zusaetzlich
implementieren.
einen msp zu benutzen sollte kein problem sein, da sich die hardware
wohl auf spannungversorgung(batterie/akku?), mc, eingangstreiber und
max232 beschraenken wird. ob die software einfach portierbar sein wird,
kann ich leider nicht sagen, da ich den msp nicht kenne.

@Hans
so oder aehnlich hatte ich mir das protokoll auch vorgestellt.
im labornetzteil-artikel gibt es ein beispiel, wie man sowas
konstruieren kann.
die "diskussion" zur la-software habe ich schlicht uebersehen.
natuerlich waere es genial, einfach bestehende software um einen
"treiber" zu erweitern. man muss das rad ja nicht mit aller gewalt
neu erfinden wollen. allerdings hatte ich da nur die hier entwickelte
la-software im sinn, die ja definitionsgemaess universell sein soll und
leicht an verschiedene hardware angepasst werden kann. da es aber im
artikel schon lange keine updates mehr gab (ich gebe zu, dass ich die
verschiedenen threads zum la nicht mitverfolge) bin ich davon
ausgegangen, dass die sache sich im sande verlaufen hat.
wenn du bereit waerst auch einen gtkwave-treiber fuer den palm-la zu
schreiben, schlage ich vor, dass du dazu ein paar worte im wiki
schreibst und vielleicht auch ein sinnvolles (mit dem "echten" la
gemeinsames?) protokoll vorgeben kannst. wichtig waere eine abfrage,
welche features der la hat(max kanaele, sampleraten, usw.), damit
flexible hardwareloesungen moeglich sind.

gruss, bjoern.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei richtigen la wirds so wie ich das mitbekommen hab erst ein protokoll
geben wenn es hardware gibt => es muss zuerst mal ein komplett
durchkontrollierter core fertig sein... kann also noch dauern...

im prinzip sollte das aber kein problem sein, da die "driver" in
gtkwave eigentlich sehr ähnlich ausfallen dürften... solange die daten
über die serielle wandern... oder eben über den ftdi...

interessant wäre eine autobaud-funktion wobei ich mir noch nicht sicher
bin ob das der la können soll oder die soft am pc...

was mir da an protokol-spec einfallen würde wäre folgendes...

get blah
gibt blah zurück (kann baudrate,version,features,timebase,data oder
status sein)

set blah
wie oben.. version,features und status sind aber nicht schreibbar ;)

startsampling
startet sampling vorgang..

beim status soll zurückkommen was denn gerade so los ist.. z.b
sampling, idle, fail

die timebase würde ich als zahl + prefix der einheit übegeben... z.b
100n für 100ns, 1u für 1µs... oder eben nur 1 für 1s ;)

get features gibt einfach eine liste aus.. z.b

max_sampling_timebase 1,min_sampling_timebase 100n,channels
8,bytes_per_sample 1

der version string ist nicht allzuwichtig.. falls aber jemand mods
macht sollte das auch irgendwie erkennbar sein...

mein vorschlag: SimleLA Major.Minor.build [küzel des codemassakrieren
+rev oä] [küzel des nächsten codemassakrieren +rev oä]

beginnend bei "SimpleLA 0.0.1" bzw wenn ich böse war und 2 patches
gemacht hab "SimpleLA 0.0.1 HW1 HW2"

dann weis jeder was los ist und beim supporting ists auch einfacher
wenn man sieht was da für eine firmware jetzt tatsächlich läuft G

das wär alles was mir bis jetzt so einfällt... wenn das "protokoll"
etwas diskutiert wurde schreib ichs ins wiki...

73

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
autobaud:
waere zumindest auf dem palm recht umstaendlich, da man dann nicht mehr
auf die API zurueckgreifen kann. es ist zwar vorgesehen, eigene
"treiber" fuer die serielle zu schreiben, finde ich jedoch overkill,
weil es sowieso darauf hinauslaeuft 115200baud zu benutzen. und da die
datenmenge ja ueberschaubar bleibt, sollten auch ftdi-nutzer mit dieser
geschwindigkeit klarkommen. ich will dich jedoch nicht daran hindern, so
etwas pc-seitig zu implementieren. falls es dann aufgemotzte versionen
mit mehr sram gibt, wird das bestimmt interessant. andererseits sollte
sich mit "kompression" einiges wieder rausholen lassen.

protokoll:
es kommt fuer mich so rueber, als wolltest du die befehle plain-text
uebertragen. das waere zwar debug-freundlich, da per terminal
benutzbar, in der auswertung jedoch recht umstaendlich. deswegen
schlage ich folgende struktur vor:

es werden immer 4+x byte uebertragen. das erste byte ist reserviert;
das zweite enthaelt die befehlsart(get, set, get_database,
set_database,..); das dritte enthaelt den eigentlichen befehl; das
vierte eine weitere differenzierung des befehls; 5-n sind dann die
daten. hat den vorteil, dass man mit ein paar switch- und
if-konstrukten die komplette auswertung machen kann.

koennte ungefaehr so aussehen:
0            1            2             3            4...n
reserviert   befehlsart   befehl_high   befehl_low   daten

byte1:
0x00-0x0F get la
0x10-0x1F set la
0x20-0x2F get palm
0x30-0x3F set palm

byte2:             byte3:        byte4-n:
0x00 hw-version
0x01 sw-version
0x10 timebase      0x00 s        uint16_t
                   0x01 ms       uint16_t
                   0x02 ns       uint16_t
0x11 trigger       0x00 "OR"     uint8_t mask,uint8_t value
                   0x01 "AND"    uint8_t mask,uint8_t value
                   0x02 "toggle"

zb
00 00 01 00              get sw-version from la
00 10 10 01 00 0A        set timebase to 10ms on la
00 10 11 00 05 01        trigger if channel 0=TRUE or channel 3=FALSE

ich hoffe man kann dieses wirrwarr entziffern und versteht, wie ich das
meine. muss allerdings noch ausgereift werden, da zb "get timebase from
la" ja keine unterscheidung zwischen s, ms, ns braucht, dafuer aber
mehrere werte zurueckgeben soll, die ausgewertet werden wollen.
vielleicht waere auch ein antwort-protokoll sinnvoll, ansonsten waeren
das nur die reinen daten ohne header.

habe gestern angefangen meinem palm, bzw dem emulator die serielle
kommunikation beizubringen. bin dabei auf folgendes problem gestossen:
der palm verhaelt sich so wie es sein soll, ich sende was, es kommt was
an. der emulator verhaelt sich jedoch recht zickig; wenn ich was sende
landet das in irgendeinem buffer und bleibt da auch. wenn man dann ein
anderes serielles prog startet(ptelnet in dem fall) und dort etwas
sendet, dann wird mit einem schlag der buffer + die neuen daten
uebertragen. habe dann den palm-api befehl zum buffer flushen
ergaenzt(was beim hardware-palm nicht noetig war), bringt aber auch
keine verbesserung.
os: gentoo x86
pose: v3.5 (binary aus debian/sarge kopiert)
rom: platform41_Vx_full_eng
(wer mal software fuer palm geschrieben hat, weiss, dass das programm
99% der zeit auf dem emulator getestet wird und erst wenns fertig ist
auf den echten palm kommt)

gruss, bjoern.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja.. soo umständlich ist es auch wieder nicht ;)

nur etwas speicherlastiger...sollte aber nicht das problem sein
glaubich....

vorallem wenn man am avr transitional time analysis implementiert...

ob ich jetzt in einem char-array bits fischen tu oder mir mit strtok oä
den string zerpflücke ist mehr oder weniger wurscht...

wichtiger sind so kleine definitionen wie trigger.. die hätt ich wieder
mal untern tisch fallen lassen ;)

73

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
denkfehler: das autobaud ist sinnvoll, gehoert dann aber auf den mc.

hat sich eigentlich schon jemand gedanken um die programmierung
desselben gemacht? bin leider zu unerfahren um sowas effizient zu
programmieren. ausserdem sollte das ganze moeglichst resourcenschonend
sein, da ja der groesste teil des srams fuer die daten gebraucht wird.

gruss, bjoern.

(leicht offtopic, da gegen die anforderungen verstossend:
externe sram-erweiterung schonmal grundsaetzlich im hinterkopf zu haben
ist dabei sicher nicht schlecht. wie siehts da eingentlich mit der
geschwindigkeit von dem xmem-interface aus? brauchbar?)

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ich so im hinterkopf hab ohne waitstates möglich... das wär nicht
das problem.. im übrigen wäre die verwendung eines lpc21xx vllt auch
nicht schlecht ... wenn man den sram betrachtet ;) wies da aber
ausschaut mit polling speed... eher schlecht als recht jenn ich das
richtig im kopf hab...

das ist aber meine geringste sorge muss ich zugeben... zumal es ja in
der codesammlung auch ein bsp für dram gibt ;)

unter mega128 wirds eh nix werden.. 1k reservier ich einfach mal für
die firmware... der verbleibende rest ist zwar nicht allzuviel aber
wenn man keine redundanten daten speichert dürften 1k samples
(transitional time analysis) schon überbleiben... und 1000
zustandsänderungen sind doch eigentlich schon mal ein guter anfang wenn
man z.b i2c sniffen will  ;)

73

Autor: Bjoern Mueller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also meiner meinung nach kommen nur die im wiki genannten controller in
frage, da als dip erhaeltlich. nicht, dass ich mich davor scheuen
wuerde doppelseitige platinen zu aetzen und TQFPs zu verloeten, aber
das kann halt nicht jeder. und meiner meinung nach soll es ein
"volks-la" werden. ansonsten wuerde ich sowieso nen cpld+cacheram aus
nem alten motherboard bzw vllt einen SAM7 nehmen, da ich mir den
demnaechst mal genauer anschauen will. dass die AVRs nur sp "wenig"
ram haben, ist mir allerdings auch erst aufgefallen, als ich die
controller rausgesucht habe.
einzig akzeptable(lochrasterfaehige) loesung stellt meiner meinung nach
das xmem-interface dar.

gruss, bjoern.

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so, grade reichelt-bestellung rausgeschickt. atmega8515+adresslatch war
auch dabei. und soweit ich das auf die schnelle aus dem datenblatt
rauslesen konnte(oder eben grade nicht), macht es von der
geschwindigkeit keinen unterschied, ob interner oder externer ram
verwendet wird. ich kann mich also beruhigt wieder auf die
programmierung des palm stuerzen, ohne im hinterkopf zu haben, wie
unbrauchbar das ganze am ende wird.
leider muss ich am wochenende sehr viel fuer die fh machen, mal sehen
wieviel zeit da noch fuer das projekt bleibt.
als erstes steht wohl nochmal grundsaetzliche planung, datenblaetter
waelzen, protokollentwicklung und vorversuche auf dem programm, damit
sich das chaos in grenzen haelt.

gruss, bjoern.

Autor: dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich verweise mal auf
http://www.mikrocontroller.net/forum/read-4-121457.html ;)

ein grundsätzliche frage wäre tatsächlich der speed... im prinzip ist
man doch sehr eingeängt mit den 16Mhz vom AVR... bei 16Mhz sollte der
dram zugriff 1-2us dauern (laut thread von oben)... sagen wir mal wir
bräuchten 2us für einen zyklus... => 500khz max sampling rate...
verfünftig... im prinzip dauerts dann 4s bis der ram voll das probem,
das entsteht.. die refresh zyklen... die sind böse ...

andere alternative... etwas ttl, sram und etwas mehr fläche ;)

74HC4060
einen netten 8 oder 16k sram
und einen schnellen latch..

der 4060 kann max 87Mhz ;)
weils nachbaubar sein soll... sram der günstig ist.. 3-5e bei 12-50ns
zugriffszeit => 20-83Mhz max sampling rate.. also auf jeden fall
schneller als der AVR takt generiere kann... => 0815latch sollte auf
jeden fall reichen...

den avr lässt man dann einfach nur toggeln.. das sollte eigentlich mit
8Mhz möglich sein...wobei dann müssten 16k im flash nur getoggle sein..
also eher um die 3mhz max.... da könnte man aber mit etwas ttl.. noch
was machen.. sprich noch einen lustigen 4060 hernehmen und den mit
einem z.b 64Mhz oszillator paaren ;) => 15 timebases von 64Mhz bis
3,6KHz... dazu noch ein bisserl mehr logik um die jeweilige timebase
auswählen zu können...

naja... kingt gut aber aufwendig... aber die zähler-sram kombination
dürte der einfachste weg sein schnell zu samplen.. ich würde sagen
80mhz sind sicher drinnen.. taktgeneration muss noch überlegt
werden...

der avr kann dann richtig niedlich sein ;)

ich würde sagen 5e für ram, 5e für avr und 5e für den rest
(max232,spannungsversorgung,75hc4060,..)

viel billiger dürfte es nicht machbar sein...

ich bin mal für ein irc meeting... wann ist denn wer von euch so im irc
???

73

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
für die, die das oben etwas zu wirr finden...

http://www.avrfreaks.net/index.php?module=FreaksTo...

timebase-generation muss ich mir noch überlegen...

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<buhmannmode>
auch auf die gefahr hin mich unbeliebt zu machen, muss ich das mal so
klar sagen: wir sollten auf dem teppich bleiben! fliegen koennen wird
der LA aus dem "richtigen" LA-projekt.
nicht ohne grund werden da so sachen wie perfektes(doppelseitiges oder
besser eigentlich vier-lagiges) layout, hoher schaltungsaufwand, aktive
probes, riesige cplds und was sonst noch noetig ist, um auf akzeptable
sampleraten(>50Mhz) zu kommen, ohne dass ein "cat /dev/urandom" in
etwa das gleiche ergebniss liefern wuerde.
die wuerden dumm gucken, wenn wir aus bauteilen fuer unter 20euro mal
eben einen 80mhz la auf lochraster herzaubern.
</buhmannmode>

dram waere zwar schoen gross, aber wie ja schon erwaehnt mit 1-2µs doch
recht langsam. hinzu kommem die refreshcycles(oder sind die in der
rechnung vllt schon drin?).

im vergleich dazu(ich kann nicht wirklich assembler):

[lade endadresse des ram zu vergleichen]
loop:
  in tmp, port                      1cycle
  (store with increment)            2cycles
  cmp aktuelleadresse, endadresse   1cycle
  brne loop                         2cycles

unter der vorraussetzung, dass der externe ram in 2 zyklen angesprochen
werden kann, und unter nichtbeachtung, dass die adressen wohl
16bit-werte sein muessten, kommt man bei 14Mhz takt auf knapp ueber
2Mhz. (man koennte ja nur das high-byte vergleichen und auf die letzen
256 werte aus dem low-byte verzichten-->ich hoffe man verstehts).
aber wiegesagt, ich bin nicht erfahren genug um sowas auch in der
praxis effizient umzusetzen.

bleibt noch die frage nach dem ripple-counter. war auch mein erster
gedanke, um die samplerate hochzujagen. hat nur einen kleinen
schoenheitsfehler. woher weiss der counter respektive die taktquelle,
wann es losgeht mit dem samplen? sprich triggerung ist dann nicht mehr
moeglich. klar koennte das der avr machen, nur halt nicht so schnell.
also triggerlogik+counter in nen cpld packen und schon sind wir wieder
bei smd-bauteilen und weitaus hoeherem aufwand.

insgesamt waere ich mit 1-2mhz und 16-64kb speichertiefe mehr als
zufrieden. das ist mit "einfachsten" mitteln moeglich, stellt keine
grossen anforderungen an das platinenlayout(ob lochraster die 2mhz
mitmacht, muessen experimente zeigen; denke aber schon) und sollte
erstmal realisiert werden(was schon aufwand genug ist).
da das protokoll aber offen liegt, steht es jedem frei spaeter auf
dieser basis diverse hardware zu realiesieren(pimp my la).

so, genug meinen standpunkt vertreten, diskussion erwuenscht, gruss
bjoern.

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
saetze die grammatisch keinen sinn ergeben, bitte selbstaendig sinnvoll
ergaenzen.

ach ja, im irc bin ich 24/7, einfach meinen nickname schreiben, bekomme
dann ein akkustisches bing.

gruss, bjoern.

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kurzes update:

hardware:
es hat ein langer core-entwickler-chat stattgefunden. dabei wurde sich
auf eine vorlaeufige hardwareversion geeinigt. erste prototypen sind
realisiert worden. kleines wiki-update zur software.
palm:
nichts neues. der emulator weigert sich immernoch sich so zu verhalten,
wie er soll.

gesucht wird noch ein erfahrener avr-programmierer mit asm-kenntnissen
um das letzte aus dem avr rauszuholen.

weitere wiki-eintraege werden im laufe des wochenendes folgen.

persoenliches fazit: so langsam nimmt die sache form an.

gruss, bjoern.

Autor: fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Bjoern Mueller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kurzes lebenszeichen von mir.

die emulatorprobleme sind zwar laengst geloest, aber die zeit noch
knapper geworden. sowohl palm-soft als auch mein prototyp gammeln seit
meinem letzten eintrag vor sich hin und warten drauf, dass es weiter
geht. das projekt ist aber keinesfalls untern tisch gefallen. einzig
der zeitplan wird noooooch weiter gedeeeeehnt.

@Hans:
gibts bei dir was neues?

gruss, bjoern.

Autor: Frank S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Björn,

gibt es schon was Neues? Kann man evtl. schon mal den Prototypen,
Schaltpläne, Quellcode oder irgendwas bestaunen?

Frank

Autor: Bjoern Mueller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aufsdatumvomletztenpostschau
Wie doch die Zeit vergeht...

Leider gibts immer noch nichts neues. Das Projekt liegt erstmal auf
Eis, bis ich wieder mehr Zeit habe. Wird aber auf jeden Fall noch
realisiert.

gruss, bjoern.

Autor: Frank S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Björn, Hans und alle anderen,

könnt ihr nicht mal die vorläufigen Stände Eurer Arbeit hier posten.
Vielleicht findet sich ja der ein oder andere, der das dann aufgreift
und ein paar Dinge dazu beiträgt.

Frank

Autor: Ich Bin (ichbin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eingeschlafen?

Autor: AVRNIX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibts schon was neues oder ist das Projekt gestorben?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.