DYI: MIDI Fußleiste selber bauen?!

[axefx]

Ich hab das .fzz mal aktualisiert und ins GitHub geladen...

Hab`s https://github.com/oson/midi_board_ONE/tree/master/schematic

Du verwendest da also auch 220 Ohm für die LEDs ... korrekt?

 

[OSon]

Jupp... Ist in jedem Arduino-Beispiel... Uuund, ich habe es irgendwie berechnet... ;-)

 

[axefx]

Jupp... Ist in jedem Arduino-Beispiel... Uuund, ich habe es irgendwie berechnet... ;-)

Tja berechnen ... hier hatte ich was dazu gefunden: http://www.mikrocontroller.net/articles/LED Aber Leute ... ich bin Marketing-Schwätzer und "Projektmanager" in meinem bisherigen Leben gewesen ... ich Verkauf euch gelb als grün ... wie alle Leute, die Physik mit 4 Punkten nach der elften Klasse abgegeben haben .... * duck und wegrenn ...

 

[Pacosipulami]

hihi ... da steht:

"Die Pins, welche als OUTPUT definiert sind, können auch beschädigt oder zerstört werden, wenn sie kurzgeschlossen oder mit starken (strommässig) 5 Volt Spannungsquellen verbunden werden." ...

- ja....wenn der Strom grösser ist als 40mA. Hier wieder das ohmsche Gesetz.

Spannung / Strom = Widerstand

Sprich mit einem Widerstand von grösser als 125Ohm bist Du safe! Eine "normale" Anzeige-LED hat vielleicht max. 20mA Stromaufnahme, also ist deren Innenwiderstand bereits grösser als 125Ohm. Ohmsches Gesetz sagt ja - wenn Strom kleiner = Widerstand grösser.....
Mit dieser Angabe sollte nur davor gewarnt werden bei einem Output-Zustand den Pin kurzzuschliessen oder damit versucht werden direkt einen Motor anzusteuern oder sonstige Verbraucher, deren Stromaufnahme höher ist als 40mA

Eben - bald kommt mein Starter Set - und dann darf Pacosipulami auch.....

 

[axefx]

Super Paco, das versteht sogar der kleine axefx Habe jetzt mal die bisherige Videodokumentation mit einheitlichem Titel versehen und ordentlich verlinkt und in einer Playlist zusammengeführt. Also , wer auf dem laufenden bleiben will, der mögge sich folgenden bookmark setzen:

http://www.youtube.com/watch?v=dIs-Xt1zd-U&list=PLT2sYJRe7JGzRZjYknhBgOrFEbOZDuBH5

 

[axefx]

Allright: Letzte Version vom Fritzing Schaltplan (Basti`s mit den integrierten LEDs) genommen, um 2 Schalter mit LED`s erweitert, Software letzter Stand genommen und die CCs und PCs für die ersten 4 Schalter eingetragen:

// Button-Definitions:
  //                      Button-Pin   LED-Pin  Funkt.  CC/PC   High  Low,  init. Ctrl. State
  buttons[0] = new Button(    2,       38,      "CC",    7,    127,     0,        LOW );              //Chorus + rote LED
  buttons[1] = new Button(    3,       36,      "CC",    9,    127,     0,        LOW );              //Delay + rote LED
  buttons[2] = new Button(   23,       22,      "PC",   10,      0,     0,        LOW );              // Preset 11 + grüne LED
  buttons[3] = new Button(   49,       48,      "PC",   11,      0,     0,        LOW );              // Preset 12 + grüne LED
  buttons[4] = new Button(   12,       32,      "PC",    0,      0,     0,       HIGH );               // Pseudo "startup" Preset 1
  buttons[5] = new Button(   13,       33,      "CC",   21,    127,     0,        LOW );            // -
  buttons[6] = new Button(   14,       34,      "CC",   22,    127,     0,        LOW );            // -
  buttons[7] = new Button(   15,       35,      "CC",   23,    127,     0,        LOW );            // -

im setup.h file:

#define START_PROGRAM_NO       0           // Start Program-Preset-No at initialization

0 müsste Preset 1 sein, aber ich kann da Nummern eintragen, wie ich will, das G-Major hüpft da immer auf irgendeine Zahl, die ich nicht nachvollziehen kann ... das ist das einzige, was (bei mir) nicht so recht funzen will. Von daher der "Pseudo "startup" Preset 1" mit dem unbesetzten "buttons[4]". Da hüpft das G-Major zwar beim Startup auch noch hin und her manchmal, landet aber am Ende beim Gewünschten Preset 1.

Auch mit der externen Stromversorgung habe ich noch Probleme: Da wird einach kein MIDI Signal mehr gesendet. Jemand eine Idee, warum? Muss da die Stromversorgung irgendwo umgeschaltet werden?

Anyhow ... schaut`s euch an:

[video=youtube;cyn-qqQxlFk]http://www.youtube.com/watch?v=cyn-qqQxlFk&list=PLT2sYJRe7JGzRZjYknhBgOrFEbOZDuBH5[/video]

Geil, oder????? You`re `da men! :rock:

 

[axefx]

OK, anderes Netzteil probiert, 9V, 500mA, korrekte Polung und schon funktioniert es Yeah!

 

[Nils H.]

Moin,

ich der Typ mit dem MIDI-Controller bei Tube Town. Ich habe mich hier mal registriert, um Euch ein paar Tipps mit auf den Weg zu geben; versteht mich nicht miss, ich will hier auf gar keinen Fall allwissend erscheinen, habe aber bei meinem Projekt auch einiges an Lehrgeld gezahlt. Ich habe jetzt nicht den ganzen Thread gelesen, sondern nur überflogen, weiß also nicht genau, welchen Umfang Euer geplanter Controller haben soll. Was ich Euch aber aus meiner Erfahrung aus dem Ampbau und mit meinem Controller dringenst empfehlen kann ist, alles so gut wie möglich zu planen und zu dokumentieren, und das geht bei der Hardware los. Ich würde auch noch nicht zu viel Energie in die Programmierung stecken, solange die Hardware noch nicht komplett fest steht. Wenn Euch die Portpins ausgehen, müsst Ihr entweder auf ein Arduinoboard mit einem MEGA ausweichen, oder Porterweiterungen benutzen, worauf dann u.U. die ganze Programmierung angepasst werden muss. Ich habe bei meinem Controller natürlich auch erst mal viel runprobiert, hinterher aber sehr viel Code wieder weggeworfen, weil er nicht mehr zur Hardware passte. Kommt allerdings darauf an, wie sehr man von vorne herein sich von dier Hardwareebene abstrahiert.

Als erstes solltet Ihr überlegen, wieviele Taster und LEDs benötigt werden, da gehen einem bei einem Uno oder vergleichbaren Board (28 Pin ATMEGAS) schnell die Ports aus, wenn's größer wird. Darüber hinaus solltet Ihr, wenn's wirklich ernst wird, vernünftige Pläne zeichnen. Es spricht natürlich nichts dagegen, das aufm Steckbrett zu improvisieren; ein gut lesbarer Plan ist aber das A und O, um Fehler zu vermeiden. Und es macht die Kommunikation in einem Community-Projekt einfacher. Außerdem hatte ich beim Überfliegen des Threads den Eindruck, dass ein paar Grundlagen bei der Beschaltung der MIDI- und I/O-Ports und LED (Stichwort interne/externe Pullups, Vorwiderstand etc) nicht ganz sicher sitzen (korrigiert mich, wenn das nicht stimmt).

Eine "normale" Anzeige-LED hat vielleicht max. 20mA Stromaufnahme, also ist deren Innenwiderstand bereits grösser als 125Ohm.

Das stimmt so nicht, oder liest sich zumindest mißverständlich. Die Stromaufnahme einer LED, die im Datenblatt steht (meistens besagte 20 mA) ist der maximal zulässige Strom, mit dem die LED betrieben werden darf, ohne Schaden zu nehmen. Der Innenwiderstand einer LED ist mitnichten größer als 125 Ohm, im Gegenteil, er ist nahe 0. Eine LED braucht immer einen Vorwiderstand, der den Strom begrenzt. Lässt man ihn weg, steigt der Strom stark an, und die LED geht kaputt - oder der Port am µC.

Eine LED hat einen charakteristischen Wert, nämlich die Durchlassspannung. Fließt ein Strom durch eine LED, fällt über der LED eine bestimmte Spannung ab, die nur unwesentlich von der Stromstärke abhängt. Bei den meisten LED sind das so 2,2 bis 3,3 Volt. Treibe ich die LED mit 5 V, bleiben am Vorwiderstand z.B. 5 V - 2,2 V = 2,8 V über. Jetzt kann man per URI den Widerstand ermitteln, der kleinste zulässige Wert wäre dann 2,8V/20mA = 140 Ohm.

Meist kann man LEDs mit deutlich niedrigerem Strom betreiben, ohne dass die Helligkeit merklich nachlässt. Für einen Bodencontroller würde ich aber eh immer superhelle LED mit glasklarem Gehäuse empfehlen (gibt's z.B. bei Musikding). Die sind bei 2 mA immer noch so hell, dass es blendet, wodurch man sie auch auf erleuchteter Bühne gut erkennen kann - das ist mit den matten LED mit farbigem Gehäuse manchmal nicht mal bei 20 mA der Fall, besonders bei gelben.

Mehr kann ich im Moment noch nicht beitragen, ich hab noch nicht ganz den Überblick über das Projekt. Sofern es irgendwelche Zwischenstände festzuhalten gibt, könnte das fortlaufend z.B. durch editieren des ersten Beitrags des Threads gemacht werden; so kann man sich dann schnell einen Überblick verschaffen, ohne zig Seiten lesen zu müssen -

In diesem Sinne, viel Erfolg!
Gruß, Nils

 

[axefx]

Moin,

Moin Nils, schön, dass Du Dich hier mit eingeklingt hast - Willkommen! Ich versuche mal auf einige Punkte von Deinem Post einzugehen, um ein wneig "Licht" ins Dunkel zu bringen - was unser Projekt angeht:

(...)weiß also nicht genau, welchen Umfang Euer geplanter Controller haben soll.

Das Wissen wir selber noch nicht so genau, aber soweit ich OSons Ansatz der Software verstanden habe, nutzt er diese OOP - Programmierung, um sie eher "dynamisch", statt "statisch" auszurichten. Korrigiert mich, wenn ich das falsch verstehe - deshalb schreibe ich es - andere hier im Forum wissen das tausendfach besser - ich bin der Noob. Jedenfalls können jetzt schon nach belieben die Anzahl der Schalter erhöht und verringert werden und als CC oder PC genutzt werden - je nach Bedarf einfach anzupassen, was ich sehr geil finde
Im Grunde steuern wir hier alle das besagte Axe-Fx, welches im Grunde so viele Funktionen bietet, dass der Funktionsumfang für jeden anders ist, den er wohl mit einem Controller gerne steuern würde.

Was ich Euch aber aus meiner Erfahrung aus dem Ampbau und mit meinem Controller dringenst empfehlen kann ist, alles so gut wie möglich zu planen und zu dokumentieren, und das geht bei der Hardware los.

Ich denke, da ist OSon mit der Dokumentation via github.com schon ganz gut aufgestellt, da hier Veränderungen nachvollziehbar werden und auch der passende Fritzing-Schaltplan zum Stand der Dinge imme rwieder sauber hinterleggbar ist. Wenn es später an die Umsetzung geht, alles wirklich in ein gehäuse zu verbasteln gebe ich Dir aber völlig recht! Ohne nachvollziehbare Übersicht wirds dann schnell chaotisch, merke ich gerade auf meinem Breadboard, wo alle mögliche Kabelfarben gerade für 5V, GND und PIN I/O Verwendung finden. Und das bei nur 4 Schaltern .... *hust.... da muss strukturell ich aufrüsten.

Wenn Euch die Portpins ausgehen, müsst Ihr entweder auf ein Arduinoboard mit einem MEGA ausweichen, oder Porterweiterungen benutzen, worauf dann u.U. die ganze Programmierung angepasst werden muss. (...)
Als erstes solltet Ihr überlegen, wieviele Taster und LEDs benötigt werden, da gehen einem bei einem Uno oder vergleichbaren Board (28 Pin ATMEGAS) schnell die Ports aus, wenn's größer wird. Darüber hinaus solltet Ihr, wenn's wirklich ernst wird, vernünftige Pläne zeichnen.

Hat OSon (basti) HIER schonmal gut überschlagen. Er und ich fahren auf deshalb schon auf dem MEGA mit 54 I/Os, Pacosipulami wird noch mit einem UNO mit 14 I/Os dazustoßen.

Es spricht natürlich nichts dagegen, das aufm Steckbrett zu improvisieren; ein gut lesbarer Plan ist aber das A und O, um Fehler zu vermeiden. Und es macht die Kommunikation in einem Community-Projekt einfacher.

Dazu veranschlaulichen wir derzeit mit den Fritzing Schaltplänen - in der bisherigen Dimension klappt das sehr gut

Außerdem hatte ich beim Überfliegen des Threads den Eindruck, dass ein paar Grundlagen bei der Beschaltung der MIDI- und I/O-Ports und LED (Stichwort interne/externe Pullups, Vorwiderstand etc) nicht ganz sicher sitzen (korrigiert mich, wenn das nicht stimmt).

Naja, das betrifft eigentlich nur mich, aber so langsam beginne ich auch das zu schnallen, danke der Hilfe von Leuten wie beispielsweise "wildlive" und "Jojo", die da offensichtlich den vollen Durchblick haben

(...)würde ich aber eh immer superhelle LED mit glasklarem Gehäuse empfehlen (gibt's z.B. bei Musikding)

Unbedingt!

Sofern es irgendwelche Zwischenstände festzuhalten gibt, könnte das fortlaufend z.B. durch editieren des ersten Beitrags des Threads gemacht werden; so kann man sich dann schnell einen Überblick verschaffen, ohne zig Seiten lesen zu müssen -

Aus diesem Grund habe ich im ersten Beitrag auch die links gesetzt, auf die ich auch in Deinem TubeTown-thread verweise:

Diskussion hier im axefx.de Forum: http://www.axefx.de/showthread.php/1040-DYI-MIDI-Fu%C3%9Fleiste-selber-bauen-!

Software auf github.com: https://github.com/oson/midi_board_ONE
(Nochmals größten Dank an den "Konstrukteur" OSon!!!

Video-Dokumentation auf youtube: http://www.youtube.com/watch?v=dIs-Xt1zd-U&list=PLT2sYJRe7JGzRZjYknhBgOrFEbOZDuBH5

Diese drei "Anker" sollten eigentlich immer den aktuellen, letzten Stand zeigen.

In diesem Sinne, viel Erfolg!
Gruß, Nils

Mille Gracie, ich hoffe Du schaust ab und an vorbei und verfolgst es vielleicht etwas mit! Wäre schön!

 

[axefx]

Hatte schon mit Basti ein paar Ideen angerissen, aber das ist noch Zukunftsmusik ... :

Gruppen bilden, um beispielsweise CC-behaviours zu Klassifizieren:
1) SCENE CCs
2) NORMALE Stompbox CCs
3) AMP-SWITCH CCs

Wer genauer drüber nachdenkt wird schnell feststellen, dass spätestens beim auslesen vom Axe-Fx II die LED Anzeige der CC-Stati bei diesen drei Klassen verschieden zu interpretieren wäre. Wenn man das weiterspinnt und an 3 farbige LEDs denkt (wofür wir allerdings dann wirklich die PINs via ICs erweitern müssten (ICs? Richtig?) könnte man sich sowas vorstellen:

SCENE CCs -> blau
Max. 8 blaue Schalter, aber nur einer darf leuchten, wie bei einem PC! -> Alle laufen auf demselben einen CC, aber 8 unterschiedlichen values!
-> SCENE Paradigma.

Stompbox CCs -> grün
Beliebig viele Schalter können leuchten (an/aus sein) -> Jeder läuft auf eigenem CC mit Value an/aus 127/0
-> Stompox Paradigma

Amp-CCs -> rot
Axe-Fx II gibt per X/Y und 2 Blöcken 4 Amp-Kanäle her -> mindestens drei CCs pro Schalter notwendig (2x Amp CC; 1x X/Y CC, weniger geht nicht, ansonsten nicht mehr SCENES kompatibel!) In der Guppe Amp-CCs darf immer nur einer leuchten.
-> Amp-Switch Paradigma.

Würde man die Taster (und 3farbige-LEDs) also frei konfigurierbar halten und beliebig einer dieser Gruppen zuordbar machen, könnte jeder seine SCENES dahin legen, wo er sie haben will, frei wählen, wieviele es sein sollen, oder eben keine Nutzen und dafür mehr Stompbox oder Amp-Switch CCs haben ... wäre doch ne krasse Idee????

Diese "Gruppentherapie" würde sogar die Leistungsfähigkeit der MFC in den Schatten stellen *hust .... basti meinte ... vielleicht ginge da was .... vielleicht .... aber klar, erstmal die Basics ...

Diese Idee macht natürlich erst Spaß und Sinn, wenn die MIDI Leiste Statusrückmeldungen des AXE-FX interpretieren könnte - also den aktuellen Status übermittelt bekommt und die MIDI Leiste das ausliest und korrekt interpretiert.

Das wäre mein "Aufbohren" der bisherigen 2 Farben-Leds+ Linkgroup-Möglichkeit an der MFC ... Verwaltet da mal 4 Amp-Kanäle innerhalb von Scenes: Ihr braucht drei Taster, von denen mindetsens zwei leuchten und eine linkgroup. Funktioniert, ist aber nicht sehr übersichtlich ;( Es geht auch im Axe-Fx NONE Mode: 4 Amps, je ein Taster. Dann sind die aber nicht mehr Status-synchron bei Scene-Wechsel. Just sayin ...

RJ45 Uplink
Noch heikler: Man stelle sich einen uplink im Footcontroller vor: Vom Axe-Fx II per Ethercon ins DIY Board incl . Stromversorgung, von da weiter in die MFC. Problem: Signalfluss müsste beidseitig funktionieren mit beiden devices und man müsste wissen, wo der Strom anliegt und darf sich dann nicht vertun, um nicht die MFC zu schrotten - im schlimmsten Fall.

Von daher, erstmal die kleinere Variante:
MIDI Buchse phantomisieren so hatte ich es bei meiner FCB1010 gemacht. Das sollte nicht so schwer sein... der direkte 5V Eingang auf dem Arduino Board müsste dann aber nochmal zusätzlich vor Verpolung und Überspannung geschützt werden, habe gelesen, dass das von Haus nur am Boardeigenen externen Stromanschluss so ist.

Tja ... also, je länger ich träume, desto größer wird das System .... *hust ....

 

[Nils H.]

Moin,

Ich denke, da ist OSon mit der Dokumentation via github.com schon ganz gut aufgestellt, da hier Veränderungen nachvollziehbar werden und auch der passende Fritzing-Schaltplan zum Stand der Dinge imme rwieder sauber hinterleggbar ist. Wenn es später an die Umsetzung geht, alles wirklich in ein gehäuse zu verbasteln gebe ich Dir aber völlig recht! Ohne nachvollziehbare Übersicht wirds dann schnell chaotisch, merke ich gerade auf meinem Breadboard, wo alle mögliche Kabelfarben gerade für 5V, GND und PIN I/O Verwendung finden. Und das bei nur 4 Schaltern .... *hust.... da muss strukturell ich aufrüsten.

[...]

Dazu veranschlaulichen wir derzeit mit den Fritzing Schaltplänen - in der bisherigen Dimension klappt das sehr gut

Am Anfang scheint das albern, aber macht von Anfang an richtige Stromlaufpläne. Bei diesen Bildern verlierst Du die Übersicht, sobald die Bauteilezahl etwas rauf geht. Als Dokumentation sind die - meiner Meinung nach - nicht geeignet. Ist anfangs etwas mühselig, aber im Gegensatz zu diesen Fritzing-Bildern kann man auf einen Blick sehen, was in der Schaltung vorgeht und wo mögliche Probleme liegen, ohne mit dem Finger am Bildschirm virtuelle Kabel zu verfolgen.

Hat OSon (basti) HIER schonmal gut überschlagen. Er und ich fahren auf deshalb schon auf dem MEGA mit 54 I/Os, Pacosipulami wird noch mit einem UNO mit 14 I/Os dazustoßen.

Was man im Hinterkopf behalten sollte: Wenn man nicht SMD-Löten kann, ist das Arduino-Board Schrott, wenn man den AVR himmelt - und das geht schnell, z.B. durch einen falschen Vorwiderstand bei einer LED, oder wenn man einen Output-Pin, der High ist, kurzschließt. Also entweder für Experimente einen µC im PDIP-Format nutzen, oder schön aufpassen .

Mille Gracie, ich hoffe Du schaust ab und an vorbei und verfolgst es vielleicht etwas mit! Wäre schön!

Mal schauen . Im Zweifelsfall kann man mich bei Problemen ja auch direkt fragen . In Sachen Hardware auf jeden Fall, denn da habe ich mich intensiv mit auseinander gesetzt, in Sachen Software bin ich auch nicht sooooo fit und habe mich bei meinem Projekt eher durchgehangelt.

Gemäss Referenz eignen sich die Pins in diesem Zustand tatsächlich um eine LED anzusteuern - sprich um jeweils 40mA abzugeben (ziemlich krass!!!)
http://arduino.cc/de/Reference/Constants

Aufpassen! Das ist der Strom, den man maximal entnehmen / einspeisen darf. Darüber kann der Pin, der Port oder der Controller dauerhaft Schaden nehmen. Außerdem muss der Strom irgendwo hin oder irgendwo herkommen. Für die Summe der Ströme durch die GND und Versorgung gilt ein Maximum von 200 mA. Außerdem wird der Controller ganz schön heiß, wenn man's mit dem Strom übertreibt, was seine Lebensdauer drastisch verkürzen kann. Bei erhöhtem Strombedarf oder induktiven Lasten (Relais), die über wenige einstellige Miliampere hinaus gehen, würde ich immer auf externe Treiberbausteine zurück greifen.

Gruß, Nils

 

[OSon]

Also, ich würde das gesamte Projekt aktuell als "spielen mit den Möglichkeiten" nennen. Ich für meinen teil spiele aktuell gerade nur herum und Schau, was so möglich ist. Ich versuche dabei aber immer im Hinterkopf zu haben, dass ich eine beispielschaltung mit beispielcode habe. Der soll dann von jedem einfachst so erweitert werden, dass man möglichst alle seine Wünsche umsetzen kann. Möglichst... Ich weiß.. Ein sehr hohes Ziel. Auf jeden fall sehe ich da aktuell nur die Grenze im Speicher, was die funktionsvielfalt angeht.

Ich habe meinen Code mit einem dicken ONE gekennzeichnet. Und das mit dem hintergrund, dass es hier um den ersten Teil geht. Einfachstes Board ist hier möglich. Es werden ausschließlich die Pins des arduinos genutzt und angesprochen.


Danach folgt ein TWO....hoffentlich... Und hier wird auch mal multigeplext... Bei beiden muss vorher natürlich geklärt sein, wieviele Buttons und LEDs genutzt werden sollen. Maximal... Denn weglassen kann man dann ja immernoch.

Aber alles eins nach dem anderen.... Aktuell sehe ich es so, dass das recht übersichtlich ist. Es sind nur ein paar Schalter und LEDs, die abgefrag und gesetzt werden müssen. Und um das modular zu halten versuche ich das relative übersichtlich zu gestalten. Ich hoffe das gelingt mir auch weiterhin....

 

[Andy]

Ich würde euch empfehlen für die Dokumentation der Ideen eine geeignete Art zu wählen.

Da bin ich ganz auf Nils Seite. Richtig planen ist die halbe Miete!

Wobei ich verstehe, dass man beim Herumprobieren dass erst einmal ohne macht.
Aber denkt dran, die ganzen Ideen aus nem Thread zusammen zu tragen ist ab
einem gewissen Stand nicht mehr machbar.


Beispiel:
Ich hab gestern den Thread hier eine gute Stunde durchwühlt um mir die folgenden Infos zusammen zu suchen:

Wo gab es das Board nun wieder?
Was für eins war das wieder?
Wo gibt es den Compiler?
Was für Libs braucht ich und wo waren die nun wieder?
.... und, und, und. ....


Heut steht das Wesentliche schon mal gut zusammengefasst bei github.
Da kann man in 10 Minuten einsteigen.


Zurück zur Doku von Ideen:
Einfachstes Mittel, man nimmt sich ne Tabelle, bringt eine Struktur/Hierarchie/Klassifizierung, etc.
rein und füllt diese. Was dann umgesetzt wird, ist ne ganz andere Geschichte.

Alternativ kann man auch so was hier für ersten Ideen nehmen.

http://www.xmind.net/


Nutz ich recht gern um Ideen im ersten Anlauf zu sammeln.
Man kann die Einträge leicht hin- und her schieben, neu strukturieren, usw.
Zusätzlich können Kommentare eingefügt werden und ich kann mir ein Inhaltsverzeichnis für ne
Anforderungsspek, etc. generieren lassen.


Ich weiß dass ich hier altmodisch bin ....


Gruß

Andy

 

[Pacosipulami]

Aufpassen! Das ist der Strom, den man maximal entnehmen / einspeisen darf. Darüber kann der Pin, der Port oder der Controller dauerhaft Schaden nehmen. Außerdem muss der Strom irgendwo hin oder irgendwo herkommen. Für die Summe der Ströme durch die GND und Versorgung gilt ein Maximum von 200 mA. Außerdem wird der Controller ganz schön heiß, wenn man's mit dem Strom übertreibt, was seine Lebensdauer drastisch verkürzen kann. Bei erhöhtem Strombedarf oder induktiven Lasten (Relais), die über wenige einstellige Miliampere hinaus gehen, würde ich immer auf externe Treiberbausteine zurück greifen.

Gruß, Nils

Hallo Nils

Erstmal herzlich willkommen bei Axefx.de :rock:

Danke - konnte das ja auch kaum glauben (deshalb "ziemlich krass") Und klar - Du kannst nicht mehr ausgeben, also Du "einziehst" (als Elektroniker mit bald 20 Jahre Background ist mir das "bewusst" ) - sprich falls das Arduino-Board nur erst via USB gespeist wird, dann stelle ich eine solche Abgabe pro Pin eh in Frage. Generell kenne ich auch sonst keine Produkte und Anwendungen bei der die Relaisspulen direkt mittels eines µPCs angesteuert werden

Das Kit kommt morgen - und ich werde es nicht für ein MIDI-Floorboard nutzen - viel mehr gedenke ich mir meinen Dumblesipulami Preamp zu midifizieren - bzw. die Kanäle und Optionen "schaltbar" zu machen. Und genau da werde ich neben dem µPC einige 74xxx TTL Bausteine, LMxxx Treiber, Schalttransistörchen oder Optokoppler etc. verbauen.....
Erst freue ich mich aber einfach aufs tüfteln und entdecken meiner eingerosteten Digital-Skills - das könnte wirklich spannend werden!

Gruss
Pacosipulami

 

[axefx]

Das Kit kommt morgen - und ich werde es nicht für ein MIDI-Floorboard nutzen - viel mehr gedenke ich mir meinen Dumblesipulami Preamp zu midifizieren - bzw. die Kanäle und Optionen "schaltbar" zu machen.

Oh yeah, ein MIDI-Dumblesipulami-Preamp .... cool :rock: Auf den thread freue ich mich!

So, jetzt aber wieder

 

[OSon]

Alternativ kann man auch so was hier für ersten Ideen nehmen.

http://www.xmind.net/

Bah! Mindmaps! Ich habe die Dinger schon immer gehasst! ;-)

Aber mal im Ernst. Ja, ihr habt da schon Recht! Und vielleicht sollten wir die Fakten und die Ideen mal zentral irgendwo sammeln bevor sie vergessen werden. Und ob dann was und wie daraus wird, wird sich zeigen... Wir sind hier ja schon recht weit und befinden uns fast schon im Wechsel von "ich probier das mal aus" zu "so macht man's!" ;-)

Vielleicht ist Trello für sowas ganz gut geeignet... Mal schauen...

 

[Jojolamenace]

Jojo: wieso bist du geschockt über meine OOP? Ich fand, das Bot sich da doch an...

Ich wäre nie auf die Idee gekommen OOP für einen uC anzuwenden. Da hätte ich immer Angst zu viele Ressourcen (Speicher, CPU-Zeit) zu verschwenden (vielleicht, ist das auch nur die Uneinsichtigkeit von einem alten Sack). Zudem habe ich das Gefühl, dass OOP für Leute, welche sich nicht viel bis gar nicht mit Programmieren beschäftigen, schwieriger zu verstehen ist.
Mir persönlich ist es egal. Ich habe deinen Code verstanden und finde den Lösungsansatz sehr elegant. Bei einem nächsten uC Projekt werde ich die OOP Option sicher auch in Erwägung ziehen.

 

[OSon]

Wegen der Ressourcen hatte ich auch schon bedenken. ich weiss auch noch nicht, ob das berechtigte bedenken sind...

 

[Nils H.]

Wegen der Ressourcen hatte ich auch schon bedenken. ich weiss auch noch nicht, ob das berechtigte bedenken sind...

Mal als Orientierung: Die Software in meinem Controller - nicht OOP und einfach wild los programmiert - belegt ca. 15k im Flash und etwas über 1k im SRAM. Ich habe einen 328 mit 32k Flash und 2k SRAM verwendet (welcher auch im Uno-Board sitzt), der MEGA 2560 hat 256k Flash und 8k SRAM, da dürfte kaum Not bestehen, wenn man nicht vollkommen verschwenderisch mit den Ressourcen umgeht.

Gruß, Nils

 

[OSon]

Aktuell sind es ja auch wirklich nur Spielereien! Und aktuell basiert alles auf dem Mega! ;-) Und ich habe auch gelesen, dass rein von der Performance und vom Speicher der Compiler recht effizienten Code erstellen soll. Klar braucht ein Objekt mehr Platz als nur ein Haufen an Variablen, aber das sollte recht gering sein. Na mal schauen, wo es hingeht! :-D