jgmischke

Wie ich mir es gedacht habe. Meine eigenen Timer liegen in

SIGRTMIN bis SIGRTMAX. Im eigenen Thread blockiere ich damit nicht die bricks. Gut zu wissen!

Wie stark nutzt ihr denn eigene Threads? Und wie sind die Timer aufgebaut?

Nachdem ich mal ein paar Timer ausprobiert habe (timer_create) habe ich das dumpfe Gefühl, dass die Tinkermodule nicht mehr funktionieren. Welche Signale nutzt ihr denn oder bin ich da auf der falschen Spur?

Ist nicht weiter dramtisch, packe ich den Timer in einen eigene Thread sollte er die Bricks wohl nicht mehr stören.

EIne Ergänzung vielleicht für den bricv und Red Brick. Beim Überspielen von C-Programmen wäre es nett, wenn man noch ein eigenes ZIELVERZEICHNIS für die Dateien angeben kann. Also etwa -> Alle Dateien nach /home/test oder so.

Grund. Makefiles beinhalten meistens auch das Verzeichnis, in dem die Daten auf dem Originalsystem erstellt wurden. Also etwa /home/test/Projekt1/Makefile. Jetzt wird alles nach /home/tf gepackt, was dann aber nicht im Makefile läuft. So muss dann von Hand auf dem Red das ganze entweder auf /home/tf angepasst werden oder aber das /home/test/... wird manuell angelegt und dann das make dort gestartet. Geht jetzt auch, wäre aber um etliches einfacher, wenn man das Ziel mit eingeben kann.

Aber auch ein grosses Lob(!!) das ganze Tinkerforge System, ist sicherlich eine Heidenarbeit gewesen und was der kleine Rote so alles drauf hat ist schon beeindruckend. Es macht Spaß damit zu arbeiten und wer sich mit Linux/C auskennt, kann wohl erahnen, was da an Arbeit drin steckt.

Dafür meine Hochachtung!

Wäre sowas denn nicht interessant? Gut die Teile kosten einiges mehr, aber bieten auch einen grösseren Messbereich.

Also das ist jetzt eine "normale" SD, nichts besonderes. Aber wie beschrieben, wenn ich das ganze händisch mache, ist es auch in wenigen Minuten durch.

Das Resize liesse sich natürlich auch mit eingehängtem Dateisystem sofort durchführen, da hast du das ganze besser unter Kontrolle. Dann nur ein Reboot und das neue System muss nicht mehr warten. Vergrössern ist in der Regel unproblematisch. Aber auch so ist die Lösung wohl ok.

Danke.

OK, hatte ich beim letzten Mal gemacht, aber ist wohl bei der ganzen Umräumerei nicht bemerkt worden. Wenn das sonst funktioniert ist es ja in Ordnung so.

und, schlechte Idee? oder noch keine Zeit gehabt?

GRATULATION!

Sieht sehr geräumig aus. Da lässt sich gut arbeiten und der Kreativität sind keine Grenzen gesetzt.

Viel Erfolg!!

So, das ganze noch einmal in Ruhe getestet. Ein normales RedImage auf 16 GB brauchte ungefähr 5 Minuten, bis er im brickv wieder sichtbar war , also in etwa das, was auch beim manuellen Vergrössern drin war. OK, es funktioniert scheinbar.

Oder?

Nach 5 Minuten war der Rote zwar im brickv zu sehen, ein Skripterror 1001 wurde im brickv angezeigt. Also manuell nachgesehen ; Wie beschrieben hampelte systemd insgesamt 12 (!) Minuten rum, das resize wurde zwar durchgeführt, aber das ist eindeutig zu lang! Hier blockierte systemd sich wohl selbst?

Also unter einem "take a moment ..." im Text des Brickv verstehe ich etwas ganz anderes. Zudem liefert der RedBrick keine Daten während er das Dateisystem ändert. Hier wäre eventuell ein kleiner Textmerker für den brickv angebracht, der dann etwa ein "Resizing" anzeigt, weil da doch die Gefahr gross ist zu glauben, der Rote hätte was abbekommen.

Ist zwar nur interessant wenn man den brickv benutzt, ist auf der anderen Seite aber für unerfahrene Benutzer vielleicht ganz hilfreich.

@photon ...

Genau das ist ja nicht passiert. Wie oben beschrieben kommt systemd nicht in die Hufe und bastelt immer wieder rum. Ich habe das Teil ein paar Minuten laufen lassen. OK, es KANN eventuell sein, das systemd dann im Hintergrund das resize startet und solange warten will. Teste ich noch mal aus. Ich lasse die Maschine dann einfach mal 10 Minuten rattern, dann sollte das durch sein.

Ein kleiner Hinweis VOR dem resize wäre dann aber nett, damit man auch weiss, das nach dem reboot das ganze dauern kann und das diese Wartezeit normal ist!

Ansonsten läuft der kleine rote aber super. Die Funktionen die im brickv möglich sind erschlagen die meisten Sachen für Anfänger. Und "Profis" gehen eh über die Konsole oder direkt aufs Linux via Tastatur drauf.

Da stimmt wohl beim brickv etwas nicht. Manuell die Partition vergrössert, mit resize2fs das Dateisystem vergrössert ... geht. Das vergrössern dauert hier auch um etliches länger als mit dem brickv, der war nach einer halben Minute angeblich fertig.

So, nach dem "vergrössern" kommt systemd nicht in die Hufe. Mit /etc/rclocal Compatibilty bremst er das ganze System aus, zudem gibt es wohl für das Modul kein Timeout. Der RED läuft zwar, wird aber nicht fertig. Nach 4 Minuten hab ich das Teil abgeschaltet und das alte Image draufgepackt.

Habe heute den Red Brick ausprobiert. Zum EInsatz kommt eine 16GB Karte. Das Aufspielen mit dd hat einwandfrei funktioniert. System bootet und wird auf einem PC mit brickv angezeigt.

WLAN wird erkannt.

Aber nach dem Vergrössern der SD Karte auf die Gesamtgröße brachte der brickv nach dem Neustart ein Timeout nach dem anderen und ziegt nix mehr an. Heute ist es schon spät, ich werfe da morgen mal einen Blick drauf.

Interessant wäre auch die Option, sich ein eigenes Linux auf den Red Brick zu packen. Wie sieht es da mit dem Tool "buildroot" aus, würde das funktionieren?

Blöde Frage, hat das Borad keinen USB Anschluss. Die Teile von Arduino die ich kenne haben alle USB.

Vielleicht bin ich ja der einzige Grobmotoriker hier, aber diese kleinen Beinchen machen mir echt zu schaffen. Letztens ist mir ein Steckteil vom Distance US weggebröselt, heute hab ich beim Beinchen geredebiegen ( was mittlerweile ganz gut klappt ) an meinem LCD Bricklet gleich eine Beinamputation hinbekommen. Da wäre es doch im Shop ganz nett, wenn man quasi eine Art Leerbestellung aufgeben könnte, also etwa 1 Stück "Nur Brickletteil für LCD" oder so, ihr teilt kurz den Preis mit und fertig ist das ganze. 

Ist eine solche Reaktionszeit den von Nöten. Fliegen liegen bei 1/10 s und sind damit ziemlich sicher in der Luft unterwegs. Und soweit ich weiss, reagieren die meisten Vögel auch nicht schneller? Einfach mal für mein Verstädnis.

Habe einige US Sensoren gesehen, die bis zu einem Bereich von 7m exakt arbeiten, da sie sich automatisch kalibrieren. Wäre das nicht eine gute Ergänzung zum beisherigen Bricklet, der ist ja beim Start immer unkalibriert?

Lang ist es her, aber als PCs nur piepen konnten, gab es die Möglichkeit durch schnelles an- und ausschalten quasi eine primitve Ausgabe von Sprache zu ermöglichen. Die Zeitdauer ist ja in 1/1000tel Sekunden programmierbar, wäre da sowas möglich??

@NIC

Ups, das Teil ist wohl etwas klein geraten, wird auf ein NEMA 17 nicht passen. Aber ein anderes Teil in der gleichen Preisklasse mit 1:3600 Untersetzung gibt es auch noch.

Ich packe das mal in Zukunft unter den von dir gezeigten Forumspunkt.

@NIC

Naja, da sitzen echt Profis. Ob das Teil auf eine NEMA 17 passt, konnte mir der Mensch am Telefon nicht sagen, das 5 stufige Getriebe mit fast 1:4000 liegt bei 64€ netto. Ist also noch finanzierbar. Mal sehen, ob ich auch jemanden von der Technik dran bekomme, dann gibt es mehr Info.

@NIC

Also es gibt auch die Getriebe OHNE Motor. Leider gibt es da noch keine PDF Datei für, aber das DSMP221 hat ein Getriebe mit 1:3968, das würde ich gerne mal ausprobieren. ( Ok, ist 5 stufig, aber einfach mal schaune ob das irgendwie passt )

Preise hab ich noch nicht, da wollte sich mein Kollege mal schlau machen, aber der verpennt das bestimmt.

Hier wie versprochen die Webadresse:

http://www.dc-getriebemotor.de/

Ich stelle die Webadresse am Monatg hier rein, wenn ich wieder auf Arbeit bin.

@ NIC: " Wo gibt es denn sowas für Schrittmotoren ?

Du willst das also noch vor den Getriebemotor spannen ?"

Ja bei uns in der Hardwareentwicklung gibt es einen Freak, der kennt eine Firma, die Getriebe auch alleine verkaufen, also ohne jeden Motor. Die Preise sind human und selbst wenn mein Projekt "Erdrotation" nicht klappt, habe ich schon jetzt so viel gelernt, das sich das ganze auf jeden Fall lohnt. Und wenn es dann klappt, ein Weitwinkelbild vielleicht ein paar Minuten zu belichten OHNE Strichspuren .. mal sehen. Ich kann ja dann davon berichten, wenn du Interesse daran hast.

@remotecontrol.

Genauso ist es ja auch geplant, die Puffer auf dem Host stellen quasi eine Art virtuelles Display dar und da wäre halt ein LCD Timer von TI bequemer, da ja alle Timerevents von dort gesteuert werden. Mach ich es jetzt eben selbst. Trotzdem DANKE!