borg

Ist gefixt, Danke !

Mh hast du schon ein anderes Bricklet Kabel probiert? Anderen Port beim Master? Analog In neu geflasht?

Hab ich auch heute schon gemacht. Aber wir hausen hier ja auf einem Bauernhof, da gibts Trecker zum Schneeschieben .

Du hast dir im Prinzip schon alles selbst beantwortet. heap_1.c und heap_2.c werden nicht benutzt. Die sam3s4.ld Linkerskripte werden beim Master benutzt und die sam3s2.ld Linkerskripte bei den anderen Bricks. Die benutzen unterschiedliche Mikrocontrollertypen (atsam3s4 vs atsam3s2).

Danke!

Die Bohrschablonen und die neueste BrickViewer Versionen sind jetzt erreichbar. Bzgl. der Bemaßung der Bohrlöcher bei den Industrial Bricklets muss Bastian morgen gucken, das wird irgendwie automagisch aus den KiCAD Projektdateien erzeugt. Keine Ahnung wie das funktioniert .

Da hast du natürlich recht. Jetzt haben wir wenigstens noch Ideen fürs LCD 1.3 . Die vorgehensweise wäre vermutlich, ein Käbelchen in die GND Löststelle zu löten und von diesem Käbelchen aus die Käbelchen für die 4 externen Taster zu ziehen.

Rastermaß ist Standard 2.54mm. Ich hab auch mal gerade passende Stiftleisten in den Shop gestellt: https://shop.tinkerforge.com/right-angle-pin-header-2x3.html Davon haben wir hier zufälliger weise noch 1000stk rumliegen, die von einem anderem Projekt übrig geblieben sind . Aber wie gesagt, um die einzulöten muss man entweder zuerst den Lötzinn entfernen mit Entlötlitze o.ä., oder man muss die komplette Fläche warm genug machen, dass man die Stiftleiste reinstecken kann.

Die eingesenkte Buchse für die Ethernet Extension muss leider extra für uns angefertigt werden, wir konnten nichts bekommen was von der höhe her zwischen den Stack gepasst hätte. Die Buchsen bekommen wir leider erst Ende Januar. Ansonsten ist Ethernet fertig. Ich hab hier einen funktionierenden Prototypen liegen! Eine Stiftleiste ist beim LCD20x4 V1.2 nicht bestückt, dafür benötigen einfach zu wenige Nutzer die externen Anschlüsse und viele werden auch direkt ein Kabel anlöten wollen. Wir haben aber passende Stiftleisten hier, die könnten wir günstig mit anbieten. Das einzige Problem was ich sehe: Die Lötpunkte vom neuen LCD20x4 sind bereits verzinnt. Das ist gut zum anlöten von Käbelchen, dadurch wird aber das anlöten einer Stiftleiste leider anstrengend. @Nic: http://de.blog.tinkerforge.com/2012/12/6/lcd-20x4-bricklet-1-2

LCD 20x4 Bricklet Plugin 1.1.1 Support for LCD 20x4 Bricklet hardware version 1.2 Download: Plugin

LCD 20x4 Bricklet Plugin 1.1.1 Support für LCD 20x4 Bricklet Hardware Version 1.2 Download: Plugin

Das Projekt was du da gefunden hast ist sehr cool, das kannte ich noch gar nicht! Zu deiner Frage: Das sollte gehen, der csharp code sollte ja fast genauso auch in Java funktionieren, ich wüsste nicht was dagegen spricht. Von Unity3D selbst hab ich leide keine Ahnung .

Vermutlich ist der Master einfach im Bootloader und muss neu geflasht werden: http://www.tinkerforge.com/doc/Software/Brickv.html#brickv-flash-firmware

Master Brick 2.0 ist jetzt verfügbar! http://de.blog.tinkerforge.com/2012/11/27/master-brick-2-0-und-geschirmte-bricklet-kabel

Mh, probier nochmal das "generate_makefile" Script auszuführen und ruf dann nochmal make auf. Aus irgendwelchen Gründen findet cmake manchmal arm-none-eabi-objcopy nicht, deswegen wird dann keine .bin erzeugt. Ich konnte aber noch nie herausfinden was da wirklich Sache ist, beim zweiten mal geht es aber dann für gewöhnlich. Ich glaube das sich am Debug Brick nichts am Layout geändert hat zwischen 1.0 und 1.1 (nur am Silkscreen). Bin ich mir aber nicht sicher, da muss Bastian morgen was zu sagen.

Es gibt leider keinen schraubbaren Stecker der flach genug wäre um die Bricklet Ports vom Stepper Brick noch zu benutzen, ansonsten würden wir sie verkaufen. In Theorie sollten diese beiden hier kompatibel sein: http://www.phoenixcontact.com/online/portal/de?uri=pxc-oc-itemdetail:pid=1840382&library=dede&tab=1 http://www.phoenixcontact.com/online/portal/de?uri=pxc-oc-itemdetail:pid=1840366&library=dede&tab=1 Bzw bei Mouser: http://de.mouser.com/Search/ProductDetail.aspx?qs=ChwaSN6Xm49EQ7SgFVITdA%3d%3d http://de.mouser.com/ProductDetail/Phoenix-Contact/1840366/?qs=sGAEpiMZZMv8kklI404QlYhPqHChqbP9 Aber ich garantiere für nichts, wir haben das nie getestet.

Standardmäßig ist JTAG aus, da die JTAG Pinne verwendet werden. Du kannst JTAG aktivieren, indem du in der config.h die "#define DISABLE_JTAG_ON_STARTUP" Zeile auskommentierst.

Mh, muss ich mir angucken. Für das Protokoll 2.0 muss ich da sowieso nochmal dran rumfummeln.

Das sollte in Theorie funktionieren. Kannst du mal einmal zum Testen die Reihenfolge von Chibi und RS485 tauschen? Also Master -> Chibi -> RS485?

Mh, schick mal eine Email an info@tinkerforge.com mit der Bestellnummer die zum dem Master Brick gehört. Wir tauschen den dann aus.

Protokoll 2.0 hat damit soweit erstmal nichts zu tun. Ich habe die Hoffnung, dass die neuen geschirmten Bricklet Kabel das Problem endgültig lösen. Falls diese nichts bringen, können wir da mit Hardware wohl nichts gegen unternehmen. Wir müssen dann wohl eine Firmware bauen mit der man zwischen den 100 und 400khz umstellen kann.

Prinzipiell geht das. Der Sensor gibt einen analogen Wert zurück und mit steigender Kabellänge fällt die Spannung und somit die Entfernungsmessung. Bei 50cm wirst du kaum einen Unterschied merken, bei 2m wird es sich bemerkbar machen.

Ja, also: bytes = read(sizeof(Header)); while(len(bytes) != bytes[4]) { bytes += read(bytes[4] - len(bytes)); } vs bytes = read(sizeof(Header)); while(len(bytes) != (bytes[4] + sizeof(Header))) { bytes += read((bytes[4] + sizeof(Header)) - len(bytes)); }

I can't imagine a system where we ever return an answer for the same FID in a wrong sequence. I think we can safely add that to the spec. A Brick that returns responses to requests to two different Bricklets in a "wrong order" could however easily happen if we ever have a multicore Brick or add real threading to the Brick firmwares. However, the Bindings could implement the sequence number per FID and then the 4 bit would likely suffice again, even if we didn't guarantee the correct order for requests with the same FID. Implementing something like "Future Objects" as a general concept in all of our Bindings would be cool, but i really don't know if it is worth the effort. Especially if we consider that the first steps will get harder for someone that just starts to learn programing.

Da hast du natürlich recht. Dann würde ich vorschlagen wir machen aus dem einem Error Bit gleich zwei Error-Bits, dann können wir 4 Fehlerzustände zurückgeben: * 0 = OK * 1 = BAD_PARAMETERS (Index out of range or similar) * 2 = FUNCTION_NOT_SUPPORTED * 3 = TODO