cfranz

R99, Du kannst (bei einem iOS Device, dass Du nicht jailbreaked hast) nur dann eine selbstentwickelte App auf das Device laden, wenn Du die dafür notwendigen Certificates hast. Diese Certs verwendet XCode, um die Executables digital zu signieren, damit iOS sie nicht zurückweist (schützt in der Form auch vor Viren, da deine app, sobald sie von einem Virus oder Drittpartei modifiziert wurde, nicht mehr der Signatur entspricht). Während der Entwicklung gehst Du nicht den Umweg via iTunes, sondern lädst deine App direkt vom Mac (du brauchst einen Mac dafür) auf das Device. XCode kann dann die App monitoren und 'fernsteuern', inklusive dem Lesen aller Variablen, setzen von Breakpoints usw. In einem normalen Entwicklungszyklus kannst Du nämlich davon ausgehen, dass Du deine App 5-10 mal pro Tag (häufiger beim debuggen) auf das Gerät lädst. Da ist es gut, dass Du nicht über iTunes gehen musst... Und hier ist das Problem: die Certificates bekommst Du nur über Dein Developer Account. Und soweit ich weiss knöpft Dir Apple dafür pro Jahr 99 USD ab. Darin sind allerdings (aber nur für professionelle Entwickler wirklich interessant) zwei Support-Anfragen an Apple's engineering enthalten. Wenn Du die Support Cases nicht brauchst, hättest du von den 99$ mehr, wenn du Tabak reinstreust und rauchen würdest - aber das kostet halt der Eintritt. Was allerdings auch ohne zu Zahlen geht, ist der Simulator, der mit XCode kommt. Mit dem kannst Du eine ganze Menge anfangen, solange Du nicht bestimmte hardware ansprichst (bspw. accelerometer). In Verbindung mit der WiFi Extension kann auch der Simulator gute Ergebnisse liefern. Und ohne die WiFi-Extension (oder Ethernet) kann kein iOS-Gerät was mit den TF Stacks anfangen. Gruss und viel Spass, -ch

Gibt es ein Bricklet, mit dem ich Lautstärke (in dB nehme ich an?) messen kann? Ich verstehe ja nicht viel (genauer: gar nichts) von Elektronik, weshalb ich so gerne die fertigen Bricklets verwende. Konkret möchte ich gerne periodisch messen, wie 'laut' es in der Umgebung vom sensor ist. Ist das so elementar umsetzbar, dass niemand dafür einen Brick gebaut hat, so kompliziert, dass es zur zur zeit nicht gemacht werden kann, oder so saublöd, dass es ausser mir niemand braucht? Gruss, -ch

Danke! Das mir dem Step-Down (den ich komplett übersehen habe, weil ich dachte, der sein nur für das Treiben von Motoren da) macht die Sache in der Tat viel einfacher. Ist 'gleichgerichteter stom' das gleiche, was amateure wie ich 'gleichstom' nennen (also z.b. 5V DC)? Und wie ist das mit 'geglättetem' (spannungsstabilisiertem?) gleichstom? Muss ich darauf achten oder macht da das brickli? Oh, und was für werkzeug brauche ich für den stecker? ich habe nix bei mir gefunden, was dafür passend was machen kann. Gruss, -ch

Wenn wir schon bei dem thema sind: Für absolute Elektronik-nieten wie mich ist es schwer, herauszufinden, was für ein Netzteil ich brauche. Leider bietet TF selber ja keine Netzgeräte an, noch empfehlen sie etwas. Wenn ich nicht selber löten möchte, sondern nur mit einer Steckplatine und TF-kabeln arbeite and keine Lasten wie e-motoren treiben will: Habt ihr eine Empfehlung, was ich mir zulegen sollte? Hier um die Ecke ist sogar ein Conrad shop, der eigentlich gut sortiert ist. Danke für jede Empfehlung.

Das stimmt nur bedingt. Wenn Du hart am Metall coden kannst, dann ja. Dann brauchst Du nur kleine oder keine Libraries. Sobald Du aber mit einer 'komfortablen' umgebung arbeiten willst, brauchst du libraries (=platz) oder interpreter (viel platz) und der code wird viel länger. 100 KB ist viel, wenn du mit einem 6502 prozessor arbeitest (mehr, als der addressieren kannst), absolut nichts wenn du mit modernen entwicklungsumbegungen arbeitest. Was natürlich der Ausgangspunkt dieser diskussion ist So wie ich das jetzt verstanden habe, bin ich immer mehr auf den Paspberry Pi neugierig geworden. Braucht es für die Integration irgend was bestimmtes, oder wird der einfach mit usb an den master angeschlossen, der Pi mit strom versorg und alles in einen schuhkarton geworfen? -ch

OK, da sieht man mal wieder, wie wenig ich von hardware verstehe. Ich bin davon ausgegangen, dass es sich bei dem brick nicht um einen 'refurbished master' handelt, sondern einen eigenen Prozessor mit entsprechendem Speicher in der Grössenordnung 8 MB (für programm und variables) oder mehr hat, der nach dem bootvorgang sein programm z.b. von einer SD-Karte zieht. Wie gesagt, ich verstehe davon nix, aber ein 64mbit chip kostet ca 3.00 EUR in kleinen mengen, weshalb ich davon ausging, dass das preislich kein problem darstellt. 100 KB ist weniger als der literal table einer 'hello world' app bei vielen interpretierten sprachen. Autsch. OK, in solchen grössenordnungen hat nur C oder assembler eine chance.

Wenn es simple ist, c (compiliert neheme ich an) auszuführen, dann sollte es auch einfach sein (sofern der speicher gross genug ist) auch beliebige interpretierte sprachen auszuführen. Bspw wird ein Py programm zusammen mit dem interpreter als compiliertes c programm geladen. Der interpreter wird ausgeführt und lässt dann das Py programm laufen. Bereits der alte Apple II funtionierte 1977 mit BASIC so. Wenn es also einen open source Py interpreter gibt, sollte es nicht allzu schwierig sein, so etwas zusammenzuschustern. Der c brick wird also jedesmal mit einem paket bestehend aus interpreter und Py programm geladen. Oder mit einem basic-interpreter und zugehörigem basic-programm etc. Aber evtl habe ich die ausgangslage nicht voll verstanden. Ich ging davon aus, dass auf dem brick ein prozessor läuft, der einen native maschinencode benötigt. Wenn ich dich richtig verstehe, läuft auf dem brick aber Py native? Hab ich das richtig verstanden? Was sind zur zeit die Parameter, die für so ein programmierbares device gelten? Ich dachte ein prozessor, der mit maschinensprache programmiert wird, ein paar MB RAM und etwas IO.

Ich bin mir nicht sicher, dass ich die diskussion ganz verstehe, aber ich bin eventuell auch zu spät erst dazugestossen. Meine Annahme: Ihr wollt einen TF block herausbringen, der die bricks/bricklets direkt steuert, also quasi die Daemon/PC-kombination ersetzt. Nun scheint die Frage zu sein, ob der brick eher in C oder Python programmiert werden soll. Meine Frage: wieso 'oder'? Soweit ich weiss, ist Py eine interpretierte Sprache, C wird kompiliert (also direkter maschinencode). Aus meiner Sicht (die sehr beschränkten ist, immerhin habe ich das letzte mal vor gut 20 jahren einen compiler geschrieben) sind im Endeffekt beide das gleiche. Ein interpretiertes Programm wird halt mit dem Interpreter plus Library und dem byte/tokencode auf den brick gebracht. Ein voll compiliertes programm wird direkt aufgespielt. Das ist doch 'bloss' ein Problem deiner Toolchain. Kann euer compiler nicht automatisch den python zwischencode mit einem interpreter verpacken und als maschinencode auf den chip bringen? Alternativ könntet ihr den chip do entweder als Py engine oder 'straight machine' flashen. So können die C heads direkt (schnelle programme), die pythoners den interpretierten code draufknallen. Und die community kann dann noch interpreter für andere dialekte (z.b. das erwähnte TF-Basic) dazu schreiben Was habe ich übersehen? -ch [eine sache die ich nicht geschnallt habe: wieso wird C hier als Guru-Sprache bezeichnet? C++ meinetwegen. Aber oldskool C ist eher ein glorifizierter Macroassemberl. Das ist nur unbequem, nicht schwierig. Py ist hat viel eleganter.]

Arnim, ich bin mit nicht sicher, dass es für Deine Frage eine eindeutige Antwort gibt. Wenn ich Dich richtig verstanden habe, willst Du auf dem *selben* Rechner eine Art 'Totmann'-Schalter implementieren. Ein countdown wird gestartet, der regelmässig auf den anfangswert zurückgesetzt wird, solange das system läuft. Kann der Countdown erfolgreich durchlaufen, erfolgt der reset-zyklus. Deine Frage ist, ob der daemon immer noch läuft (und daher den countdown weiter laufen lässt), wenn sich der server aufhängt. Falls nein, würde dann der selbst-reset nicht ausgeführt werden. Meine persönliche Meinung: 1. Mit grosser sicherheit wird der daemon und der server auf unterchiedlichen prozessen/threads laufen. In vielen Fällen sollte es funktionieren 2. Es gibt beliebig viele vorstellbare konstellationen, wo der serverprozess absäuft, aber die steuersoftware nicht. In diesem fall wird es keinen reset geben 3. Es wird sicher auch konstellationen geben, wo sich der kernel zentral aufhängt und nix mehr geht. auch dann kommt kein reset. 4. Wie behandelst du false positives? Was, wenn aufgrund unglücklicher umstände der countdown voll durchläuft, obwohl der server läuft? Ich glaube, dass Du nie alle probleme ausschliessen kannst. Am sichersten aber wäre in so einem setup, wenn du zwei unabhängige rechner hast. der eine ist nur dafür da, regelmässig den serverprozess auf dem hauptrechner abzufragen und wenn kein signal kommt, den reset-vorgang auszulösen. So etwas kannst du beispielsweise mit einem Raspberry Pi umsetzen. Aber eventuell habe ich alles falsch verstanden. -ch

Ich glaube, das Wichtigste ist, dass Ihr euch vorher noch einmal genau darüber gedanken macht, wer eigentlich eure Zielgruppen sind, und die dann so ansprecht, dass sich diese Leute verstanden und bei Euch gut aufgehoben führt (Achtung: ich sage nicht, dass Ihr das nicht tut - lediglich, dass ihr es besser könnt). So wie ich das sehe, habt ihr mindestens zwei sehr unterscheidliche Zielgruppen: Da sind die codeheads wie ich, reinste Softwareleute, die endlich einmal mit dem code etwas Hardware steuern möchten. Wir haben marginals Wissen über Digitaltechnik (wenn ihr Glück habt - und selbst meines erstreckt sich nur auf die alte 74LS.. Baureihe), null komma null Erfahrung mit Elektrik/Elektronik. TF ist deswegen für mich interessant, weil ich wenig bis nix Löten muss und mit plug&play dennoch viel hinbekommen kann. Jedenfalls ist das meine Erwartung/Hoffnung. Eure Doku in bezug auf Programmierung ist für mich einfach zu verstehen (das Wort Binding war vom Kontext her klar; 'Interfaces' hätte auch gereicht), aber die Doku richtet sich weniger an Programmierer als an Digitaltechniker - es ist auch einfach zu erkennen, dass das Design eher auf den Bricks/Bricklets liegt als auf der Software (Bindings). Ich hätte mir weniger technische Beispiele gewünscht, mehr (triviale) Schaltbeispiele und Programmierungen um das Spielkind in mir zu fördern. Auch wenn dann der Elektrotechniker an 'Kindergarten' oder 'Lego' denkt. Beipielsweise eine kleine Gruppe von Experimenten geschrieben für euer Starterset plus ein paar Leuchtdioden und eine Steckplatine. Damit 'spiele' ich nämlich rum und habe *extrem* viel spass. Oder *einfachste* Beispiele wie man mit den bricks ein muster von LED ansteuert, eine kleine Alarmanlage baut etc. Worauf ein Depp wie ich achten muss, wenn er andere Dinge anschliessen will. Und ein oder zwei komplette Beispiele, wie man ein oder zwei servos richtig anschliesst, warum das so angeschlossen wird, welchen Spielraum man bei den Bauteilen hat, worauf zu achten ist etc. Und am allerwichtigsten: ihr braucht für 'schreibtischtäter' wie mich ein oder zwei netzteile im shop. Elektronieten wie ich wissen nicht, worauf wir achten müssen. Ein Netzteil, das ausreicht 8 bricks und ein paar Servos zu treiben würde ich mir sofort bei euch kaufen aus dem einfachen grund, dass ich weiss, dass ihr es empfehlt und ich vermute, dass es passt. Die zweite Zielgruppe sind wahrscheinlich elektro- und digitaltechniker, die sich wünschen, ihre designs und geräte mit mehr automatisierung zu versehen oder verschiedene geräte zu einem viel komplexerem ganzen zu verbinden. Diese Leute sind götter der elektrotechnik; mit den Fragen einer IDE, verschiedenen Compilers, OS-Integration, deamons und Kernel extensions kommen sie nur unwillig zurecht. Mit den Bindings selber werden sie weniger Probleme haben (vermute ich), da sie vom Design her eher die 'Sprache' der Hardware abbildet als die Integration in ein OS. Als ich auf der Suche nach einer Möglichkeit war, etwas Hardware mit Software einfach zu steuern, bin ich eher durch Zufall auf Euch gestossen ('hardware mit computer steuern' bringt keinen google-treffer), nachdem ein Programmierkollege an der Uni Stockholm (!) mir einen Tipp gegeben hat. Überzeugt hatte mich dann euer Filmchen. Verstanden hatte ich zwar nur die Grundaussage, aber das hat gereicht. Ich bin sicher, Ihr habt selber ein viel besseres Bild von euren Kunden und es ist gut möglich, dass ihr die bereits perfekt ansprecht. Um mehr SW-lastige Kunden anzusprechen (die nicht gleich vorhaben, einen Raspberry zu verbauen), könntet ihr vielleicht schon ein paar Änderungen anbringen. Hoffentlich habe ich genügend zum Ausdruck gebracht, dass ich all das hier nicht schreibe, um euch blöd anzumachen, sondern weil ich von TF begeistert bin und mir wünsche, dass noch viel mehr Leute an euch Freude finden sollten. Ich habe fertig. -ch

Ich bin gerade dabei, mit einem Ind Quad herumzuexperimentieren und habe eine Anregung: Meine Dual Relays haben eine kleine Leuchtdiode neben jedem relay, die den Status anzeigt (gechlossen = leuchtet). Ist so etwas auch für die nächste revision der quads möglich? Es ermöglich mir das debugging viel einfacher (ich kann schon sehen, ob der code stimmt, bevor ich mit dem messgerät an die pins gehe). -ch

Jetzt klappt's!!! Danke, -ch

ah! jetzt wird auch mir das klar. Danke! -ch

Ich bin gerade dabei, die callbacks von ipcon auzutesten. Die Dokumentation erklärt ja bereits eine ganze Menge, und meine Test sind gut voran gekommen. Eine Interpretation der callbacks von mir aber scheint falsch gewesen zu sein; daher würde ich mich über ein paar mehr Erläuterungen freuen. Aufbau: master mit 4 bricklets hängen via USB an meinem Mac ipcon ist configuriert, dass für alle drei klassen der callbacks (IPCON_CALLBACK_ENUMERATE, IPCON_CALLBACK_CONNECTED und IPCON_CALLBACK_DISCONNECTED) meine callbacks angesprungen werden. Zur Verständnisfrage: Wenn ich während des Betriebes den USB-Stecker ziehe, dann hatte ich erwartet, dass der callback für IPCON_CALLBACK_DISCONNECTED angesprungen wird. Statt dessen erhalte ich (was ja auch logisch ist), 5 mal IPCON_CALLBACK_ENUMERATE mit reason=IPCON_ENUMERATION_TYPE_DISCONNECTED. So weit, so gut - hab ich nun geschnallt. Aber unter welchen Umständen erhalte ich einen IPCON_CALLBACK_DISCONNECTED? Genauer: wie kann ich so etwas testen? Danke, -ch

Ich fürchte, meine elektronik-kenntnisse sind sehr gering (ich weiss gerade mal, warum die steckdose zwei löcher hat: eines für den strom, das andere für die spannung...). Ich habe eben die IO16-doku eingesehen. Die sagt, dass die pins verschieden konfiguriert werden können - unter anderem als input 'floating' und als output low (wahrscheinlich mit GND verbunden - ich verstehe wirklich nicht viel davon). Könnte ich diese beiden states in meiner steuerung dazu verwenden, um das relais zu simulieren? also im normalzustand die pins auf input-floating setzen. Dann zum ansteuern (beispielsweise mittels monoflop) die pins fur 0.5 sekunden auf output low schalten um danach zu input-float zurückzukehren? Könnte ich so das relais in der schaltung durch einen IO blöckli ersetzen? -ch