Jump to content

Ingenieur

Members
  • Gesamte Inhalte

    50
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von Ingenieur

  1. Memories

    ̶ From 64 to 256 Kbytes embedded Flash, 128-bit wide access, memory accelerator, single plane

    ̶ From 16 to 48 Kbytes embedded SRAM

    ̶ 16 Kbytes ROM with embedded bootloader routines (UART, USB) and IAP routines

    ̶ 8-bit Static Memory Controller (SMC): SRAM, PSRAM, NOR and NAND Flash support

    ̶ Memory Protection Unit (MPU)

     

    In der Dokumentation zu dem SAM3S4 steht, dass der ROM Bootloader die Funktionen zum Flashen via UART auch hat. Oder verstehe ich es falsch?

     

    Auch dann, was stört uns einen eigenen Bootloader zu implementieren und vor dem ROM Bootloader im Speicher zu setzen und beim Booten von der Adresse des eigenen Bootloaders zu starten :) ?

     

     

  2. Hallo zusammen,

     

    habe ich gerade /Remoteflash/ gelesen? :gruebel:

     

     

    Der Loetkolben

     

    Hallo zusammen,

     

    wenn man in der Lage ist ein Master Brick in das Bootloader Modus zu versetzen, könnte man theoretisch die Einheit via UART auch remoteflashen. Wenn ich richtig die Sources/Layouts lese, läuft die Kommunikation zwischen der WiFi Erweiterung und dem Master Brick via UART. Wahrscheinlich könnte man diese Verbindung zum Flashen verwenden?

     

    Viele Grüße,

    Kirill

     

     

  3. Ja genau, von den bricks (genau gesagt von dem master brick). Inzwischen habe ich eine Insellösung für mich gebaut und die API und die "brickv" Anwendung entsprechend geändert. Ich wollte nur vermeiden, dass ich bei den nächsten Revisionen der API oder "brickv" ständig die Sources mergen muss.

     

    Danke für die schnelle Antwort,

    Kirill

     

  4. @FlyingDoc

     

    Keine Frage, dass man manchmal das "Cloud Gedöns" ohne Sinn und Verstand verwendet. Nur weil es auf einmal zum Trend geworden ist. Aber wenn das Nutzen von solcher Lösung mehr als Kosten bzw. Risiken ist?

     

    Man hat mich wahrscheinlich falsch verstanden. Ich persönlich brauche so ein System nur für die Überwachung und Kontrolle. Von solchem System würde ich ein Dashboard mit der allgemeinen Information der Bricks erwarten und ein Paar Wartungswerkzeuge (ssh, telnel usw.)

     

  5. @jgmischke

     

    Ich würde nicht alles zu einer Cloud-Dienst machen. Die Logik des Kontrollers kann weiter auf dem Red Brick/Raspberry Pi/usw. laufen. Meiner Meinung nach soll so eine Cloud-Dienst hauptsächlich für die Kontrolle der laufenden Systeme benutzt werden. Selbstverständlich, will einer auch die Logik der Anwendung zu der Cloud schieben, soll auch die Möglichkeit gegeben werden.

     

    Vorteile:

    - Konsistenz der Schnittstellen bei den eventuellen Änderungen

    - Kontrolle der laufenden Systeme

    - Kein Red-Brick notwendig, wenn man entscheidet für die Logik in der Cloud (-70 Euro in Budget des Projektes)

    - keine Sorge bei den Verbindungen über 3G/4G

     

    Und überhaupt, wenn die TinkerForge Kollegen weiter das Paradigma des OpenSource verfolgen, stellen sie auch die Quellen der Cloud zur Verfügung. Dann kann man bei Bedarf den Weg des Benders aus Futurama gehen: “I'm Going To Build My Own Theme Park With Blackjack and Hookers”.

     

    Viele Grüße,

    Kirill

  6. Hallo Bastian,

     

    danke für die schnelle Antwort. Ich habe den W5200 erwähnt, da in der Dokumentation vom W5200 die Gestaltung von der Stromversorgung beschrieben ist. In der Dokumentation vom W5500 habe ich solche Information auf schnelle nicht gefunden.

     

    Viele Grüße,

    Kirill

     

     

  7. Hallo TF Team,

     

    bei den Komponenten der Ethernet Erweiterung habe ich das nächste Problem. Bei dem Filter ist für die Ferrite keine Impendanz angegeben. Soll man die gleichen nehmen, die in dem Datasheet für 5200 ("5200.pdf") vorgeschlagen sind? Oder ist es unwichtig?

     

    Viele Grüße,

    Kirill

     

     

     

  8. Hallo, Bastian,

     

    ich wollte einfach in der Lage sein selbst ein System aus kleinen Stücken aufbauen. Das sollte die Hardwareseite und die Softwareseite betreffen. Deswegen wollte ich wie die Bricks sowohl auch die Brickltes selbst zusammenbauen. Die Anwendung dafür ist die Hausautomation, die zurzeit bei mir auf industrietauglichen PLCs läuft (1 Wago PLC + 1 Beckhoff PLC + Raspberry Pi). Die 3 Einheiten möchte ich durch das einheitliche System ersetzen, welches ich auch selbst reparieren kann, wenn was kaputt geht.

     

    Viele Grüße,

    Kirill

  9. Hallo TF Team,

     

    bei der Suche nach Komponenten für das Ethernet Brick hatte ich Schwierigkeiten mit der RJ45 Buchse. Solche Ausführung ist recht kompliziert zu finden. Was ich in Europa gefunden habe, das war nur vom Würth elektronik und kostete genau so viel als alle andere Komponente zusammen.

     

    Könnt Ihr vielleicht eine andere Buchse empfehlen, die billiger ist? Auf den Bildern erkenne ich, dass ihr eis von Taimag nimmt, aber solche finde ich nicht zu kaufen.

     

    Viele Grüße,

    Kirill

  10. Hallo TF Team,

     

    es wäre nett, wenn ihr einen Überblick gibt, wie ihr die Bricks bei der Entwicklung von Firmware debugt und welche Werkzeuge ihr dabei verwendet. Wenn ich alles richtig verstehe ihr macht es über die JTAG Schnittstelle an dem Debug Brick. Aber welche Software ihr dabei benutz und welchen JTAG Emulator würde mich interessieren.

     

    Vielen Dank im Voraus,

    Kirill

×
×
  • Neu erstellen...