Hallo Kurzurlauber !
Danke für die Ausführungen - also seid ihr ganz normale Studenten - meinst etwas, wo anders ists viel besser (gewesen) ...
> aber nicht, wie man sowas entwickelt bzw programmiert.
Nun, als Student lernt man Probleme zu lösen .. lernt zu Wissen wo die wichtigen Informationen stehen .. die Fächer sind alle nur Schein (in doppeltem Sinn)
Mein Werdegang war Ausbildung zum PhyTA, Bw, Studium Nachrichtentechnik .. dann zwei Jahre Project Auditing bei VEBA OEL und danach selbständig als Softwareentwickler .... im Studium gings mir so ähnlich wie euch, trotz FH, vorher gabs Basic und Asm .. später TurboPacscal und Modula und wieder pascal .. nur irgendwann war mir das geschreibsel zu viel und hab eben selbst Zeh gelernt und später lange gebraucht, die Vorteile von OO/C++ zu kapieren .. und heute ists ein C/C++-Gemisch auf Windoof-Ebene (nein keine MSKotzWerkzeuge) und Zeh auf uC
Solange Du nicht Asm aufm uC machst, ist C die bessere Wahl, weil Du richtig schöne Fehler machen kannst, die Dir Basic verwehrt
Und eben sehr effizienten Code schreiben kannst .. Kenner wissen, C ist eigentlich eine Mischung aus Aprilscherz und Macroassembler
Im Endeffekt ists nur das Werkzeug und hat nichts damit zu tun, ob man programmieren kann, das "Können" ist aus meiner Sicht was anderes ....
> In C (NICHT C++!) war das letzte, was wir programmiert
> hatten, ein Taschenrechner und ein Adressverwaltungsprogramm
> (natürlich nur Darstellung auf CMD-Ebene).
Na ist doch prima !!!
> µC-Programmierung hatten wir auf dieses Jahr zwar etwas gelernt,
> aber das war ein Schnellkursus in einem Zeitrau von 18
> Schulstunden a einer 3/4 Std (80C517A), wo wir grad mal Timer
> und Display gelernt haben.
Nun für euer Project müßt ihr nunmal uC entwickeln und programmieren - wie gesagt, C ist da nur ein Werkzeug, Timer, Interrupts und Co sind die Basis ... und von C brauchste nur Schleifen und Bedingungs-Abfragen verschiedener Art (if, switch/case) oder eine Mischung daraus
Was bei C haarig sein kann, ist die Verwendung von Pointern oder Referenzen ... aber einmal kapiert, nie wieder Basic ! (bitte an Basic-Menschen, nicht hauen)
> ganz easy auf einem 16Bit µC mit DSP das Programmieren
> und Filterdesignen lernen!
geil !
> .. bei einem 12Bit A/D-Wandler 4096 das Datenwort ist,
> welches als 32Bit-Wert über die UART übertragen wird!!!
ja macht Sinn .. dann muß man auf Windoof-Ebene nicht drüber nachdenken, was man tut
> "Macht's einfach". Nur meine Meinung ist, wenn man
> nicht zumindest ein paar Grundlagen auf den Weg
> mitbekommt, wofür geht man dann eigentlich in eine
> Schule?!? Dann kann man sich ja alles im Selbsttudium
> beibringen, oder???
wie denn - ohne die aus Schüler/Studentensicht fiesen Aufgaben würdet ihr euch doch garnicht damit auseinander setzen
Übrigens später im Berufsleben macht ihr ständig Diplomarbeiten !!!
Die uC - Schnittstelle von Funkübertragung zu PC macht durchaus Sinn !
Außer ihr würdet eben WLAN nutzen.
> wir sollen uns erst mal erkundigen, ob über unser Modul überhaupt
> fähig ist, CAN zu übertragen, bzw ob dies überhaupt funzt.
Thema ist hoffentlich abgehakt, CAN ist wiegesagt ein Baustein-Protokoll für Kabel wegen Kabel-Verhalten ... mit dem Vorteil gegenüber z.B. RS232, daß die "Kabelbedingungen" angepaßt werden können. Na gut, es nimmt einem auch "Arbeit" ab ...
> Und nachdem ich nach stundenlangen Googeln nichts
> brauchbares gefunden hab, hab ich mich an euch ans Forum
> gewendet.
brav
> EKG wird mit 300 Hz abgetastest, bei einer Grundfrequenz
> (normaler Herzschlag) von 1Hz werden ca alle 3,33ms ein
> Datenwert übertragen.
> Wird das Ergebnis 12Bit A/D gewandelt, ergibt:
> (12 Bit/ 3,33ms)x1000= 3604 Datenbits/ sec, natürlich
> ohne die restlichen Bits, welche zu einem vollständigen
> Protokoll noch dazukommen.
bei 19200 Bit per sec ist da noch Luft !
Aber ich verstehe das noch nicht so richig .. EKG mit 3 1/3 ms abgetastet. Ist EKG nicht etwas mit mehreren Elektroden an verschiedenen Stellen des Körpers ? ... Oder nur der Puls ? ... Ähm ... Grübel ...
Gib mal mehr Input ...
Und generelle Frage, kann nicht eine Vorverarbeitung der Werte im uC erfolgen ?
Zur Info eine Messung A/D dauert beim ATmega128/16MHz maximal 200 usec ...
> Da das ER400 über Luft nicht besonders schnell ist (19200 Baud fix),
habs ergoogelt- die 19200 sind nicht fix ! Der Defaultwert ist änderbar. Aber es gibt beim Modul scheinbar Probleme mit der Betriebsspannung verschiedener Chargen ... fragt mal Dr. Google
öhm .. sind 19200 Baud - sind die Bauds nicht den Bits gleichzusetzen - und nicht gleich 2400 Bytes pro sec ? Sprich 1 Byte in ca. 500 usec ?
>deswegen war auch die Rede von einem Zeitstempel, falls
> doch ein eigenes Protokoll notwendig.
zum Thema Protokoll sag ich noch was ...
> Es waren auch schon Überlegungen, da das FM zehn Kanäle hat,
> jeden Sensor auf einem anderen Kanal zu betreiben (Master
> müsste halt dann immer auf den betreffenden Kanal wechseln),
> aber ob das Sinn macht???
Kurzfassung - vergiss es !
Der Master muß die einzelnen Slaves nacheinander abfragen - folglich müssen die Slaves Werte zwischenspeichern ...
Nicht jeder Slave liefert ja EKG-Werte - oder ? ... sprich nur Pulsmessungen etc. können auf die Slaves ausgelagert werden und müssen dann nur minimal Daten übertragen.
> Wegen den EMV-Bestimmungen, das haben mein Kollege und
> ich immer wieder erwähnt, was damit ist, aber da hats nur
> geheißen, das ist daweil nicht so wichtig, darum brauchts ihr
> euch noch keine Gedanken zu machen.
jeinörgl. ... schon klar, soll ja kein Produkt für den Markt werden sondern eine Studie
> Unser Grundgedanke war, da HF-frequente Strahlung im GHz-Bereich
> nicht die gesündeste ist, nehmen wir halt ein FM mit etwas
> niederfrequenterer Strahlung. Bluetooth, WLAN und Co, sind
> zwar gesetzlich nicht verboten, aber es ist halt daweil eine
> graue Zone, solange nichts passiert. Bestes Beispiel: DECT! In
> allen Krankenhäusern installiert, aber 1000 x gefährlicher als GSM.
Nun zu EMV und Co könnte ich jetzt meine Meinung schreiben ... FM .. 70cm-Band ist da auch schon nicht zu verachten !!
Aber für euer Project wohl unrelevant !
Egal was ihr wählt ! Ode reben gewählt habt !
>> Dewegen VB.
Argl .. macht was ihr wollt - ich hasse nurmal WinzigWeich und lehne auch VC ab ! ...
Auf Windoof-Ebene progge ich mit Compiliern von Borland seit dem Turbo C für den Atari
> Wegen bewegten Objekten, schätz einmal, die sind per Funk nicht
> so gut zu erfassen, oder was meinst du damit!
jein .. da ihr den Probanten sicher keinen Helm mit Antenne drauf aufsetzt, hast Du bei all den Frequenzen mit möglicherweise mit menschlichen Hinternissen zu tun ...
.. und aus EMV-Gründen und im speziellen im medizinischen gehe ich davon aus, daß es da viel zu beachten geben würde ..
.. da ihr jedoch keine verkaufsfähige Lösung erstellt ist dies unrelevant.
So nochwas zum Thema Protokoll:
Also ein Datenprotokoll ist nichts anderes als eine Zusammenstellung von Daten, wie ich ja schon geschrieben habe. #<ID-Sender><ID-Empfänger><Datenlänge><Daten>#<Prüfsumme>
Abgesehen davon ist es wichtig, daß ihr die zu übertragenden Daten aber nicht aufbläht, also nicht nur long = 32-Bit - Werte, sondern bytes von 0xFF als Inforamtion ausreicht ..
Die Prüfsumme kann ein CRC-Wert sein - dieser Wert wird mit übermittelt - so kann auch der Empfänger über die Daten ein CRC machen und mit dem übertragenen Wert vergleichen. Die Prüfsumme wird jeweils über den mit # begrenzeten Bereich ermittelt !
Ich bevorzuge Daten im ASCII-Format, so daß man mit einem normalen Terminal die ankommenden Wert auf RS232 / PC - Ebene mit einem Terminalprogrammm sehen kann. Zumindest in der Debugphase ist das sinnvoll!
ACSII kann man auf PC-Ebene wie auch uC - Ebene schön einfach wieder in die Bestandteile zerhacken (strtok, strchr) ....
in C geht das mit schön effizientem Code .. auf uC und PC identisch.
Wobei ich keine Ahnugn habe, ob es ein "strtok" in Basic gibt ...
Der Master spricht die einzelnen Slaves mit ihren Adressen an und erwartet eine Antwort innerhalb eines Zeitfensters .. kommt diese nicht, muß er entweder sofort wieder abfragen und/oder feststellen Kommunkation ggf. gestört ist ...
Da der Master ja mehrere Sensormodule abfragen soll, darf ein Fehlen von Daten eines Moduls nicht zur Blockierung des Systems führen.
Der Master könnte bei seiner Abfragesendung an das Modul auch eine Zeitinformation mitsenden - oder
ihr setzt einfach einen Zähler - int-16bit-bereich reicht und dieser Wert muß wieder zurückgegeben werden ... das kostet weniger Bytes als ein voller Zeitstempel .. und kommt dem gleich ...
So genug Text,
helfe gerne weiter ..
LG
Vajk
Zitieren
Lesezeichen