AVR32 kompatibilität mit Bascom?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • AVR32 kompatibilität mit Bascom?

      New

      Hallo!

      Habe da mal eine dumme Frage:

      Ich interessiere mich aktuell für ein spezielles Optionsboard eines Geräteherstellers, worüber ohne relativ aufwändiges und langwidriges Verfahren (einige NDA's und Verträge) keine brauchbare Informationen zugänglich sind.
      Es gibt den ganzen Dokumentationskram nebst API und SDK erst wenn das alles durch ist.
      Gerne würde ich da Software für entwickeln, bekomme aber keine Informationen die für eine Entscheidung reichen.
      Beispielsweise welche Programmiersprachen die zugehörige SDK beherrscht, bis auf Basic sind mir höhere Sprachen weitgehend bömische Dörfer.

      Was ich aber inzwischen rausgefunden habe in den öffentlich zugänglichen Fragmenten:
      Herzstück dieses Optiosboards ist eine AVR32UV3B0512.

      Kann ich da für soeine AVR32UC3B notfalls auch mit Bascom funktionsfähige Programme schreiben, oder kann ich das eher vergessen?

      Grüße

      Jürgen
    • New

      Ich würde sagen, wenn Bascom diesen Prozessor unterstützt, dann kann man auch mit Bascom Programme dafür schreiben.

      Ein weiterer Punkt ist allerdings die Schnittstelle, wie das Programm dann in den Controller gelangt.
      Ist ISP-Schnittstelle vorhanden oder Bootloader?
      Wird Bootloader-Protokoll von Bascom unterstützt?

      Vielleicht findest du in YouTube weitere Infos, wenn du nach dem Board oder dem Controller suchst.
      Kaum macht man es richtig - und schon geht's!
    • New

      Hallo!

      Mitch64 wrote:

      Ich würde sagen, wenn Bascom diesen Prozessor unterstützt, dann kann man auch mit Bascom Programme dafür schreiben.

      Genau das ist der Punkt: Bislang machte ich nur mit ATmegas rum und seit kurzem liegt mein aller erster ATXMEGA in der Ecke.
      Aber zu den AVR32UC3B habe ich im Bascom-Manual noch nichts gesehen, auch eine kurze Google-Suche nach "AVR32UC3B + Bascom" brachte keine Hinweise darauf das sowas bekannt ist.
      Als ich zu diesem zugenagelten optionsboard las das da ein AVR32UC3B0512 drin steckt freute ich mich erst mal...bin mir aber inzwischen nicht mehr sicher das Bascom den tatsächlich beherrscht.
      In Bascom finde ich auch keine entsprechende Chipdefinition (*.dat) zu solchen AVR32-Chips.

      Mitch64 wrote:


      Ein weiterer Punkt ist allerdings die Schnittstelle, wie das Programm dann in den Controller gelangt.
      Ist ISP-Schnittstelle vorhanden oder Bootloader?
      Wird Bootloader-Protokoll von Bascom unterstützt?

      Das wäre das nächste: Nach dem ersten überfligen des Datenblattes zur AVR32UC-Reihe finde ich zwar was zum Thema JTAG, aber nix zum Thema ISP oder PDI.
      Die vom Hersteller vorgegebene Programmierschnittstelle läuft über einen Bootloader:
      Habe drei verschiedene Programme hier die dazu gedacht sind über die virtuelle IP-Schnittstelle via USB dieses Optionsboard im Hauptgerät zu erkennen und eine entsprechende Binärdatei draufschieben und bei bedarf auch den Bootloader aktualisieren zu können.

      Hersteller denkt sich das so:
      Software in der SDK schreiben und als Binärdatei speichern.
      Dann mit einem eigenen Flashtool durch das Hauptgerät hindurch die eingebaute Optionskarte flashen.
      Davon gibt es sogar öffentlich ein Video vom Hersteller, wie das gedacht ist.

      Mitch64 wrote:

      Vielleicht findest du in YouTube weitere Infos, wenn du nach dem Board oder dem Controller suchst.
      Kaum, suche schon seit ner Woche nach Hintergrundinfos.
      Weltweit gibt es knapp 100 externe Firmen die mit diesem Optionsboard schon was gemacht haben, aber Anfragen dort fahren vor die Wand weil die halt vertraglich dazu verknebelt sind.
      Beispiele, und Hintergrund worum es mir geht, findet man in diesem öffentlich zugänglichen Katalog der mit gut vier Jahren inzwischen reichlich veraltet ist.

      Grüße

      Jürgen
    • New

      Wie Michael schon sagte. Wenn Bascom die CPU nicht unterstützt, vergess es.
      Und wenn du nur in Bascom fit bist gehts wohl nicht.

      Ich weiß jetzt aber nicht ob C/ C++ für dich eine Lösung ist, dann käme z.B. AVR-Studio eventuell als IDE in Frage.
      Diese IDE sollte alle Controller unterstützen. Auch 32-Bitter und die größeren ARM Controller.
      Kaum macht man es richtig - und schon geht's!
    • New

      Hallo!

      Ja, habe gestern mal im MSC-Forum geschaut.
      Beiträge aus 2006 rum ließen verlauten das man an einer AVR32-Bascom IDE arbeitete, diese sogar schon weitgehend funktionierte.
      Beiträge 10 Jahre später (2016) zeigten dann das diese AVR32-IDE irgendwann aufgegeben wurde...schade.

      Ebenso bin ich zur hardware schlauer geworden:
      In einem Servicemanual zu einem anderen Hostgerät ist dieses Optionsboard erwähnt, komplett mit Schalt- und Bestückungsplan. Und siehe da: Der JTAG ist als direkte Programmierschnittstelle als Buchse herrausgeführt.

      Ob ich C oder C++ jemals burchblicke weiß ich nicht. Bei Bascom bin ich überhaupt erst gelandet weil ich in meiner Jugend relativ leicht einen Einstieg unter QBasic/GWBasic fand.

      Grüße

      Jürgen
    • New

      Hallo!

      six1 wrote:

      Was ist so besonders an diesem Board, dass du da so eine Energie reinsteckst und gegen solche Widrigkeiten ankämpfst?
      Gibt doch so viele andere Boards, ohne Beschränkungen...

      Nunja, weil es eben nicht um irgendein Experimentierboard geht.
      Es geht um ein Optionsboard für ganz spezifische Hauptgeräte.
      Das pezifische Board für diese Geräte gibt es für <50€ blanko ohne Firmware.

      Im Posting Nr. 3 ganz unten habe ich eine PDF verlinkt die einen eindrucksvollen Überblick gibt was andere schon mit diesem Optionsboard gemacht haben.
      Es ist also ein System nach foldenden Schema:
      Hersteller entwickelt eine Gerätefamilie mit absichtlich beschränktem Funktionsumfang den Vertriebspartner mit einem gewissen Gewinn vermarkten können. Optional gibt es dazu diese Boards wo Vertriebspartner Software für schreiben können um zahlreiche Sonderfunktionen in die Hauptgeräte zu implementieren.

      Somit wird das Serienprodukt spezialisiert und sein Verkaufswert gesteigert -> höherer Gewinn.
      Das dumme daran ist, das kaum Informationen dazu öffentlich sind, gibt es nur gegen NDA und Lizenzgebüren welche an sich schon sehr diffus sind. Dreistellige Euros, vierstellige Euros? Das erfahre ich frühestens 4 Wochen nach NDA-Antrag wie viel mich das kostet um an die komplette Dokumentation, die AIP's zum Hostgerät sowie an die SDK zu kommen.
      Daher habe ich mich erst mal um die Hardware gekümmert um zu eruieren ob ich das Board auch notfalls ohne die SDK programmieren kann.
      Aus diesem Grund lese ich mich gerade in C ein und gucke ob ich da durchblicke...bislang eher weniger.

      Grüße

      Jürgen
    • New

      Hast du denn ein solches Gerät, dass sich mit so einem Board erweitern lässt?
      Weil ich sehe sonst auch keinen Grund ein solches Board programmieren zu wollen.

      Auch der Anhaltspunkt, dass es eine SDK gibt, läßt mich schon vermuten, dass hier umfangreiche C/C++ Bibliotheken beinhaltet sind.
      Für einen C-Newcommer ist das wahrscheinmich nicht stemmbar.
      Kaum macht man es richtig - und schon geht's!
    • New

      Hallo!

      Mitch64 wrote:

      Hast du denn ein solches Gerät, dass sich mit so einem Board erweitern lässt?
      Weil ich sehe sonst auch keinen Grund ein solches Board programmieren zu wollen.

      Selbstverständlich, ein DP4600 liegt schon als Experimentiergerät in der Werkstatt.
      Aufgrund dieses Experimentiergerätes entsprang ja auch meine Erkentniss das bei den Optionsboards nicht ausschließlich in eine offene Erweiterungsoption geht, sondern zusätzlich auch eine absichtliche Funktionsbeschneidung seitens des Herstellers.

      Beispiel: Eine relativ häufige Anforderung an solche Geräte - je nach Anwendungsgebiet - ist eine "Man Down" genannte Funktion, auf Altdeutsch auch "Totmannfunktion":
      Verharrt das Gerät in ungewöhnlicher Position (programmierbar) oder erfährt expreme Beschleunigung, soll ein Alarm ausgesendet werden.
      Dazu braucht es einen Sensor, heutzutage gerne ein 3-Achsen Gyro.
      Will man sowas haben, braucht es zwingend dieses Optionsboard.
      Guckt man aber genauer hin sitzt der gleiche Gyro welcher mit dem Optionsboard hinzugekauft werden kann bereits auch schon auf der Hauptplatine des Grundgerätes.
      In der Gerätefirmware taucht der aber nicht auf...nur wenn man das Optionsboard zukauft erkennt das Gerät den zweiten Gyro auf dem Optionsboard.

      Mitch64 wrote:


      Auch der Anhaltspunkt, dass es eine SDK gibt, läßt mich schon vermuten, dass hier umfangreiche C/C++ Bibliotheken beinhaltet sind.
      Für einen C-Newcommer ist das wahrscheinmich nicht stemmbar.

      Ja, befürchte ich auch, zumal mir nicht 100%ig klar ist wie die Kommunikation zwischen Hostgerät und Optionsboard gedacht ist.
      Im Schaltplan sehe ich eine UART, einen I²C und einen USB zwischen Gerät und Optionsboard.
      Das Hauptgerät selber nach aussen (PC) stellt ein USB-Decive dar, welches vom PC-seitigen Treiber als virtuelles Netzwerkgerät (IP/UPD) erkannt wird.

      Naja, war ne interessante Idee, scheint aber nicht wirklich erfolgsversprechend zu sein weiter Zeit da rein zu investieren.
      Denn auch meine diversen Versuche mich in C schlau zu lesen stocken. So wirklich von Grund auf, oder zumindest einer Einstiegsstelle wo ich adaptieren kann habe ich da bislang nichts gefunden.

      Grüße

      Jürgen