Schieberegister PISO Probleme mit der Ausgabe

[Vicky M. (vicky_m)]

Hi,

da ich noch Anfängerin bin und mich Schritt für Schritt durch den VHDL 
Jungle kämpfe, bin ich nun am Schieberegister angelangt. Ich habe mir 
vorgenommen ein Schieberegister aufzubauen welches parallel zwei 8Bit 
Zeichen einliest und anschließend diese Seriell ausgibt. Später will ich 
diese 8 Bit Zeichen an meinem Nexys Board einlesen welche dann von 
meinem µC kommen. Deshalb habe ich wie @Lothar Miller es beschrieben hat 
den Enable und und Reset einsynchronisiert. Theoretisch müsste ich Load0 
und Load1 auch einsynchronisieren, oder?

Das Einsynchroniseren habe ich versucht wie beschrieben umzusetzten, 
weis aber nicht ob das so komplett passt wie ich das aufgefasst und 
umgesetzt habe. Der Reset muss laut Ihm auch auf jedenfall 
einsynchronisiert werden da dieser von einem Taster kommt und daher 
komplett asynchron wäre.

Nun gut, es funktioniert auch eigentlich alles auch so halbwegs. 
Probleme sind das mein Schieberegister die Werte einliest, aber diese 
nicht ausgibt. Was habe ich falsch verstanden? Habe ein Bild von meiner 
Simulation angehangen.

Auch habe ich bei meinen eingelesen werten einen Taktversatz. Ich lese 
doch parallel ein, warum ist da ein Versatz drinnen?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity tutorial is
          
    Port(
          clk         :   IN  STD_LOGIC;
          enable      :   IN  STD_LOGIC;
          reset      :   IN  STD_LOGIC;
          y           :   OUT STD_LOGIC
           );

end tutorial;

architecture Behavioral of tutorial is

    constant load0    : STD_LOGIC_VECTOR(7 downto 0) := "10101010";
    constant load1    : STD_LOGIC_VECTOR(7 downto 0) := "11001100";
    signal sr         : STD_LOGIC_VECTOR (7 downto 0) := (others=>'0');
    signal resetsr    : STD_LOGIC_VECTOR (1 downto 0);
    signal enablesync : std_logic := '0';
    
    
begin

    process
        begin                                         -- Einsynchronisieren der externen Inputs
            wait until rising_edge(clk);
               enablesync <= enable;
               resetsr <= resetsr(0) & reset;
     end process;
             
         process(clk)                                  -- Schieberegister
         begin
            if (enablesync = '1') and (resetsr(0) = '0') then
                sr <= load0;
            elsif (enablesync = '0') and (resetsr(0) = '0') then
                sr <= load1; 
            elsif (resetsr(0) = '1') then
                sr <= "00000000";
            elsif rising_edge(clk) then
                sr <= sr (6 downto 0) & '0';     
             end if;
         end process;
          
    y <= sr(0);      

end Behavioral;

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity testbench is
end testbench;

architecture Behavioral of testbench is

COMPONENT tutorial is
    Port( 
         clk         :   IN  STD_LOGIC;
         enable      :   IN  STD_LOGIC;
         reset       :   IN  STD_LOGIC;
         y           :   OUT STD_LOGIC
        ); 
        
end COMPONENT;

    signal clk       :   STD_LOGIC := '0';
    signal enable    :   STD_LOGIC := '1';
    signal reset     :   STD_LOGIC := '0';
    signal y         :   STD_LOGIC := '0';
  
begin
    aand : tutorial PORT MAP(
         clk        =>  clk,
         y          =>  y,
         reset      =>  reset,
         enable     =>  enable
         );

    clk        <=  not clk after 5 ns;
    enable     <=  not enable after 40ns;
    reset      <=  not enable after 120ns;
   

end Behavioral;

Zusatz: Die Zeiten in der Testbench sind von mir frei ausgedacht. Aber 
eigentlich sollten diese passen, oder?

Aller beste Grüße
Vicky

[Vicky M. (vicky_m)]

Also es ist schon dubios. Ich bekomme keine Error List aber Warnings und 
diese versteh ich nicht:

[Synth 8-3332] Sequential element (enablesync_reg) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (resetsr_reg[0]) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (sr_reg[7]) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (sr_reg[6]) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (sr_reg[5]) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (sr_reg[4]) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (sr_reg[3]) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (sr_reg[2]) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (sr_reg[1]) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (sr_reg[0]) is unused and will be removed from module tutorial.
[Synth 8-3332] Sequential element (y_reg) is unused and will be removed from module tutorial.

Warum sind die alle unbenutzt? Ich lade diese Register doch und gebe 
diese auf Y was mein Output ist.

[Bernhard K. (bkom)]

Vicky M. schrieb:
> (...)
> process(clk)                                  -- Schieberegister
>          begin
     viel zu viel asyncrones
>             if (enablesync = '1') and (resetsr(0) = '0') then
>                 sr <= load0;
>             elsif (enablesync = '0') and (resetsr(0) = '0') then
>                 sr <= load1;
>             elsif (resetsr(0) = '1') then
>                 sr <= "00000000";
>             elsif rising_edge(clk) then
>                 sr <= sr (6 downto 0) & '0';
>              end if;
>          end process;

Probier es erstmals so:

process(clk)
      if rising_edge(clk) then
             if (enablesync = '1') and (resetsr(0) = '0') then
                 sr <= load0;
             elsif (enablesync = '0') and (resetsr(0) = '0') then
                 sr <= load1;
             elsif (resetsr(0) = '1') then
                 sr <= "00000000";
             else
                 sr <= sr (6 downto 0) & '0';
              end if;
         end if
     end process;

AAAAber: >sr <= sr (6 downto 0) & '0';< kann rein logisch nie erreicht 
werden!

> Theoretisch müsste ich Load0 und Load1 auch einsynchronisieren, oder?
Nein, da die zwei intern und konstant sind.

[Vicky M. (vicky_m)]

Erst einmal vielen Dank dir. Aber leider bleibt mein y Ausgang immer 
noch auf Null.

Bernhard K. schrieb:
> AAAAber: >sr <= sr (6 downto 0) & '0';< kann rein logisch nie erreicht
> werden!

Das verstehe ich nicht ganz was du damit meinst?

[Bernhard K. (bkom)]

mach einfach eine Tabelle:
wenn     enablesync und resetsr(0)   dann macht dein VHDL-code
             1             0           sr <= load0
             0             0           sr <= load1;
             - (=egal)     1           sr <= "00000000";

Mit welchen Logikwerten kommt man nun
zu "sr <= sr (6 downto 0) & '0'" ??

Evtl mit einem zusätzlichen Steuersignal:

process(clk)
      if rising_edge(clk) then
             if (enable_load0_sync = '1') and (resetsr(0) = '0') then
                 sr <= load0;
             elsif (enable_load1_sync = '0') and (resetsr(0) = '0') then
                 sr <= load1;
             elsif (resetsr(0) = '1') then
                 sr <= "00000000";
             else
                 sr <= sr (6 downto 0) & '0';
              end if;
         end if
     end process;

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

Wozu hat reset_sr eigentlich 2 Bits, wenn das zweite davon niemals 
benutzt wird?

Vicky M. schrieb:
> deshalb habe ich wie @Lothar Miller es beschrieben hat den Enable und und
> Reset einsynchronisiert.
Das solltest du dir nochmal genauer ansehen und vor allem: versuchen zu 
verstehen, warum da 2 Flipflops hintereinander kommen sollten...

> Der Reset muss laut Ihm auch auf jedenfall einsynchronisiert werden da
> dieser von einem Taster kommt und daher komplett asynchron wäre.
Meine Worte sind: ein Reset ist unnötig, weil im echten Leben ein 
Resettaster niemals gedrückt wird. Nur vermurkste Designs und Anfänger 
brauchen sowas.

BTW: deine Simulation ist FALSCH, weil die Sensitivliste nicht 
komplett ist. Da fehlen enablesync und reset_sr. Deshalb ist der 
Screenshot auch teilweise so schön synchron zum fallenden(!!) 
Taktflanke, obwohl die Signale asynchron sind...

[Vicky M. (vicky_m)]

Bernhard K. schrieb:
> mach einfach eine Tabelle:
> wenn     enablesync und resetsr(0)   dann macht dein VHDL-code
>              1             0           sr <= load0
>              0             0           sr <= load1;
>              - (=egal)     1           sr <= "00000000";
>
> Mit welchen Logikwerten kommt man nun
> zu "sr <= sr (6 downto 0) & '0'" ??
>
> Evtl mit einem zusätzlichen Steuersignal:
>

> process(clk)
>       if rising_edge(clk) then
>              if (enable_load0_sync = '1') and (resetsr(0) = '0') then
>                  sr <= load0;
>              elsif (enable_load1_sync = '0') and (resetsr(0) = '0') then
>                  sr <= load1;
>              elsif (resetsr(0) = '1') then
>                  sr <= "00000000";
>              else
>                  sr <= sr (6 downto 0) & '0';
>               end if;
>          end if
>      end process;
>

Ok, ich hoffe ich habe es verstanden. Ich glaube du möchtest mir damit 
sagen das ich immer in den ersten drei if hängenbleibe und nie in die 
else Bedingung komme. Somit wird nie der Befehl

sr <= sr (6 downto 0) & '0‘;

ausgeführt. Somit müsste das letzte else eigentlich ein elsif mit 
Bedingung sein damit ich da rein komme.

Jo da stehe ich dann aber vor dem Problem was für eine Bedingung das 
sein soll. Theoretisch ein writeout. Theoretisch könnte ich es auch 
Taktgesteuert herausführen und aus der elsif herausnehmen sobal das 
Schieberegister geladen ist?

           
         process(clk, enablesync, resetsr)                                -- Schieberegister
         begin
          if rising_edge(clk) then
                if (enablesync = '1') and (resetsr(0) = '0') then
                    sr <= load0;
                    writeout <= '1';
                elsif (enablesync = '0') and (resetsr(0) = '0') then
                    sr <= load1; 
                    writeout <= '1';
                elsif (resetsr(0) = '1') then
                    sr <= "00000000";
                    writeout <= '1';
                elsif (writeout = '1') then
                    sr <= sr (6 downto 0) & '0';  
                    writeout <= '0';  
                 end if;
            end if;     
         end process;  
          
      y <= sr(0);  

end Behavioral;

Nachtrag: Dieser Versuch führte auch nicht zum gewünschten Ziel. Ich 
habe es wohl doch falsch verstanden.

Lothar M. schrieb:
> Wozu hat reset_sr eigentlich 2 Bits, wenn das zweite davon niemals
> benutzt wird?

Da muss ich ehrlich zugeben das ich es nicht vollständig verstanden 
habe. Ich habe mich auch gewundert. Damit ich keine Fehler mehr bekommen 
habe habe ich dann ein Bit ausgewählt.

Lothar M. schrieb:
> BTW: deine Simulation ist FALSCH, weil die Sensitivliste nicht
> komplett ist. Da fehlen enablesync und reset_sr. Deshalb ist der
> Screenshot auch teilweise so schön synchron zum fallenden(!!)
> Taktflanke, obwohl die Signale asynchron sind...

Habe die Sensitivliste vervollständigt.

Des Weiteren meinst du ich sollte den Reset heraus nehmen. Ich wusste 
nicht das dieser besser weggelassen wird. Ich dachte das wenn mal ein 
Fehler auftaucht das ein Reset gedrückt werden kann :D .

[Bernhard K. (bkom)]

Vicky M. schrieb:
> (...)
>Ich habe es wohl doch falsch verstanden.
ja, dennwie soll "sr <= sr (6 downto 0) & '0';" erreicht werden, ohne 
neues Signal in den ersten if-abfragen ?

Ich meine etwa so:

 process(clk)
                                -- Schieberegister
  begin
     if rising_edge(clk) then       --      -----> hier das neue Signal
       if (enablesync = '1') and (resetsr(0) = '0') and (writeout='0') then
              sr <= load0;

    --- und so weiter und so fort ...

               elsif (writeout = '1') then
                    sr <= sr (6 downto 0) & '0';  
                 end if;
            end if;     
         end process;

Und lass den reset einfach erstmal drin, wenn dann das Beispiel geht
könntest du bei FPGAs den reset auch rauslassen, mach aber erst mal 
den ersten Schritt mit reset!

[Vicky M. (vicky_m)]

Also so sehr ich es auch versuche und weitere Variablen einführe usw. 
will der Ausgang einfach nichts ausgeben. So langsam glaube ich der 
Hunde liegt noch wo anders begraben.

    process(clk, enablesync, resetsr)                                  -- Schieberegister
         begin
          if rising_edge(clk) then
                if (enablesync = '1') and (resetsr(0) = '0') and (writeout='0') then
                    sr <= load0;
                elsif (enablesync = '0') and (resetsr(0) = '0') and (writeout='0') then
                    sr <= load1; 
                elsif (resetsr(0) = '1') and (writeout='0')then
                    sr <= "00000000";
                elsif (writeout = '1') then
                    sr <= sr (6 downto 0) & '0';  
                 end if;
            end if;     
         end process;
 
      y <= sr(0);

Ich habe auch diesen Betrag von Lothar Miller gefunden.
https://embdev.net/topic/348169
Ganz am Anfang meines Post habe ich es doch so ähnlich gemacht.

[Vicky M. (vicky_m)]

Sodelle ich habe nun nochmals alles aufgeräumt und getestet. Ich habe 
ein Timingproblem! In meiner Testbench habe ich meine Zeiten und Enables 
usw. nicht im Griff. Deshalb kommt beim Seriellen Ausgang nur Müll raus.

Wie gehe ich da am besten vor?

Ich habe 8Bit die Parallel zu Seriell gewandelt werden. das bedeutet, 8* 
CLK ist die Zeit die das Schieberegister benötigt die Bits auszugeben 
bevor neue hinein geladen werden dürfen. Stimmt das?

Jetzt muss ich schauen wie ich meine loadenable und shift richtig setze 
damit es funktioniert. Aus Einfachheitsgründen habe ich den Reset mal 
weggelassen.



Programm:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity tutorial is

    Port(
      clk           : IN  std_logic;
      enable        : IN  std_logic;
      shift_i       : IN  std_logic;
      ser_out       : OUT std_logic;
      loadenable    : IN  std_logic
       );

end tutorial;

architecture Behavioral of tutorial is

    constant load0        : STD_LOGIC_VECTOR (7 downto 0) := "10101010";
    constant load1        : STD_LOGIC_VECTOR (7 downto 0) := "11001100";
    signal sr             : STD_LOGIC_VECTOR (7 downto 0);
    
    begin                           -- Schieftregister

         process(clk)
             begin
                  if rising_edge(clk) then
                     if enable = '1' and loadenable = '1' then
                         sr <= load0;
                     elsif enable = '1' and loadenable = '0' then
                         sr <= load1;
                     elsif shift_i = '1' then
                         sr <= '0' & sr(7 downto 1);  
                     end if;
                  end if;
          end process;
          
        ser_out  <= sr(0);                                       

end Behavioral;

Testbench

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity testbench is
end testbench;

architecture Behavioral of testbench is

COMPONENT tutorial is

    Port( 
         clk        :   IN  STD_LOGIC;
         enable     :   IN  STD_LOGIC;
         shift_i    :   IN  STD_LOGIC;
         ser_out    :   OUT STD_LOGIC;
         loadenable :   IN  std_logic
        ); 
        
end COMPONENT;

    signal clk         :   STD_LOGIC := '0';
    signal enable      :   STD_LOGIC := '0';
    signal shift_i     :   STD_LOGIC := '0';
    signal ser_out     :   STD_LOGIC := '0';
    signal loadenable  :   STD_LOGIC := '0';

  
begin
    aand : tutorial PORT MAP(
         clk       =>  clk,
         ser_out   =>  ser_out,
         shift_i   =>  shift_i,
         enable    =>  enable,
         loadenable    =>  loadenable
         );

    clk        <=  not clk after 5 ns;
    loadenable <=  not loadenable after 45 ns;
    enable     <=    '1' after  45ns,
                     '0' after  50ns,
                     '1' after  95ns,
                     '0' after  100ns;
    shift_i    <=  not shift_i after 5 ns;
--                   '0' after  50ns,
--                   '1' after  55ns;

end Behavioral;

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

Vicky M. schrieb:
> 8* CLK ist die Zeit die das Schieberegister benötigt die Bits
> auszugeben bevor neue hinein geladen werden dürfen. Stimmt das?
Und zudem brauchst du noch mindestens 1 Taktzyklus zur Übernahme des 
nächsten Datenworts.

BTW: das was du da machst wird bei SPI im Grunde auch gemacht...

Vicky M. schrieb:
> Programm:
Dir sollte klar werden, dass du da nicht programmierst, denn sonst hieße 
es ja VHPL.

Vicky M. schrieb:
> In meiner Testbench habe ich meine Zeiten und Enables usw. nicht im
> Griff. Deshalb kommt beim Seriellen Ausgang nur Müll raus.
> Wie gehe ich da am besten vor?
Was macht nun diese Beschreibung mit dieser Testbench? Woher kommen im 
"echten Leben" diese Signale? Wie sieht dort das zeitliche Verhalten 
aus? Denn im besten Fall ist die Testbench eine Nachbildung der 
Realität...

[Vicky M. (vicky_m)]

Lothar M. schrieb:
> Vicky M. schrieb:
>> 8* CLK ist die Zeit die das Schieberegister benötigt die Bits
>> auszugeben bevor neue hinein geladen werden dürfen. Stimmt das?
> Und zudem brauchst du noch mindestens 1 Taktzyklus zur Übernahme des
> nächsten Datenworts.

Wenn ich dann aber meine parallel eingeschobene Bits seriell ausgeben 
möchte, habe ich dann immer einen Takt Versatz von load0 zu load1. Das 
macht mir ja meine serielle Bitkette kaputt?

> Vicky M. schrieb:
>> In meiner Testbench habe ich meine Zeiten und Enables usw. nicht im
>> Griff. Deshalb kommt beim Seriellen Ausgang nur Müll raus.
>> Wie gehe ich da am besten vor?
> Was macht nun diese Beschreibung mit dieser Testbench? Woher kommen im
> "echten Leben" diese Signale? Wie sieht dort das zeitliche Verhalten
> aus? Denn im besten Fall ist die Testbench eine Nachbildung der
> Realität...

Projekt 1.)

Wie oben beschrieben ist es ein Eigenprojekt die ich mir ausgedacht habe 
um ein besseres Verständnis für alles zu bekommen. Load0 und Load1 sind 
noch Konstanten, welche ich aber später mit einem STM Board zu meinem 
FPGA sende. Dort will ich diese einlesen und anschließend Parallel 
Seriell Wandeln um eine schöne Bitkette zu bekommen.

Projekt 2.)

STM Board sendet die serielle Bitkette zum FPGA und soll diese Parallel 
Wandeln um wieder Load0 und Load1 zu erkennen. Theoretisch versuche ich 
eine sehr einfache Übertragung aufzubauen. Theoretisch das oben 
rückwärts.


Aber zu aller erst muss es in der Simulation mit festen Werten 
funktionieren, anschließend schau ich weiter wie es mit den externen 
Signalen funktioniert. Somit muss ich mir jetzt eine Frequenz aussuchen 
wo mit die 8Bit+ Taktversatz rein passt damit mein Ausgangssignal 
vollständig abgebildet wird.

100MHz ist vom Nexys der Grundtakt. Das bedeutet ja das 10ns eine 
Periode vom Takt ist. Dann brauche ich 90ns (8Bit+ Taktversatz) für 
meine Bitkette (z.b. load0) aber nur beim ersten mal, oder? Wie verhält 
sich es mit dem Taktversatz beim Wechsel von load0 zu load1?

Sollte ich andere, tiefere Frequenzen wählen? Theoretisch kann ich diese 
ja später immer noch mit einem Zähler langsamer machen, oder? Wie macht 
man das in der Paxis?

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

Vicky M. schrieb:
> Wenn ich dann aber meine parallel eingeschobene Bits seriell ausgeben
> möchte, habe ich dann immer einen Takt Versatz von load0 zu load1. Das
> macht mir ja meine serielle Bitkette kaputt?
Ja nun, wenn du alle 8 Bits ein neues Wort einlesen und nahtlos 
ausgeben willst, dann musst du da ein wenig mehr Gehirnschmalz 
reinstekcne und praktisch schon am vorhergehenden Takt alles für Laden 
vorbereiten. Es ist dann ja nichts zufällig, sondern es muss einfach 
einen Takt früher passieren...

> Load0 und Load1 sind noch Konstanten, welche ich aber später mit einem
> STM Board zu meinem FPGA sende. Dort will ich diese einlesen und
> anschließend Parallel Seriell Wandeln um eine schöne Bitkette zu bekommen.
Wenn in deinem Bitstrom ausschließlich Datenbits kommen, wie kann sich 
der Empfänger dann synchronisieren? SPI verwendet zum Synchronisieren 
z.B. den SlaveSelect.

> Sollte ich andere, tiefere Frequenzen wählen?
Du solltest die Frequenz maximal so hoch wählen, dass du deine Daten 
ausreichend schnell übertragen kannst. Wenn du die beiden 8 Bit Worte 
100000 mal pro Sekunde übertragen musst (! Achtung: es zählt nur das, 
was du musst, nicht das, was du willst), dann reichen dir 2 MHz Takt 
locker aus.

> Theoretisch versuche ich eine sehr einfache Übertragung aufzubauen.
Praktisch wirst du sehen, dass dir da der angesprochene 
Synchronisationsmechanismus fehlt. Denn wenn da nur 1 kleine Störung 
auftritt und der Empfänger einen Taktimpuls doppelt oder gar nicht 
erkennt, dann läuft deine gesamte Kommunikation von da an um 1 Bit 
versetzt.

[Vicky M. (vicky_m)]

Lothar M. schrieb:
> Vicky M. schrieb:
>> Wenn ich dann aber meine parallel eingeschobene Bits seriell ausgeben
>> möchte, habe ich dann immer einen Takt Versatz von load0 zu load1. Das
>> macht mir ja meine serielle Bitkette kaputt?
> Ja nun, wenn du alle 8 Bits ein neues Wort einlesen und nahtlos
> ausgeben willst, dann musst du da ein wenig mehr Gehirnschmalz
> reinstekcne und praktisch schon am vorhergehenden Takt alles für Laden
> vorbereiten. Es ist dann ja nichts zufällig, sondern es muss einfach
> einen Takt früher passieren...

Mach ich das mit einem Zähler? Sozusagen alles fängt an mit Zählerstand 
10 außer das Laden das wird schon ab Takt 9 ausgeführt? Also benötigt 
man hierfür zwei Zähler? Oder gibts eine einfachere Lösung?

Lothar M. schrieb:

>> Theoretisch versuche ich eine sehr einfache Übertragung aufzubauen.
> Praktisch wirst du sehen, dass dir da der angesprochene
> Synchronisationsmechanismus fehlt. Denn wenn da nur 1 kleine Störung
> auftritt und der Empfänger einen Taktimpuls doppelt oder gar nicht
> erkennt, dann läuft deine gesamte Kommunikation von da an um 1 Bit
> versetzt.

Also müsste ich ein weiteres load „load2" einführen mit fest definierten 
Datenbits, welche immer an einer gewissen Stelle vorkommen. Und beim 
Empfänger eine Biterkennung aufbauen. Theoretisch ein MUX der immer 
schaltet wenn eine gewisse Folge anliegt.

Ziemlich komplex finde ich gerade. Gibts hier irgendwo ein Beispiel für 
so etwas?

[Gustl B. (-gb-)]

Wieso verwendest Du nichts Fertiges wie UART? Oder zumindest das Konzept 
mit Startbit und Stoppbit ...

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

Vicky M. schrieb:
> Also müsste ich ein weiteres load „load2" einführen mit fest definierten
> Datenbits, welche immer an einer gewissen Stelle vorkommen. Und beim
> Empfänger eine Biterkennung aufbauen. Theoretisch ein MUX der immer
> schaltet wenn eine gewisse Folge anliegt.
Du musst noch weiter denken, denn wenn dieses 
"Synchronisations-Bitmuster" zufällig mal durch andere Daten erzeugt 
wird, dann machst du ebenfalls einen Resync. Denn mal angenommen, dein 
Synchronisationspattern ist 01010101, dann sag mir mal, wo du bei dieser 
Bitfolge neu aufsetzen würdest:

...111001101010101010101010111001101010101010101010111001101010101010101010111001...

Ein Tipp: das sind tatsächlich immer die selben 3 Bytes, die 
nacheinander gesendet werden. Und eines davon ist das "Sync-Byte" 
01010101
Sag mir jetzt, welches die beiden anderen Bytes sind. Ich sage dir dann 
hinterher, welche ich tatsächlich gesendet habe...

Aber wie schon erwähnt: das Rad ist bereits erfunden. Du kannst dir 
einfach mal anschauen, wie andere das machen: RS232, SPI, Microwire, 
usw. usf.

> Mach ich das mit einem Zähler? Sozusagen alles fängt an mit Zählerstand
> 10 außer das Laden das wird schon ab Takt 9 ausgeführt? Also benötigt
> man hierfür zwei Zähler? Oder gibts eine einfachere Lösung?
Ein Zähler reicht aus. Und den nimmst du dann gleich als Basis für einen 
Multiplexer, der diese Bits auf den Ausgang durchschaltet...

[Gustl B. (-gb-)]

Also bei einem Datenstrom übertrage ich viele bytes aber bei jedem byte 
ist das letzte bit reserviert. Ist das das erste byte in einem Paket so 
ist das bit 1 und bei allen weiteren bytes im Paket 0. also kostet zwar 
Datenrate aber funktioniert super.

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

Gustl B. schrieb:
> Ist das das erste byte in einem Paket so ist das bit 1 und bei allen
> weiteren bytes im Paket 0. also kostet zwar Datenrate aber funktioniert
> super.
Es funktioniert aber auch nur dann, wenn du weißt, welches das "erste" 
Bit ist. Du brauchst also noch einen weiteren 
Synchronisationsmechanismus, der anzeigt, wo denn so ein Datenwort 
anfängt.
Bei der RS232 z.B. muss mindestens einmal eine Pause von mindestens 
einem ganzen Byte eingelegt werden, sonst hast du ständig falsch 
empfangene Bytes zusammen mit irgendwelchen Framing- oder 
Parity-Fehlern...

[Gustl B. (-gb-)]

Ach so, ja. Also ich habe das nur um Pakete aus mehreren Byte zu 
erkennen. Übertragen wird das über UART oder parallel FIFO da ist immer 
klar wo ein Byte anfängt und wo es endet.
Also ich verstehe nicht wieso hier nicht auch einfach UART oder so 
genommen wird. Kann man ja schneller laufen lassen als Daten nachkommen 
und hat so eitwas Pausezeiten dazwischen.