Ampelschaltung

[Moritz R. (moritz_r483)]

Hallo,

ich habe ein kleines Problem mit einer Ampelschaltung.
Die Schaltung für die zwei Ampeln (main und side) funktionieren.
Jetzt wollte ich eine Fußgängerampel integrieren die folgendes tun soll:

- nach dem drücken des BTN0 wird ein Merker gesetzt
- Wenn die Ampel Main im State Green ist, soll die Fußgängerampel rot 
leuchten
- Die Ampel Main durchläuft weiterhin die normalen Zyklus von grün -> 
gelb-> rot -> rotgelb -> grün
- allerdings soll die Fußgängerampel dann einen Zyklus lang aktiv sein.
- also wenn die Ampel Main grün, gelb, gelbrot ist soll die 
Fußgängerampel rot leuchten und wenn die Ampel Main rot leuchtet, soll 
die Fußgängerampel umschalten auf grün.
- die Fußgängerampel soll sich ausschalten sobald die Ampel Main wieder 
im Zustand Green ankommt und warten bis der Taster BTN0 wieder gedrückt 
wird.

Der Code dazu ist folgender, allerding habe ich Probleme mit dem 
aktivieren und deaktivieren der Fußgängerampel für genau einen Zyklus.
Hat jemand einen Tipp?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.all;

entity TOP is
    Port (
        CLK, SW, BTN0: in bit;
        LEDMAINR, LEDSIDER, LEDMAING, LEDSIDEG, LEDPEDG, LEDPEDR: out bit
    );
    constant TRED: unsigned (3 downto 0) := "0010";
    constant TREDAMBER: unsigned (3 downto 0) := "0010";
    constant TGREEN: unsigned (3 downto 0) := "0010";
    constant TAMBER: unsigned (3 downto 0) := "0010";
    constant PED_CYCLE_LENGTH: integer := 10; -- Define the length of one cycle of the pedestrian lights
    constant DIVBY: integer := 100000000;
end TOP;

architecture Behavioral of TOP is
    component PWM is
        Port (
            CLK: in bit;
            DUTY: in unsigned (7 downto 0);
            PWMOUT: out bit
        );
    end component;
    
    signal DUTYMAINR, DUTYMAING, DUTYSIDER, DUTYSIDEG, DUTYPEDG, DUTYPEDR: unsigned (7 downto 0);
    signal CNTPHASE: unsigned (3 downto 0);
    signal STB: bit;
    signal CNTSTB: integer;
    type MSTATE is (INIT, RED, REDAMBER, GREEN, AMBER);
    signal STATE: MSTATE;
    signal PEDESTRIAN_ACTIVE: boolean := false;
    signal PEDESTRIAN_DURATION: integer := 0; -- Counter for pedestrian light duration
    signal PEDESTRIAN_REQUEST: boolean := false;
begin

    strobe: process(CLK)
    begin
        if CLK='1' and CLK'event then
            if (CNTSTB /= (DIVBY-1)) then
                STB <= '0';
                CNTSTB <= CNTSTB + 1;
            else
                STB <= '1';
                CNTSTB <= 0;
            end if;
        end if;
    end process strobe;

    STATE1: process(CLK, STB, BTN0)
    begin
        if CLK='1' and CLK'event then
            if (CNTPHASE = 0) then
                case STATE is
                    when INIT =>
                        STATE <= GREEN;
                        CNTPHASE <= TGREEN;
        
                    when RED =>
                        STATE <= REDAMBER;
                        CNTPHASE <= TREDAMBER;
           
                    when REDAMBER =>
                        STATE <= GREEN;
                        CNTPHASE <= TGREEN;
                      
                    when GREEN =>
                        STATE <= AMBER;
                        CNTPHASE <= TAMBER;
                      
                    when AMBER =>
                        STATE <= RED;
                        CNTPHASE <= TRED;
              
                end case;
                -- Reset pedestrian duration counter at the beginning of a cycle
                    if PEDESTRIAN_ACTIVE = false then
                        PEDESTRIAN_DURATION <= PED_CYCLE_LENGTH;
                    end if;
            elsif (STB = '1') then
                CNTPHASE <= CNTPHASE - 1;
                
                -- Decrement pedestrian duration counter during each clock cycle
                if PEDESTRIAN_DURATION > 0 then
                    PEDESTRIAN_DURATION <= PEDESTRIAN_DURATION - 1;
                end if;
            end if;

            -- Set pedestrian flag if BTN0 pressed and the system is in GREEN state
            if BTN0 = '1' and STATE = GREEN then
                PEDESTRIAN_REQUEST <= true;
            end if;

            -- Activate pedestrian light if there is a pedestrian request and the system is in GREEN state
            PEDESTRIAN_ACTIVE <= PEDESTRIAN_REQUEST and STATE = GREEN;

            -- Deactivate pedestrian light after it gets to the GREEN state again
            if STATE = GREEN and PEDESTRIAN_ACTIVE = true then
                PEDESTRIAN_REQUEST <= false; -- Reset the pedestrian request flag
        end if;
        end if;
    end process STATE1;

    mr: PWM Port map (
        CLK => CLK,
        DUTY => DUTYMAINR,
        PWMOUT => LEDMAINR
    );
    mg: PWM Port map (
        CLK => CLK,
        DUTY => DUTYMAING,
        PWMOUT => LEDMAING
    );
    sr: PWM Port map (
        CLK => CLK,
        DUTY => DUTYSIDER,
        PWMOUT => LEDSIDER
    );
    sg: PWM Port map (
        CLK => CLK,
        DUTY => DUTYSIDEG,
        PWMOUT => LEDSIDEG
    );
    pg: PWM Port map (
        CLK => CLK,
        DUTY => DUTYPEDG,
        PWMOUT => LEDPEDG
    );
    pr: PWM Port map (
        CLK => CLK,
        DUTY => DUTYPEDR,
        PWMOUT => LEDPEDR
    );

    STATE2: process(CLK)
    begin
        if CLK='1' and CLK'event then
            case STATE is
                when RED =>
                    DUTYMAINR <= "10000000";
                    DUTYMAING <= "00000000";
                    DUTYSIDER <= "00000000";
                    DUTYSIDEG <= "10000000";
                     if PEDESTRIAN_ACTIVE and PEDESTRIAN_DURATION > 0 then
                        DUTYPEDR <= "00000000";  -- Pedestrian light ON
                        DUTYPEDG <= "10000000";
                    else
                        DUTYPEDG <= "00000000";
                        DUTYPEDR <= "00000000";  -- Pedestrian light OFF
                    end if;
                when REDAMBER =>
                    DUTYMAINR <= "01110000";
                    DUTYMAING <= "00010000";
                    DUTYSIDER <= "01110000";
                    DUTYSIDEG <= "00010000";
                     if PEDESTRIAN_ACTIVE and PEDESTRIAN_DURATION > 0 then
                        DUTYPEDR <= "10000000";
                        DUTYPEDG <= "00000000";  -- Pedestrian light ON
                    else
                        DUTYPEDG <= "00000000";
                        DUTYPEDR <= "00000000"; 
                    end if; -- Pedestrian light OFF  -- Pedestrian light OFF
                when GREEN =>
                    DUTYMAINR <= "00000000";
                    DUTYMAING <= "10000000";
                    DUTYSIDER <= "10000000";
                    DUTYSIDEG <= "00000000";
                    if PEDESTRIAN_ACTIVE and PEDESTRIAN_DURATION > 0 then
                        DUTYPEDR <= "10000000";
                        DUTYPEDG <= "00000000";  -- Pedestrian light ON
                    else
                        DUTYPEDG <= "00000000";
                        DUTYPEDR <= "00000000";  -- Pedestrian light OFF
                    end if;
                when AMBER =>
                    DUTYMAINR <= "01110000";
                    DUTYMAING <= "00010000";
                    DUTYSIDER <= "01110000";
                    DUTYSIDEG <= "00010000";
                     if PEDESTRIAN_ACTIVE and PEDESTRIAN_DURATION > 0 then
                        DUTYPEDR <= "10000000";
                        DUTYPEDG <= "00000000"; -- Pedestrian light ON
                    else
                        DUTYPEDG <= "00000000";
                        DUTYPEDR <= "00000000";
                     end if;  -- Pedestrian light OFF
                when others =>
                    DUTYMAINR <= "10000000";
                    DUTYMAING <= "00000000";
                    DUTYSIDER <= "10000000";
                    DUTYSIDEG <= "00000000";
                    DUTYPEDG <= "00000000";
                    DUTYPEDR <= "00000000";  -- Pedestrian light OFF
            end case;
        end if;
    end process STATE2;
end Behavioral;

[Helmut -. (dc3yc)]

Ich weiß zwar nicht, welche Programmiersprache das ist, weswegen ich 
nicht helfen kann. Aber es wäre schön, wenn du dich an die Forenregeln 
halten würdest:

Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Danke.

[Rick D. (rickdangerus)]

Ohne (sinnvolle) Testbench macht debuggen keinen Spaß!
Kannst du deine Testbench noch anhängen?

[Marcel V. (mavin)]

Helmut -. schrieb:
> Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Ein zusätzlicher Text zum Dateianhang hat aber den Vorteil, dass man den 
Sourcecode sofort von Unterwegs aus lesen kann und nicht erst warten 
muss, bis man ihn erst zu Hause mit dem Programm öffnen kann.

[Steve van de Grens (roehrmond)]

Marcel V. schrieb:
> nicht erst warten
> muss, bis man ihn erst zu Hause mit dem Programm öffnen kann.

???

Ich kann angehängte Quelltexte direkt auf dem Android Smartphone öffnen. 
Kann mir auch kaum vorstellen, dass das auf anderen Geräten nicht geht.

[Max M. (fpga_eth)]

Helmut -. schrieb:
> Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Nun anstatt OT zu generieren und sich darüber zu beschweren, könntest du 
einfach kurz einen mod benachrichtigen der dies kurz verbessern kann. 
Dein beitrag (wie auch dieser hier) helfen dem TO nicht weiter und sind 
OT.

@ Mod: diesen OT post (inkl. diesem) bitte löschen

[Christian K. (chkddd)]

Das Verhalten der Fußgängersignale ist nach RiLSA überhaupt nicht 
zulässig.

[Wegstaben V. (wegstabenverbuchsler)]

Christian K. schrieb:
> Das Verhalten der Fußgängersignale ist nach RiLSA überhaupt nicht
> zulässig.

welches Schaltverhalten genau hast du identifiziert?
Wie müsste man es anpassen, damit es RiLSA konform wird?

[Re D. (re_d228)]

Christian K. schrieb:
> Das Verhalten der Fußgängersignale ist nach RiLSA überhaupt nicht
> zulässig.

Es ist doch offensichtlich, dass hier jemand seine Hausaufgaben macht. 
Troll wo anders.

[Christian K. (chkddd)]

Wegstaben V. schrieb:
> Christian K. schrieb:
>> Das Verhalten der Fußgängersignale ist nach RiLSA überhaupt nicht
>> zulässig.
>
> welches Schaltverhalten genau hast du identifiziert?
> Wie müsste man es anpassen, damit es RiLSA konform wird?

Das Ausschalten der Fußgängersignale.

[Joe G. (feinmechaniker)]

Moritz R. schrieb:
> Hat jemand einen Tipp?

Ja. Entwerfe für dein Problem einen endlichen Automaten (finite state 
machine) und setze ihn in der Programmiersprache deiner Wahl um.

[Christian K. (chkddd)]

Wegstaben V. schrieb:
> Christian K. schrieb:
>> Das Verhalten der Fußgängersignale ist nach RiLSA überhaupt nicht
>> zulässig.
>
> welches Schaltverhalten genau hast du identifiziert?
> Wie müsste man es anpassen, damit es RiLSA konform wird?

Das Ausschalten der Fußgängersignale.
Fußgängersignale dürfen nicht nur auf Bedarf Ein-/Ausgeschaltet werden 
sondern sind durchgehend in Betrieb entweder Zeigen die Freigabe oder 
Gesperrt.

[Re D. (re_d228)]

Christian K. schrieb:
> Das Ausschalten der Fußgängersignale.
> Fußgängersignale dürfen nicht nur auf Bedarf Ein-/Ausgeschaltet werden
> sondern sind durchgehend in Betrieb entweder Zeigen die Freigabe oder
> Gesperrt.

Wenn  das dein einziges Problem ist, dann solltest du noch mal in die 
RiLSA schauen. Fußgängerampeln schalten nicht mit rot für den 
"Querverkehr" auf grün, sondern warten die Räumzeit ab.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Christian K. schrieb:
> Fußgängersignale dürfen nicht nur auf Bedarf Ein-/Ausgeschaltet werden
> sondern sind durchgehend in Betrieb entweder Zeigen die Freigabe oder
> Gesperrt.

Dann sind eben viele Fußgängersignale nicht RiLSA-konform. Trotzdem 
existieren sie im deutschen Straßenverkehr.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Moritz R. schrieb:
> also wenn die Ampel Main grün, gelb, gelbrot ist soll die Fußgängerampel
> rot leuchten und wenn die Ampel Main rot leuchtet, soll die
> Fußgängerampel umschalten auf grün.
Ich würde da noch eine Sekunde warten, bis der letzte Rotlichtsünder 
über den (noch leeren) Fußgängerübergang drüber ist. Und ich würde die 
Fußgängerampel schon deutlich eher rot schalten, vor die Straße auf grün 
geht.

Ein Tipp: einfach mal eine echte Fußgängerampel anschauen.

Andreas S. schrieb:
> Christian K. schrieb:
>> Fußgängersignale dürfen nicht nur auf Bedarf Ein-/Ausgeschaltet werden
>> sondern sind durchgehend in Betrieb
> Dann sind eben viele Fußgängersignale nicht RiLSA-konform. Trotzdem
> existieren sie im deutschen Straßenverkehr.
"Viele" kann nich sein. Denn ich kenne keine einzige, bei der die 
Straßenampel grün zeigt und die Fußgängerampel abgeschaltet ist. Was es 
allerdings gibt, ist gelbes Blinklicht auf der Straße, so lange die 
Fußgängerampel aus ist.

Moritz R. schrieb:
> Hat jemand einen Tipp?
Mein Ansatz wäre sowas wi das da im 
Beitrag "Re: Ampelsteuerung"

> Hat jemand einen Tipp?
die Sensitivliste ist falsch:

    STATE1: process(CLK, STB, BTN0)
    begin
        if CLK='1' and CLK'event then
        :

Da gehört nur CLK rein, die anderen beiden Signale sind unnötig.

Und noch ein Tipp: verwende die Funktion rising_edge() statt nur 'event.

Max M. schrieb:
> könntest du einfach kurz einen mod benachrichtigen der dies kurz
> verbessern kann.
Kann er nicht. Das muss der TO am gleich von Anfang an selber richtig 
machen und die Bedienungsanleitung über der Texteingabebox beachten. Und 
zudem war der Thread schon 6 Wochen tot und begraben, wozu für OT 
ausbuddeln?

[Re D. (re_d228)]

Lothar M. schrieb:
> Ich würde da noch eine Sekunde warten, bis der letzte Rotlichtsünder
> über den (noch leeren) Fußgängerübergang drüber ist. Und ich würde die
> Fußgängerampel schon deutlich eher rot schalten, vor die Straße auf grün
> geht.

Wie gesagt, wie lang zu warten ist, muss man ausrechen. Nennt sich 
Zwischenzeit und steht im Regelwerk.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Lothar M. schrieb:
> Andreas S. schrieb:
>> Christian K. schrieb:
>>> Fußgängersignale dürfen nicht nur auf Bedarf Ein-/Ausgeschaltet werden
>>> sondern sind durchgehend in Betrieb
>> Dann sind eben viele Fußgängersignale nicht RiLSA-konform. Trotzdem
>> existieren sie im deutschen Straßenverkehr.
> "Viele" kann nich sein. Denn ich kenne keine einzige, bei der die
> Straßenampel grün zeigt und die Fußgängerampel abgeschaltet ist.

Es war nie die Rede davon, dass die Straßenampel grün zeige. Sog. 
"Bedarfsampeln" bzw. "Schlafampeln" werden per Knopfdruck eingeschaltet 
und beginnen dann mit einer kurzen Grünphase für die Straße und Rotphase 
für Fußgänger. Und nachdem der ganze Zyklus, d.h. der Grünphase für die 
Straßenüberquerung der Fußgänger, abgeschlossen ist, schalten sie sich 
wieder aus.

Eine durchaus interessante Betrachtung, ob für solch eine "Schlafampel" 
eine Benutzungspflicht besteht, findet sich hier:
https://www.haufe.de/recht/deutsches-anwalt-office-premium/zfs-72015-benutzungspflicht-einer-schlafampel-fuer-den-fussgaengerverkehr_idesk_PI17574_HI8493238.html

Das ist wohlgemerkt die Meinung eines Rechtsanwalts. Was in dem Verweis 
auf "Hentschel/König/Dauer, Kommentar zum Straßenverkehrsrecht, 41. 
Auflage, § 37 Rn 35" beschrieben wird, habe ich nicht recherchiert, da 
es im Kontext dieses Threads auch völlig irrevant ist. Hier geht es ja 
nur um die Existenz von (nicht defekten) Lichtzeichenanlagen, bei denen 
die Fußgängerzeichen im Normalzustand ausgeschaltet sind.

Auch in der Wikipedia wird die "Schlafampel" ausdrücklich erwähnt:
https://de.wikipedia.org/wiki/Ampel

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andreas S. schrieb:
> Es war nie die Rede davon, dass die Straßenampel grün zeige.
Kann man aber ohne Widerspruch aus der Formulierung des TO genau so 
herleiten, denn

Moritz R. schrieb:
> die **Fußgängerampel** soll sich **ausschalten** sobald die *Ampel Main*
> wieder im Zustand Green ankommt
Da steht eben nichts davon, dass die Straßenampel ebenfalls 
ausgeschaltet wird.

Deshalb wäre es sinnvoll, gleich zu Beginn mit einem Zeitdiagramm die 
Abfolge der Hell- und Dunkelphasen der Lampen aufzuzeigen. Dann sieht 
man auch gleich, wie viele Zustände man für den Gesamtablauf braucht.

[Frank E. (Firma: Q3) (qualidat)]

Ich würde das Programm grundsätzlich anders aufbauen, nicht so ein 
"Friedhof" aus 1000x wenn-dann-sonst, wo keiner mehr durchblickt ...

Die Ampelschaltung ist doch ein immer wiederkehrender Zyklus, bestehend 
aus einzelnen Schritten, von denen einige (Fußgänger-Bedarfsampel) 
optional sind, d.h. ggf. übersprungen werden (je nachdem, ob jemand die 
zugehörige Taste gedrückt hat).

Also würde ich mir eine tabellarische Notierung ("Script") ausdenken, 
was diese Schritte, ihre Dauer und Bedinungen enthält, ggf. sogar auf 
externem Datenträger (SD-Karte), so dass man jederzeit ohne 
Neuprogrammierung das Verhalten anpassen kann.

Die Tabelle könnte folgenden Aufbau haben:

- für jeden Schritt eine Zeile
- jede Zeile besteht pro Ampel-LED aus einem Zeichen
 diese Zeichn könnten sein 0=aus, 1=unbedingt an, 2=bedingt an

usw. ...

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Frank E. schrieb:
> ggf. sogar auf
> externem Datenträger (SD-Karte), so dass man jederzeit ohne
> Neuprogrammierung das Verhalten anpassen kann.

Solch ein Dateisystem in einer (V)HDL-Beschreibung zu realisieren, 
dürfte den Aufwand unglaublich in die Höhe treiben. Das mag zwar in der 
Simulation funktionieren, bei der einem auch Dateioperationen zur 
Verfügung stehen, nicht jedoch bei der Synthese für ein FPGA o.ä..

[Manfred P. (pruckelfred)]

Lothar M. schrieb:
> Ein Tipp: einfach mal eine echte Fußgängerampel anschauen.

Warum, wenn man doch im Forum fragen kann?

Lothar M. schrieb:
> Ich würde da noch eine Sekunde warten, bis der letzte Rotlichtsünder
> über den (noch leeren) Fußgängerübergang drüber ist. Und ich würde die
> Fußgängerampel schon deutlich eher rot schalten, vor die Straße auf grün
> geht.

Wer nicht mit geschlossenen Augen durch die Gegend fährt / läuft, kennt 
diese Totzeiten, wo alles Rot ist.

Andreas S. schrieb:
> Es war nie die Rede davon, dass die Straßenampel grün zeige. Sog.
> "Bedarfsampeln" bzw. "Schlafampeln" werden per Knopfdruck eingeschaltet
> und beginnen dann mit einer kurzen Grünphase für die Straße und Rotphase
> für Fußgänger. Und nachdem der ganze Zyklus, d.h. der Grünphase für die
> Straßenüberquerung der Fußgänger, abgeschlossen ist, schalten sie sich
> wieder aus.

Sind das irgendwelche landesspezifischen Sonderlocken?

In meiner Nähe ist eine Fußgängerampel, einfache Querung ohne 
PKW-Kreuzung.
Der Fußgänger hat dauerhaft rot, auf der Fahrbahn gibt es nur gelb und 
rot.
Bei Anforderung per Taster kommt gelb und kurz drauf rot, etwas 
zeitverzögert Fußgänger grün.
Nach Zeitablauf Fußgänger rot und verzögert auf der Fahrbahn aus.

Ganz wichtig sind "Toleranz-Ampeln" in zwei Nachbarstädten, eine 
Regionalzeitung hat sie anders benannt. Die Cannabis-Ampeln sind nicht 
offiziell, die haben ein paar Piraten überklebt und wurden zügig 
entfernt.

[Roland E. (roland0815)]

Lustige Ampeln gibts inzwischen einige. In Wernigerode Hexen und Teufel, 
in Marburg Märchenfiguren. In Leipzig Ampelfrauchen mit Zöpfchen und 
Röckchen...

In Frederica historische Wachsoldaten...

Ist nett und steigert die Akzeptanz.

Ne Ampel ist ja eigentlich nur eine Reihe von Bitmustern, welche nach 
Zeit und/oder Ereignis durchgeschoben werden...

[Marcel V. (mavin)]

Roland E. schrieb:
> In Leipzig Ampelfrauchen mit Zöpfchen und Röckchen...

...und in Ostfriesland den hüpfenden Otti, mit seinem Ottifant.

[Frank E. (Firma: Q3) (qualidat)]

Andreas S. schrieb:
> Frank E. schrieb:
>> ggf. sogar auf
>> externem Datenträger (SD-Karte), so dass man jederzeit ohne
>> Neuprogrammierung das Verhalten anpassen kann.
>
> Solch ein Dateisystem in einer (V)HDL-Beschreibung zu realisieren,
> dürfte den Aufwand unglaublich in die Höhe treiben. Das mag zwar in der
> Simulation funktionieren, bei der einem auch Dateioperationen zur
> Verfügung stehen, nicht jedoch bei der Synthese für ein FPGA o.ä..

Gibts doch bestimmt längst als fertiges Modul/Lib? Man muss ja nich 
tjedes Fahrrad neu erfinden, oder?

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Frank E. schrieb:
> Gibts doch bestimmt längst als fertiges Modul/Lib? Man muss ja nich
> tjedes Fahrrad neu erfinden, oder?

Ja, so etwas gibt es schon, z.B. auch im Rahmen des MiST-FPGA-Projektes. 
Das ist aber kein Anfängerkram, der mal schnell von jemandem, der schon 
Probleme mit einer banalen Ampelsteuerung hat, an die eigene Hardware 
bzw. das eigene Projekt angepasst werden kann. Es ist eben nicht damit 
getan, wie in der Softwarewelt üblich, einfach irgendwo eine open()- und 
eine read()-Funktion aufzurufen und der Drops ist gelutscht.

Für solche Dateioperationen wäre vermutlich eher ein Softcore geeignet, 
der einen (V)HDL-Funktionsblock für den SD-Kartenzugriff ansteuert. Das 
Dateisystem wird dann "wie üblich" in Software realisiert. Und natürlich 
bräuchte der Softcore noch eine Möglichkeit, die gelesene Konfiguration 
dann in die eigentliche Ampelsteuerung zu laden. Das wäre natürlich zu 
Lerntzwecken durchaus interessant, aber ansonsten so ziemlich das 
unsinnigste Projekt.

[Rolf S. (audiorolf)]

Andreas S. schrieb:
> (V)HDL-Funktionsblock für den SD-Kartenzugriff ansteuert.

und der ist auch nicht so ganz trivial. Da muss man gut simulieren oder 
man schreibt sich beim tatsächlichen Testen einen Haufen SD-Karten 
kaputt.

[Markus F. (mfro)]

Eine SD-Karte, um ein FPGA-Design zu konfigurieren?
Da haut wieder jemand mit dem Hammer Schrauben in die Wand ;)

Wenn's denn unbedingt konfigurierbar sein muss, nimmt man ein FPGA, das 
partial reconfiguration unterstützt und lädt so andere Konfigurationen.

Das wäre wenigstens "artgerechte Haltung".

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Markus F. schrieb:
> Eine SD-Karte, um ein FPGA-Design zu konfigurieren?
> Da haut wieder jemand mit dem Hammer Schrauben in die Wand ;)

Ja, das ist definitiv eine völlig unsinnige Anforderung bzw. 
Lösungsvorschlag.

> Wenn's denn unbedingt konfigurierbar sein muss, nimmt man ein FPGA, das
> partial reconfiguration unterstützt und lädt so andere Konfigurationen.

Das wäre noch unsinniger, denn dann müsste ja die neue 
Ampelkonfiguration erst synthetisiert werden.

> Das wäre wenigstens "artgerechte Haltung".

Naja...

[Markus F. (mfro)]

Andreas S. schrieb:
> Das wäre noch unsinniger, denn dann müsste ja die neue
> Ampelkonfiguration erst synthetisiert werden.

ein geändertes .mif-File kriegt man auch ohne erneute Synthese in den 
Bitstream (gut, der Assembler muss noch drüberlaufen).

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Markus F. schrieb:
> (gut, der Assembler muss noch drüberlaufen).

Das ist ein riesiger Unterschied. WENN es sich um ein reales Produkt 
handeln würde, wäre es für einen Wartungstechniker, der 
Konfigurationsänderungen an einer Ampelanlage durchführt, kaum 
praktikabel, eine passende FPGA-Toolchain mitzuführen. Das ganze wäre 
viel zu aufwändig und fehlerträchtig, abgesehen von der Lizenzthematik. 
Und der Techniker bekäme dann bei einem Tippfehler eine (aus seiner 
Sicht) völlig obskure Fehlermeldung der Toolchain um die Ohren gehauen. 
Das wäre völlig unpraktikabel. Natürlich könnte man die Aufrufe hinter 
einem eigenen GUI verstecken.

Eine einfache Konfigurationsdatei lässt sich aber mit einem einfachen 
Editor bearbeiten und dann einfach auf die SD-Karte kopieren. Oder auch 
direkt auf der SD-Karte bearbeiten.

Ob SD-Karten mit den üblichen Steckkontakten wirklich für 
Ampelsteuerungen mit riesigem Temperaturbereich und Kondenswasserbildung 
geeignet wären, steht aber auch auf einem anderen Blatt.

Insgesamt würde man aber ohnehin wohl kaum ein FPGA für solch eine 
Steuerung einsetzen, sondern irgendeinen schwachbrüstigen 
Mikrocontroller, der sich aber trotzdem noch ziemlich langweilen dürfte. 
Vermutlich werden auch heute noch Tausende an Ampeln auf Basis eines 
Intel 4004 laufen. Das war nämlich damals eine der 
"Killerapplikationen", in denen der 4004 lange Zeit verbaut wurde.

[Markus F. (mfro)]

Zumindest darüber, daß eine Ampelsteuerung kein Job für ein FPGA ist, 
sind wir uns ja einig.

Einen SD-Karten-Treiber im FPGA - ohne Mikroprozessor-Unterstützung - zu 
implementieren ist aber m.E. ebenso Quatsch (abgesehen davon, daß der 
städtische Büttel sicherlich nicht mit einem Stapel SD-Karten durch die 
Stadt pilgert und die in die Ampel schiebt).

Ampelsteuerungen werden normalerweise ferngesteuert.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Markus F. schrieb:
> Ampelsteuerungen werden normalerweise ferngesteuert.

Aber würde man wirklich die Ampelschaltung ändern, ohne dass ein 
Techniker vor Ort anwesend wäre?

Und bei Funklöchern sieht es mit der Fernkonfiguration auch etwas 
schwierig aus, siehe z.B.:

https://www.telstra.com.au/coverage-networks/our-coverage

[Peter D. (peda)]

Bei mir in der Straße ist eine sehr merkwürdige Fußgängerampel.
Ist sie schon länger rot und man drückt den Knopf, dauert es ewig, ehe 
sie grün wird.
Ist sie aber gerade auf rot gesprungen und man drückt den Knopf, geht 
sie fast sofort wieder auf grün.
Vermutlich geht der µC in Power-down und beim Drücken muß er dann 
erstmal neu booten.

[Roland E. (roland0815)]

Peter D. schrieb:
> Bei mir in der Straße ist eine sehr merkwürdige Fußgängerampel.
> Ist sie schon länger rot und man drückt den Knopf, dauert es ewig, ehe
> sie grün wird.
> Ist sie aber gerade auf rot gesprungen und man drückt den Knopf, geht
> sie fast sofort wieder auf grün.
> Vermutlich geht der µC in Power-down und beim Drücken muß er dann
> erstmal neu booten.

Ist wohl ein subjektives Phänomen. Ampeln mit Wunschtaste schalten die 
Phasen trotzdem reihum normal durch, lassen die Fußgängerampel halt rot 
wenn nicht gedrückt, damit die Rechtsabbieger nicht irritiert werden.

Ist der Zeitpunkt, bis zu dem der Wunsch ausgewertet und umgesetzt 
werden kann schon durch, wartet man eine komplette Runde. Wenn das blöd 
gesetzt ist, kommen solche komischen Effekte zustande.

Die einzigen, die die Reihenfolge ändern bzw das Programm zurücksetzen 
sind Busse und Straßenbahnen wenn vorgesehen. Die lösen eine Abkürzung 
im Programm aus um schnell grün zu bekommen. Dann läuft das Programm von 
der Stelle an weiter.
Als Fußgänger kann man an solchen Ampeln zu ungünstigen Zeiten ne 
viertel Stunde stehen...