Posts by Illuminus

    War doch soft- und hard-float.

    Das heißt, sobald es um kleine Zahlen und "math.h" geht, gibt es Probleme mit:

    • arm-none-linux-gnueabi-
    • arm-linux-gnueabi-
    • arm-bcm2708-linux-gnueabi-


    Da diese alles mit soft-float kompilieren. Versucht man mit dem Parametern "-mfpu=vfp -mfloat-abi=hard" hard-float zu erzwingen, können sie es nicht linken.

    Mit "arm-bcm2708hardfp-linux-gnueabi-" funktioniert es ohne Probleme.

    Leider habe ich das bislang nur fertig, für Linux 32 Bit kompiliert, gefunden. Läuft also nicht auf meinem Mac.

    Hallo zusammen,

    ich habe ein Problem beim Cross Compiling.

    Sowohl unter Mac OS X als auch unter Linux bekomme ich es einfach nicht hin, dass die folgende Funktion das richtige Ergebnis liefert.

    Code
    float get_altitude(float pressure) {
    
    
    	return 44330.0f * (1.0f - powf(pressure/1013.25f, 0.1903f));
    	// return = 44330.0
    }


    Der Term[font="Monaco"] [/font]"powf(pressure/1013.25f, 0.1903f)" ist immer 0.

    Ich dachte zuerst es könnte an soft- oder hard-float liegen, aber wenn ich anstelle der variable pressure z.B. den Wert 992.7 einsetze kommt das richtige Ergebnis raus.

    Code
    float get_altitude(float pressure) {
    
    
    	return 44330.0f * (1.0f - powf(992.7/1013.25f, 0.1903f));
    	// return = 172.5
    }

    Kompiliere ich das Ganze direkt auf dem Raspberry funktioniert es.

    Vielleicht nur ein kleines Flag was mir noch beim Kompilieren fehlt?

    Gruß

    Das kombiniertes Formart ermöglicht das Schreiben und Lesen innerhalb eines Zugriffes. Es wird nur ein Start und Ende gesendet.

    Hier mal das Beispiel:

    "write" sendet - [S]Addr[Wr][A]Data[A][P]


    "read" sendet - [S]Addr[Rd][A][DataHi][A][DataLo][NA][P]


    "combined" sendet - [S]Addr[Wr][A]Data[A][Sr]Addr[Rd][A][DataHi][A][DataLo][NA][P]


    Das heißt, zwischen dem lesen und schreiben wird kein Stop-Bit gesendet, sondern nur eine "repeated START condition".


    Wenn du nun ein Sensor hast, der zwingend das "combined" vorsieht, bekommst du die Kommunikation nicht hin, sofern der Kontrollor es nicht unterstützt. Daher die Frage.


    Wobei viele i2c-Sensoren das auch ignorieren der. BMP085 zum Beispiel hat das zwar im Datenblatt stehen, lässt aber den Pointer auf dem Register stehen, so dass man ihn mit write und read abfragen kann.

    Quote from pfaelzer pid=4842 dateline=1359576095

    Irgendwo im Forum steht das zusätzliche Geräte bis zu 300 mA angeschlossen werden dürfen, unter Berücksichtigung der GPIO Ströme.


    Die zusätzlichen Geräte beziehen sich auf Versorgung über den microUSB-Stecker, bei mehr bricht die Spannung zusammen. Wenn du eine eigene Spannungsversorgung bereitstellst ist das nicht gültig.

    Quote from pfaelzer pid=4842 dateline=1359576095

    Ein Widerstand zwischen den GNDs währe eine Reihenschaltung.


    Die Widerstandsidee kam Thothothomas.

    Wenn du nur LEDs 20mA bei 2V verwendest kannst du die auch, anstelle des FETs, mit jeweils einem BC337 Transistor schalten.

    Aber eigentlich wollte ich nur sagen, dass du dir über den Ground bei 600mA keine Sorgen machen musst.

    Hänge gerade an einem ähnlichen Problem.
    Ich habe versucht, nach dieser Anleitung, den Kerne (Cross Compiling) zu kompilieren hat soweit auch funktioniert, Module und Kernel sind vorhanden.

    Dann bin ich aber auf den Vermerk gestoßen:
    "rpi-3.2.27 - This is the version of the kernel currently used in Raspbian, but not exactly the same - Raspbian stock kernel image (the one available from the foundation's website) has a 3.2.27+ version marking. Please see [url=rpi-3.2.27 - This is the version of the kernel currently used in Raspbian, but not exactly the same - Raspbian stock kernel image (the one available from the foundation's website) has a 3.2.27+ version marking. Please see this post for more details.]this post[/url] for more details."

    Leider finde ich keine Details in "[url=rpi-3.2.27 - This is the version of the kernel currently used in Raspbian, but not exactly the same - Raspbian stock kernel image (the one available from the foundation's website) has a 3.2.27+ version marking. Please see this post for more details.]this post[/url]". Aber vielleicht hilft es die ja weiter.

    Weiter würde mich auch interessieren "the one available from the foundation's website" und wo? Hat jemand die Kernel-Sources 3.2.27+ auf raspberrypi.org gefunden?

    Gruß

    Du benötigst kein Widerstand zwischen den beiden Grounds. Der Strom kann auch nichts kaputt machen, dazu benötigst du Leistung und die wandeln die LEDs in Licht.

    Das Netzteil kann 1A liefern, wenn aber nur 700mA fließen wird der Rest, entweder im Netzteil verballert oder anderweitig geregelt.

    Mit einem Schaltplan währe das einfacher.

    Wie viel Strom zieht denn nun eine LED?

    Als Beispiel mal eine Schaltung die rund 3A pro Kanal schalten kann (Angehängte Datei). Solltest du weniger als 500mA pro Kanal benötigen, kannst du anstelle der FETs auch ein ULN2802 verwenden.

    Quote from cornelius pid="4768" dateline="1359454932"

    Nur halt HD nicht "ruckelfrei"

    Geht das bei euch?

    Bisschen wenig Info.

    HD ruckelt über HDMI
    HD über UPnP? Mit welchem Server?
    Über LAN oder WLAN?

    Ich hatte HD Filme nicht getestet.

    Wobei wenn ich mir überlege, dass das ganze über USB 2.0 (bezweifle das die max. Geschwindigkeit erreicht wird) über den uC an die Netzwerkschnittstelle oder noch schlimmer wieder an USB und über WLAN gestreamt wird. Das muss bei 1080i ruckeln.

    Meinst du einen Technisat DigiCorder S1?
    Der hat doch gar keine Netzwerkschnittstelle. Erst die Modelle HD S2/K2 verfügen über eine Netzwerkschnittstelle.

    Wobei die aufgenommenen Filme bei diesen Modellen nur mit der Software MediaPort (Windows) übertragen werden können. Eine Laufwerksfreigabe existiert hier nicht. Hatte das mal versucht für Mac nachzubauen aber irgendwann, aufgrund des Umfangs, aufgegeben. Mit WireShark kannst du dir aber Datenpaket anschauen und so eine Software erstellen.

    Gruß

    "Kannst du eine Programmiersprache, kannst du letztlich alle. Sind ja nur noch Vokabeln und die Grammatik ist immer gleich."
    Das war jetzt nur mal so ein Spruch aber letztlich ist was wahres daran.

    Gerade bei ARM-Basierten MCUs und Linux bietet sich C als optimale Sprache an. Mit Eclipse, als Java Programmiere wohl bestens bekannt, lässt sich schnell eine Cross Compiling Umgebung mit Remote zugriff auf das Target aufsetzen.

    Bei Java benötigst du halt eine Engine die schon sehr viele Ressourcen des PIs verbraucht, ohne das dein Programm wirklich arbeitet.

    Es währe natürlich auch möglich ein WLAN Modul über UART oder SPI zu betreiben. Ob der Datenzugriff bzw. -Transfer dadurch schneller wird wage ich aber zu bezweifeln.
    Aber ein versuch ist es wert und der UART langweilt sich sowieso, er dient zwar als Standardausgabe, aber keiner hört zu.

    Quote from orb pid="4374" dateline="1358698288"


    S/PDIF kannst Du Dir aus den Ton am HDMI-Stecker basteln.

    Ja aber doch nur mit einem Konverter der wiederum einen weiteren uController enthält. Kostet dann auch noch mehr mehr als eine Soundkarte.

    Den S/PDIF kannst du recht einfach mit einem UDA1351 in ein 24Bit analog Signal wandeln und so alles in ein Gehäuse packen.

    Oder hast du da eine Andere Lösung parat? Dann kann ich nämlich mit meinem PCM2704 aufhören, denn dafür müsste ich den USB raus löten um alles in die Box zubekommen.

    Kann das so nicht nachvollziehen, bei mir funktioniert das alles ohne Probleme. Sowohl vom iPhone als auch vom iPad kann ich drucken, dabei ist es auch egal ob ich den Drucker in Netzwerk hänge oder direkt per USB (über Hub) mit dem PI verbinde.
    Der Fehler "client-error-not-found" taucht im Netz aber häufiger auf, jedoch ohne eindeutige Lösung.
    Ist der Drucker am PI angeschlossen oder hängt er im Netz?

    Quote from manuelhanke pid="4202" dateline="1358370155"


    Habe dass selbe problem iOS 6.0.1 drucker wird angezeit - druckt nicht?

    Druckt er denn die Testseite aus dem Cups Web Frontend?