Hallo Forum, ich bin unschlüssig... Auf einer Miniplatine habe ich 4 Drehcodierschalter die an zwei Schieberegistern hängen. Wenn ich die Eingänge der beiden Schieberegister so mit den Codierschaltern verbinde, dass ich bequem einfach zwei Bytes rein-shiften könnte, muss ich beim Routing Abstriche machen und einige Vias setzen. Sieht nicht besonders ästethisch aus. Ich könnte allerdings auch die Pins so verbinden, dass ich komplett ohne Vias auskomme und die Leiterbahnen schön übersichtlich verlegen könnte. Allerdings habe ich den Knoten dann in den gelesenen Bits und müsste diese umsortieren. Was hätte eurer Meinung nach Priorität? Schönes Platinenlayout oder leicht lesbarer Quellcode? Gespannte Grüße, Marius
Marius schrieb: > Was hätte eurer Meinung nach Priorität? Schönes Platinenlayout oder > leicht lesbarer Quellcode? Schön ist vielleicht nicht ganz das richtige Wort, eher pragmatisch. Ich würde das einfach Layout nehmen und die Bits in Software umsortieren. Auch das kann man gut lesbar in den Quelltext schreiben. Win-Win.
Was Du kannst - oder auch nicht - hängt vor allem davon ab, wie die Schalter aufgebaut (verschaltet) sind. Wie wäre es mit mehr Info und weniger Prosa? Übrigens: Ein paar Bits umzumodeln ist auch nicht so schwer. Ich schätze mal, die Dokumentation der Aktion benötigt mehr Zeit, da Du ja eventuell in 5 Jahren nochmal ran musst.
:
Bearbeitet durch User
Marius schrieb: > Ich könnte allerdings auch die Pins so verbinden, dass ich komplett ohne > Vias auskomme und die Leiterbahnen schön übersichtlich verlegen könnte. > Allerdings habe ich den Knoten dann in den gelesenen Bits und müsste > diese umsortieren. Die logische Antwort ist eigentlich, das in Software zu lösen. Denn das ist im Normalfall einfacher. Und ein sauberes Layout hat nicht nur optische Vorteile. Bei meinem Arbeitgeber würde man das jetzt natürlich in Hardware lösen. Denn die Softwareabteilung ist so agil und qualitätsorientiert, die schaffen keine Änderungen mehr. Wenn du alleine arbeitest ist die Antwort ganz klar: In Software. Man kann das Mapping auch im Quellcode schön lesbar machen, nur weil man umsortieren muss, muss das ja nicht hässlich werden.
@ TO Nur der Vollständigkeit halber: Es gibt ja noch eine dritte Alternative. (Die hast Du möglicherweise schon überlegt und ausgeschöpft). Die Zuordnung und Benennung der einzelnen Schalter, wie man sie dann auf der Platine sieht, kann im Prinzip willkürlich gewählt werden. Vielleicht hast Du ja dabei noch Variationsmöglichkeiten. Z.B. Oft will man das zwei boolesche Variablen von zwei nebeneinanderliegenden Schaltern bestimmt werden. Deren Anordnung (erst Wert A und dann B oder umgekehrt) und die absolute Zuordnung kann aber (meist) variiert werden. Anderes Beispiel sind numerische Werte. Da bevorzugt man eine Abfolge entsprechend der Wertigkeit, aber die Position der Gruppe kann evtl. verschoben werden. Wer einwendet, dass das viel Aufwand ist, der mit ein bisschen Bitschubserei vermieden werden kann, dem würde ich recht geben. Allerdings besteht eben die Möglichkeit und man kann ja mal 5 Minuten probieren ob es nicht doch ohne geht.
Nö, ich würde in Hardware verünftig machen. Alles andere hat schon wieder dieses "I failed, can you fix it in software?"-Aroma.
Wühlhase schrieb: > Nö, ich würde in Hardware verünftig machen. > > Alles andere hat schon wieder dieses "I failed, can you fix it in > software?"-Aroma. Richtig ist eigentlich, dass man abwägt, was mehr Probleme macht: - Kostet das umsortieren nennenswert Rechenzeit? - Oder macht das umverdrahten das Layout schlechter? Die Antwort in dem Fall ist ziemlich sicher: Ein sauberes Layout ist wichtiger. Buttens schlucken niemals merklich Rechenzeit, außer der Programmierer ist komplett inkompetent. Ein unsauberes Layout kann dagegen EMV-Probleme anziehen. Die Übersichtlichkeit des Quellcodes ist kein Argument, die liegt rein beim Programmierer ;-)
Marius schrieb: > Allerdings habe ich den Knoten dann in den gelesenen Bits und müsste > diese umsortieren. Das ist mit einem Array doch einfach und schnell gemacht. Ein übersichtliches Layout würde ich persönlich immer vorziehen.
jemand schrieb: > Die logische Antwort ist eigentlich, das in Software zu lösen. > Denn das ist im Normalfall einfacher. Und ein sauberes Layout hat nicht > nur optische Vorteile. So ist es. Ich habe schon Layouts gesehen, wo jedes Signal gefühlt 20-mal das Layer wechselt. Irgendeine Fehlersuche ist praktisch unmöglich. Das Zuordnen in SW ist wesentlich einfacher und es erhöht nicht die Ausfallwahrscheinlichkeit. Wenn es übersichtlich sein soll, schreibt man einmalig eine Funktion für das Einlesen und ruft dann nur noch diese auf. jemand schrieb: > Denn die Softwareabteilung ist so agil und qualitätsorientiert, die > schaffen keine Änderungen mehr. Ja, wenn die SW getrennt entwickelt wird, hat man regelmäßig die Brille auf. Ich hatte mal ein Gerät, wo manche Kunden ein Signal invertiert brauchten. Es führte absolut kein Weg dahin, die SW anzupassen. Also mußte extra eine neue Platine erstellt werden mit einem Transistor als Inverter. Ein riesen Aufwand und auch für die Lagerhaltung und den Verkauf zweier Gerätevarianten. Irgendwann schied der Programmierer aus und die SW landete bei mir. Meine erste Aktion war natürlich, eine absolut winzige Routine zu schreiben, die einen Parameter aus dem EEPROM las und mit dem Eingang EXOR verknüpfte. So konnte auch nachträglich der Kunde selber den Pegel umkonfigurieren.
:
Bearbeitet durch User
Hi. Ich würd das Problem in HW lösen. Auch wenn die SW automatisch läuft, so gibts bei jedem Ausführen unnötigen overhead. Für nicht so allgemeine Antworten bräuchte man etwas mehr Infos...
bronk schrieb: > Hi. > Ich würd das Problem in HW lösen. > Auch wenn die SW automatisch läuft, so gibts bei jedem Ausführen > unnötigen overhead. Der vollkommen egal ist, solange nicht nennenswert CPU-Zeit verbraten wird. Dogmen sind selten sinnvoll und zielführend. Der Klassiker sind verdrehte Datenleitungen bei externen SRAMs. Dem SRAM ist es egal, ob D0 wirklich D0 ist oder nicht!
Marius schrieb: > Auf einer Miniplatine habe ich 4 Drehcodierschalter die an zwei > Schieberegistern hängen. > > Wenn ich die Eingänge der beiden Schieberegister so mit den > Codierschaltern verbinde, dass ich bequem einfach zwei Bytes > rein-shiften könnte, muss ich beim Routing Abstriche machen und einige > Vias setzen. Sieht nicht besonders ästethisch aus. Meinst du mit ästhetisch, dass die Leiterzüge dann schön gleichmässig gezogen werden können? Es gibt einige Anforderungen an Platinen, Ästhetik gehört im Normalfall nicht dazu. Noch dazu, da sie sowieso jeder anders empfindet. Wenn es deinem Auge weh tut, dann sortier halt in Software um. Ich würde es jedenfalls streng logisch machen. Der einzige wirkliche Grund dagegen: du willst/musst ne einseitige Platine haben.
Wenn der Schaltplan gut benamt ist, dann kann die HW auch schön (ohne Vias) werden. Einfacher zu debuggen, einfacher zu verfolgen, einfach schön. Wichtig ist nur, dass es genau eine "Übersetzungstabelle" im Schaltplan gibt: - Entweder an den 4 Schaltern stehen die Signale der Schieberegister, z.B. SR1_7 als Schieberegister1 Bit7 - ODER an den Schieberegister stehen die Signale der Schalter, z.B. DSA_3 als Drehschalter A Bit 3 Schlimm ist, wenn die Signalnamen weder am Schalter, noch am Schieberegister passen oder gar nur wild gezogen sind.
Eigentlich ist die Frage abhängig von demjenigen, der es ausführt - was kannst du denn besser, wobei passieren dir weniger Fehler, welche Fehler fallen wahrscheinlicher auf und lassen sich leichter beseitigen? Im einer schlechten Entwicklungsgruppe gilt: Softwerker werden sagen: Das soll die Hardware machen. Hardwerker: Das soll die Software machen. Projektleiter: OK, ich schreibs beiden Dienstleistern ins Lastenheft Manager: KAPUTT! REPARIEREN! SOFORT! Consultant: We very sorry but this not specified in work contract. Please allow to bill extra 20 hours for fix strange pin inputs. Will start work very promptly, but all programmer on holiday for Chinese New Year. In einer guten Entwicklungsgruppe wird der Projektleiter abwägen: - Meine Softwerker sind gut und haben Zeit (der Projektleiter wird sagen "Kapazität"), die Schalter einzulesen ist nicht zeitkritisch, das kann man einfach über eine Übersetzungstabelle anpassen, Fehler kann man per Remote-Firmware-Update ausbessern gegen - So zuverlässig, wie unsere Layouter mit DRC und der Platinenhersteller die Zuordnung richtig machen, sind meine Softwerker nicht, die Signale sind langsam, da ist EMV irrelevant, wenn einer unserer Praktikanten den Code zum Einlesen nicht versteht und mitten in der Produktion da einen Fehler einbaut, muss der Service rausfahren und 500 Geräte neu flashen, denn beim darauf herumdrücken fällt das dem "Tester" sicher nicht auf... MfG, Arno
Hardware vernünftig machen. Die Vias stören doch nicht und man kann die auch so anordnen das es dennoch ästhetisch aussieht. Wenn Du später mal andere Kodierschalter benutzt mußt Du bei der Softwarelösung unter Umständen die Software ändern. Was auch noch gegen die Softwarelösung spricht ist ein evtueller Reparaturfall. Man tut sich beim Messen leichter wenn die Bits/Bytes logisch, entsprechend ihrer Wertigkeit angeordnet sind. Eine durcheinandergewürfelte Bitfolge macht so etwas nur unnötig kompliziert.
Ich hatte das Problem in anderer Form auch schon ein paar mal: 7- bzw. 16-Segment-Displays an den Treibern anschliessen. Ich habe mich immer für die Softwarelösung entschieden, da es für mich einfacher war und ich nur einseitige Platinen herstellen mußte. Ich hab mir dabei auch schon richtig üble Dinge angetan: eine Platine mit 8 MAX7219 und 16 4fach-7-Segment-Displays und sogar welche mit gemeinsamer Anode. D.h. ein Ausgabebyte ist dann nicht mehr für eine komplette Stelle, sondern für ein Segment aller 8 Stellen zuständig. Allerdings einmal eine Funktion für die Umsetzung geschrieben und über diese das Display normal bedienen.
A. S. schrieb: > Wenn der Schaltplan gut benamt ist, dann kann die HW auch schön (ohne > Vias) werden. Einfacher zu debuggen, einfacher zu verfolgen, einfach > schön. > > Wichtig ist nur, dass es genau eine "Übersetzungstabelle" im Schaltplan > gibt: > - Entweder an den 4 Schaltern stehen die Signale der Schieberegister, > z.B. SR1_7 als Schieberegister1 Bit7 > - ODER an den Schieberegister stehen die Signale der Schalter, z.B. > DSA_3 als Drehschalter A Bit 3 > > Schlimm ist, wenn die Signalnamen weder am Schalter, noch am > Schieberegister passen oder gar nur wild gezogen sind. Also wenn ich einen Schaltplan sehen würde, bei dem die Anschlüsse einzelner Codierschalter wirr mit 2 Schieberegistern verbunden sind, eventuell noch die Leitungen eines Schalters an unterschiedliche Schieberegister, dann würde ich mir denken welcher Idiot hat denn das verbrochen. Es geht hier um eine Miniplatine mit 4 Codierschaltern, da muss man ja auch unheimlich viel debuggen. Das Layout und die Verbindungen kontrollieren macht man einmal. Ich finde, das einzige Argument gegen Vias ist, ob die Stückkosten einer zweiseitigen Platine deutlich höher sind im Vergleich zu einer einseitigen.
Marius schrieb: > Wenn ich die Eingänge der beiden Schieberegister so mit den > Codierschaltern verbinde, dass ich bequem einfach zwei Bytes > rein-shiften könnte, muss ich beim Routing Abstriche machen und einige > Vias setzen. Sieht nicht besonders ästethisch aus. > > Ich könnte allerdings auch die Pins so verbinden, dass ich komplett ohne > Vias auskomme und die Leiterbahnen schön übersichtlich verlegen könnte. Wie's aussieht, interessiert kein Schwein. Wenn ich aber dadurch z.B. mit einer einseitigen Platine auskomme, dann mach ich's ganz sicher so. Aber auch wenn nicht: weniger Kreuzungen im Netz sind immer gut. Tendenziell wird die Platine dadurch kleiner, ihre Ausfallwahrscheinlichkeit sinkt, sie ist weniger anfällig gegen einfallende EM und strahlt weniger EM ab. > Allerdings habe ich den Knoten dann in den gelesenen Bits und müsste > diese umsortieren. Nunja, das ist trivial. Und da es nur darum geht, Codierschalter einzulesen, was eher selten geschehen dürfte, typisch sogar nur einmal in der gesamten Programmlaufzeit, spielen die acht Takte/16 Byte Codespace, die man zum umsortieren von vier Bits maximal benötigt (AVR8 angenommen) ganz sicher keine Rolle. > Was hätte eurer Meinung nach Priorität? Schönes Platinenlayout oder > leicht lesbarer Quellcode? Man kann durchaus beides haben. Ist hier schon damit getan, den empfangenen Bits die passenden Namen zu geben, dann ist/sind die Routine(n) zum Umsortieren selbiger selbsterklärend. Zeno schrieb: > Was auch noch gegen die Softwarelösung spricht ist ein evtueller > Reparaturfall. Man tut sich beim Messen leichter wenn die Bits/Bytes > logisch, entsprechend ihrer Wertigkeit angeordnet sind Ach watt. Es muss nur auf dem Schaltplan korrekt beschriftet sein. Wenn das Signal von z.B. "SW3.1" nicht so kommt, wie erwartet, dann messe ich "SW3.1". Ob die Nachbarn "SW3.0" und "SW3.2" heißen oder irgendwas anderes sind, spielt dafür überhaupt keine Rolle.
Beitrag "Re: [V] Nixiuhr zu verkaufen" Logic follows Layout. Hardware mit minimalem Layoutstress, den Rest kodiert die Software. Diese Tabelle muss man einmalig aufstellen und gut.
1 | // Bitnummern für Segmente
|
2 | // verwürfelte Bitzuordnung zur Erleichterung des Hardwarelayouts
|
3 | |
4 | const uint8_t segments[7][10] PROGMEM = |
5 | {{21, 19, 18, 17, 7, 6, 5, 4, 3, 20}, // linke Anzeige |
6 | {11, 9, 23, 22, 2, 1, 15, 14, 13, 10}, |
7 | {45, 43, 42, 41, 31, 30, 29, 28, 27, 44}, |
8 | {35, 33, 47, 46, 26, 25, 39, 38, 37, 34}, |
9 | {69, 67, 66, 65, 55, 54, 53, 52, 51, 68}, |
10 | {59, 57, 71, 70, 50, 49, 63, 62, 61, 58}, // rechte Anzeige |
11 | { 0, 12, 36, 0, 0, 0, 0, 0, 0, 0}}; // DOT 1&2 |
12 | |
13 | // setzt eine Zahl einer einzelnen Stelle
|
14 | // bisherige Zahlen bleiben unverändert, somit können auch mehrere Segmente gleichzeitig leuchten
|
15 | |
16 | void set_number(uint8_t digit, uint8_t number) { |
17 | uint8_t byte, bit, bitnumber; |
18 | |
19 | bitnumber = pgm_read_byte(&segments[digit][number]); |
20 | byte = bitnumber / 8; |
21 | bit = bitnumber % 8; |
22 | nixi[byte] |= (1<<bit); |
23 | }
|
Falk B. schrieb: > Logic follows Layout. Hardware mit minimalem Layoutstress, den Rest > kodiert die Software. Diese Tabelle muss man einmalig aufstellen und > gut. Wobei ein table lookup längst nicht immer der Weisheit letzter Schluss ist. In der Anwendung, um die es hier geht, ist sie es nicht. Weder bezüglich der Geschwindigkeit noch bezüglich des Codespace-Bedarfs. Und wohl auch nicht bezüglich der Lesbarkeit. Aber natürlich gibt es sehr viele Anwendungen, wo eine Tabelle wirklich die bestmögliche Lösung ist, insbesondere dann, wenn auf Geschwindigkeit optimiert werden muss.
Peter D. schrieb: > jemand schrieb: >> Die logische Antwort ist eigentlich, das in Software zu lösen. >> Denn das ist im Normalfall einfacher. Und ein sauberes Layout hat nicht >> nur optische Vorteile. > So ist es. > Ich habe schon Layouts gesehen, wo jedes Signal gefühlt 20-mal das Layer > wechselt. Irgendeine Fehlersuche ist praktisch unmöglich. Vor Kurzem hatte ich es mit einem Motorcontroller von ST zu tun, die Bits vom Statusregister sind scheinbar beliebig invertiert, also Busy - active low, overcurrent - active high, wrong command - active low. Sowas ist einfach kein Spass. Im hier geschilderten Fall wuerde ich also eher eine Leiterbahnkreuzung eingehen, um einen sauberen Schaltplan zu erhalten. Der Schritt steht naemlich vor der Programmierung, da sollte man so wenig wie moeglich an Kompromissen mitschleppen. Es sammeln sich sowieso gern mehrere an. Andererseits darf sich das Layout dadurch nicht gross verkomplizieren, das waers natuerlich auch nicht wert.
Noscript schrieb: > Also wenn ich einen Schaltplan sehen würde, bei dem die Anschlüsse > einzelner Codierschalter wirr mit 2 Schieberegistern verbunden sind, > eventuell noch die Leitungen eines Schalters an unterschiedliche > Schieberegister, dann würde ich mir denken welcher Idiot hat denn das > verbrochen. So ein Schaltplan ist nicht wirr! Die 16 Leitungen sind ein "Bus". Und die Zuordnung ist direkt lesbar. > Es geht hier um eine Miniplatine mit 4 Codierschaltern, da muss man ja > auch unheimlich viel debuggen. Das Layout und die Verbindungen > kontrollieren macht man einmal. Ich finde, das einzige Argument gegen > Vias ist, ob die Stückkosten einer zweiseitigen Platine deutlich höher > sind im Vergleich zu einer einseitigen. Doch. Fehler passieren, egal ob im Layout, im Schaltplan, was auch immer. Mir sind 16 Leitungen straight im Layout einfach lieber. Die genialsten Lösungen sind einfach, Kompliziert kann jeder (Koroljow)
Beitrag #5933517 wurde vom Autor gelöscht.
Marius schrieb: > Wenn ich die Eingänge der beiden Schieberegister so mit den > Codierschaltern verbinde, dass ich bequem einfach zwei Bytes > rein-shiften könnte, muss ich beim Routing Abstriche machen und einige > Vias setzen. Sieht nicht besonders ästethisch aus. Das ist Anfänger Frage. Deine Platine geht nicht zum Schönheitswettbewerb. Und Vias schaden auch nicht, notfalls lässt man das Ganze mit entspr. Programm bzw. Script prüfen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.