Vielleicht kann mir jemand helfen. Für ein Demoprojekt suche ich einen
Programmierer der mir für den Philips (NXP) LPC eine Software schreibt
mit der Daten auf eine SD Card geschrieben werden. Diese sollen später
am PC ausgelesen werden.
Alles weitere unter dreibein@gmx-topmail.de
"Der Philips (NXP) LPC" kann irgendwas sein.
Es gibt einerseits mehrere ARM-Derivate mit ARM7 oder auch Cortex-Kern,
aber auch MCS-51-Varianten, und die heißen alle LPC irgendwas.
Du solltest Deine Frage daher etwas präzisieren.
@ Peter Dannegger
Das so etwas "Mannmonate" braucht kann ich mir nicht vorstellen. Es ist
doch eine Standardsache. Gibt es nicht Vorlagen die auf einen Prozessor
angepasst werden können?
Man nehme ein kleines RTOS, mache den Speicher-Footprint klein. Fertig.
Dauert vielleicht, mit allem drum und drann, 8h, ist aber alles andere
als Speichereffizient.
Viele Grüße,
Martin L.
Martin L. wrote:
> Man nehme ein kleines RTOS, mache den Speicher-Footprint klein. Fertig.> Dauert vielleicht, mit allem drum und drann, 8h
Bestenfalls, wenn Du schonmal SD-Karte + FAT komplett zum Laufen
gebracht hast und "nur" auf ein neues Projekt anpassen mußt.
Und natürlich ne bereits laufende LPC-Toolchain hast.
Ansonsten fallen die 8h unter die Rubrik Fabeln und Märchen.
So von Null an nen LPC mit Toolchain einrichten, benutzen lernen und bis
zu Deinem ersten Interrupthandler (Blink-LED) sind 2 Tage realistisch.
Programmieren ist harte Knochenarbeit. Die Sachen sehen hinterher nur so
einfach aus. Aber man muß erstmal darauf kommen, wie es geht.
Programmierer haben den Hang zur Blauäugigkeit und geben nie auch nur
annähernd die Hälfte der realen Stundenzahl an.
Daß man sich alles ausm Internet saugen kann und einfach nur zusammen
kopieren muß, ist auch nur ein Märchen.
Peter
@alle
Danke für eure Hilfe aber leider kann ich mit den Antworten nichts
anfangen da ich vom programmieren keine Ahnung hab.
@peter
Du hast sicher recht wenn es darum geht etwas "von scratch" zu lernen.
Eine SD Card ist aber Standard, meine Hoffnung ist jemanden zu finden
der so etwas schon mal gemacht hat.
Es geht mir auch nicht darum etwas umsonst zu bekommen, "mehrere
Mannmonate" sind aber in dieser Phase nicht finanzierbar.
>Eine SD Card ist aber Standard, meine Hoffnung ist jemanden zu finden>der so etwas schon mal gemacht hat.
Standard im PDA oder Handy. Bei uC wohl noch nicht ganz.
Die Dinger haben ganz unangenehme Eigenschaften.
Je nach LIB, die man durchaus fertig finden kann, könnte
es da erhebliche Probleme geben.
Interessant wäre z.B. mit welcher Datenrate geschrieben
werden muß.
Verrate doch mal noch ein paar kleine Details.
> verrate doch mal noch ein paar kleine Details.
Gern: An einem Fahrzeug sollen Posistionsdaten (GPS) und ein paar
interne Variablen aufgezeichnet werden (Drehzahl Verbrauch usw). Dazu
noch ein paar Umweltdaten (Temperatur, Luftfeuchte, Niederschlag und
Luftdruck)
Das ganze wird nach getaner Arbeit auf einem PC ausgewertet.
Oh ha---- das ist alles andere als Trivial wenn die Daten tatsächlich
über den Fahrzeug-Can ermittelt werden sollen. Hab meine Diplomarbeit zu
einem sehr ähnlichen Thema geschrieben. Und lass dir sagen: An die
CAN-ID's der gewünschten Größen wirst du nicht dran kommen.
Für den Fall, dass die Daten direkt und ungefiltert auf SD geschrieben
werden sollen, wirst du recht schnell Probleme mit der
Schreibgeschwindigkeit bekommen.
Auch wenn es jetzt blöd klingt: Noch ein paar Infos wären super (nämlich
wo du die Daten herbekommst: CAN oder wo anders her)
Viele Grüße
Sören
> Auch wenn es jetzt blöd klingt: Noch ein paar Infos wären super (nämlich> wo du die Daten herbekommst: CAN oder wo anders her)
Es sind mit Sicherheit keine Can Daten (es gibt dort keinen Can Bus),
die Daten kommen seriell aus einem anderen Gerät (und einem GPS
Empfänger).
Grüße zurück
Dreib. d. II
> Du hast sicher recht wenn es darum geht etwas "von scratch" zu lernen.
Wenn du mit einer Hardware perfekt umgehen kannst und nur SD
und Filesystem implementieren musst, dann ist das immer noch viele
Wochen Arbeit bis das halbwegs zuverlaessig laeuft.
Wenn es richtig zuverlaessig sein soll, also z.B mit jeder SD-Karte
die irgendjemand mal anschleppt und die mit den eigenartigsten
Vorsteinstellungen formatiert ist, dann koennen Jahre ins Land gehen
bis der Code laeuft.
> Eine SD Card ist aber Standard, meine Hoffnung ist jemanden zu finden> der so etwas schon mal gemacht hat.
Du kommst nur billig weg wenn du diesen Standard kaufst! Also jemanden
fertigen Source abkaufst und den implementierst. Aber da kann man
durchaus
noch Arbeit reinstecken bis das rund laeuft und an die eigenen
PRoblemestellungen angepasst ist.
Richtig billig wird es nur wenn du Hardware und Source kaufst. Und
aus genau dem Grund sind z.B Rechner mit Linux drauf so beliebt. Weil
dann
all diese Sachen wie Speicherkarten, Netzwerk usw. einfach so laufen.
Warum glaubst du wohl warum selbst grosse Firmen immer mehr auf
Linuxfirmware fuer ihre Hardware (z.B Router oder NAS) umsteigen?
Die haben nicht die Kapazitaeten sowas noch selber zu programmieren.
Olaf
Sören H. wrote:
> Fehlt halt nur noch jemand, der sich damit auskennt ;-)
Das vermute ich auch.
Man darf nicht davon ausgehen, daß alles, was zu Millionen in
Konsumgütern verkauft wird, auch offengelegt ist und frei verfügbar.
Leute, die professionell MP3-Player usw. programmieren, werden wohl
schwer ihren Code einfach so rausgeben dürfen.
Aber im Hobbybereich ist SD-Karte und Filesystem keine "Standardsache".
Und nirgends steht, daß "Standardsachen" automatisch auch einfach sein
müssen.
Die meisten Logger im Hobbybereich schreiben die Datenrecords direkt in
einen EEPROM oder Flash und nudeln es dann später über die RS-232 raus.
Per Terminalprogramm in ein File geschrieben, fertisch.
Peter
Wetten das geht doch in 15 min ;-). Lad dir ne Kickstartversion von IAR
runter, da sollte auch ne Trialversion vom PowerPack dabei sein (das ist
halt der Kram von SEGGER). Da sind ne Menge fertige BSPs drin unter
anderem auch für deinen LPC. Zumindest mal, um schnell was machen zu
können, ist das nicht verkehrt. Letzlich müsste man die Software
natürlich dann von Segger kaufen, weiß nicht, ob du Geld investieren
willst oder ob das ein reines Hobbyprojekt ist.
soo... um noch mal auf meine Diplomarbeit zurückzukommen:
Auch ich wollte Daten loggen (zwar vom CAN-Bus, aber das ist ja erstmal
egal). Vom Prozessor her war ich nicht gebunden und hätte 6 Monate Zeit
gehabt. Nach dem ich mich intensiver mit der Geschichte auseinander
gesetzt hatte, habe ich festgestellt, dass in der Zeit max. eine
"unformatierte" Lösung drin ist. Also einfaches hintereinander schreiben
an die jeweils nächste Speicherstelle auf der SD. Dann kannst du die
Daten natürlich nicht so einfach auf den PC schieben.
Lange Rede kurzer Sinn: Ich hab es sein gelassen und bin auf einen PDA
umgestiegen (mit CAN-Bluetooth-Schnittstelle). Möglicherweise macht eine
PDA-Lösung für dich ja auch Sinn: Daten per Bluetooth an PDA senden und
dann da loggen?
Solltest du die Möglichkeit haben auf AVR umzusteigen: Dafür gibt es im
Netz schon mehrere Lösungen (die aber möglicherweise nicht 100&ig
serienreif sind...)
Gruß
Sören
Erstmal vielen Dank für die vielen Antworten.
Langsam wird mir etwas klarer was ich da plane ;-).
Die Anwendung braucht keine x-beliebigen SD Cards, man kann eine Sorte
festlegen (nennt sich dann bei einigen Herstellern "nur zertifizierte
verwenden"). Insofern wäre es vielleicht etwas einfacher.
@peda
Wenn ich hier so lese was für ein Aufwand so ein Filesystem mit sich
bringt ist ein Terminal vielleicht wirklich die bessere Wahl. Da es LPC
sein soll kann man vielleicht eine kleine Karte bauen die loggt, die
SD-Card schreibt und seriell ausgibt
Dabei fällt mir ein:
Der LPC hat doch einen USB Device eingebaut. Kann man das nicht als
Stick gebrauchen und auf eine Flash Card ganz verzichten?
@sören
PDA scheidet leider aus (u. A. zu zu teuer wenn Sie robust sind und zu
kompliziert/fehleranfällig).
> Die Anwendung braucht keine x-beliebigen SD Cards, man kann eine Sorte> festlegen (nennt sich dann bei einigen Herstellern "nur zertifizierte> verwenden"). Insofern wäre es vielleicht etwas einfacher.
Ist nur einfacher wenn es sich um ueberschaubare Stueckzahlen und kurze
Produktlaufzeit handelt.
Ich hab z.B eine Anwendung wo mir eine 16MB Karte reichen wuerde, und
damit habe ich das auch mal entwickelt. Aber kauf die heute nochmal....
Olaf
Hallo Dreibein ...
Hallo Leute
hab mal geschaut was es so am Markt schon gibt, hier ein Vorschlag:
http://www.avisaro.com/html/sd_logger_modul__sd_.html
Wenn man dieses Modul als Grundlage nimmt, vereinfacht es den Rest der
Aufgabe ungemein. Ist nur als Tipp für andere gedacht, die von dem
SD-Card Handling abgeschreckt sind. Vielleicht lässt sich so leichter
jemand finden, der das Projekt angeht.
Gruß Microman
PS: Es gibt dort auch schon ein fertiges Gerät das Daten von RS232 via
Script in eine Datei schreibt, vielleicht auch eine Option?
"Dabei fällt mir ein:
Der LPC hat doch einen USB Device eingebaut. Kann man das nicht als
Stick gebrauchen und auf eine Flash Card ganz verzichten?"
Klar, brauchste halt ne USB Stack mit Mass Storage Device Class Treiber
und ein Filesystem. Also um das Filesystem kommste nicht dran vorbei,
wobei ja dann ein Filesystem im RAM reicht (RAMDISK), wennn du die Daten
sofort abholst.
Ich habe schon eine Datenlogger-Hardware mit einem LPC2368 aufgebaut,
anbei ein Foto davon.
Vorgesehen sind folgende Schnittstellen:
- Externe Stromversorgung bis 30V
- USB (Auch Stromversorgung über USB möglich)
- Netzwerk
- 2x Seriell V24
- 2x RS485 oder 1x RS485 + 1x LIN
- 2x CAN (Galvanisch getrennt)
- 1x SD-Card Slot (kann auch weiter aussen bestückt werden, so dass die
Karte von aussen gezogen werden kann)
- LCD Display
- SPI-Bus und I2C über 2,54mm Stecker
- Goldcap-Kondensator für die Uhr, damit kann 2 Tage Stromlos überbrückt
werden.
Also die Hardware währe für diese Anwendung bereits fertig...
Mit der Software bin ich noch nicht so weit, also gerade nehme ich
Netzwerk in Betrieb. Die SD Card funktioniert noch nicht.
Mit Bestückungsoptionen muss man natürlich die nicht benötigten
Komponenten nicht bestücken. Das Gehäuse ist das gleiche wie vom USB
Datenspion von http://binterm.mmvisual.de
Ich denke das wäre eine ideale Plattform für Ihre Applikation. Auch
sogar wenn Sie später einmal doch den CAN loggen wollen.
Derzeit befindet sich das Gerät im Prototypenstadium, Hardware
Anpassungen für Ihre Applikation wären also noch möglich
Hallo
Peter Danneger hat es ziemlich treffend vormuliert:
> Im Hobbybereich ist SD-Karte und Filesystem keine "Standardsache".> Und nirgends steht, daß "Standardsachen" automatisch auch einfach sein> müssen.
Damit du dir einen kleinen Überblick machen kannst, wieviel Arbeit das
gibt, kannst du mal nachsehen unter: http://arm.hsz-t.ch
Da bin ich gerade dabei das ganze zu Dokumentieren inklusive
Funktionierende Beispiele zu machen. Im Moment wird nur das lesen
Unterstützt, weil ich im Moment nur dies brauche. Eigentlich wollte ich
den Speicherverbrauch auf unter 100 Byte senken, pro geöffnete Datei.
Habe dann dies wieder verworfen, da es mit SDHC Karten keinen Sinn
macht. Es bremmst nur, ist aber möglich.
> Leute, die professionell MP3-Player usw. programmieren, werden wohl> schwer ihren Code einfach so rausgeben dürfen.
An dem verdient die Firma ihr Geld. Würden sie ihn rausgeben, währen sie
wohl bald pleite.
Eventuell ist dies aber noch interessant. Ich arbeite gerade daran, zu
erklären, wie TCP/IP funktioniert mit dem LPC2294 (mit Quellcode).
Einiges ist schon auf dem Internet, ist aber noch nicht so detailiert
beschrieben (http://arm.hsz-t.ch), der Rest kommt noch.
Sagen wir mal nur den Treiber zu portieren und läuft etwas nicht auf
Anhieb (was ja meistens der Fall ist) braucht man sofort Tage/Wochen,
weil man sich dann doch in die Thematik der Hardware einlesen muss. Das
verstehen, was die Hardware macht, ist dann was anderes. Kommt noch
dazu, dass man wissen muss, was sich der Ursprüngliche Programmierer
dabei gedacht hatte, als er den Code geschrieben hatte.
Gruss, D. Schwab
Vielen herzlichen Dank an alle die mir das Thema ein wenig näher
gebracht haben. Ehrlich gesagt hatte ich mir das ganze ein wenig
einfacher vorgestellt.
Gruß und danke nochmal
Dreibein der II.