VHDL Eingang einen Wert zuweisen

[moppel (Gast)]

Hallo alle zusammen, ich bin gerade dabei VHDl zu erlernen und habe ein 
problem bei dem ihr mir sicher helfen könnt.
im folgenden habe ich einen Uart transmitter der ein 8 bit datenwort als 
eingang bekommt und diesen dann halt sendet.
wenn ich din in der Testbench einen wert zuweise funktioniert das. 
allerdings möchte ich jetzt dass er den wert erst zuweise wenn send=1 
ist.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity Uart_Transmitter is
    Port ( din : in  std_logic_vector (7 downto 0);
           send : in  STD_LOGIC;
           clk : in  STD_LOGIC;
           rst : in  STD_LOGIC;
           txd : out  STD_LOGIC);

end Uart_Transmitter;


architecture Behavioral of Uart_Transmitter is
  
  signal bitcounter : integer:= 0;
  type STATE_T is (Warte, Sende); --Aufzählungstyp
  signal state : STATE_T;        --Zustandssignal
  signal sendeTaster: std_logic := '0';
  
begin



FSM : process (din, send, clk, rst) is
begin
  if rising_edge(clk) then
    if sendeTaster = '0' and send = '1' then -- Taktflanke des Tasters
      din<="11101101";
      state <= Sende;
      bitcounter <= 0;
    end if;
  
    if state = Warte then
      txd <= '1';
    else --Sende
      if bitcounter = 0 then
        txd <= '0'; -- start bit
      elsif bitcounter = 9 then
        txd <= '0'; --stop Bit
        state <= Warte;
      else --Daten senden
        txd <= din(bitcounter - 1);
      end if; --bitCounter
      bitcounter <= bitcounter + 1;
    end if; --Sende
    
    sendeTaster <= send;
  end if; -- clk
  
    if rst = '1' then
      state <= Warte;
      bitcounter <= 0;
    end if; 
  
end process;
  

end architecture;

dafür habe ich jetzt die zeile "din<="11101101";" hinzugefügt sodass der 
wert bei Send=1 zugewiesen wird.


das scheint allerdings falsch zu sein weil ich die Fehlermeldung "Cannot 
update 'in' object din" bekomme.

die Fehlermeldung sagt mir leider überhaupt nichts

[Alexander F. (alexf91)]

Du kannst einem Eingang keinen Wert zuweisen.
Speichere din beim Zustandswechsel von Warte zu Sende in ein eigenes 
Signal und verwende das beim Senden.

Die Überprüfung des send-Eingangs würde ich außerdem nur im Zustand 
"Warte" machen, da es sonst passieren kann, dass ein Sendevorgang 
abgebrochen wird.

  if rising_edge(clk) then  
    if state = Warte then
      if sendeTaster = '0' and send = '1' then -- Taktflanke des Tasters
        din_save <= din;
        state <= Sende;
        bitcounter <= 0;
      end if;
      txd <= '1';
    else --Sende
      if bitcounter = 0 then
        txd <= '0'; -- start bit
      elsif bitcounter = 9 then
        txd <= '0'; --stop Bit
        state <= Warte;
      else --Daten senden
        txd <= din_save(bitcounter - 1);
      end if; --bitCounter
      bitcounter <= bitcounter + 1;
    end if; --Sende
    sendeTaster <= send;
  end if;

Wie erzeugst du den Takt für dieses Modul?
Teilst du den selbst oder verwendest du eine PLL?

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

moppel schrieb:
> FSM : process (din, send, clk, rst)
In dieser Sensitivliste reicht der CLK und der asynchrone RST...

[Fritz J. (fritzjaeger)]

Lothar Miller schrieb:
> moppel schrieb:
>> FSM : process (din, send, clk, rst)
> In dieser Sensitivliste reicht der CLK und der asynchrone RST...

und der asynchrone reset ist nicht sauber beschrieben, richtig ist:

process(clk,arst)
begin
 if arst = '1' then
 ---
 elsif rising_edge(clk) then
--
 end if;
end process;

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

Fritz Jaeger schrieb:
> richtig ist:  ...
Die Synthese erkennt aber auch die hier verwendete etwas eigenartige 
Schreibweise korrekt.

[Fritz J. (fritzjaeger)]

Lothar Miller schrieb:
> Fritz Jaeger schrieb:
>> richtig ist:  ...
> Die Synthese erkennt aber auch die hier verwendete etwas eigenartige
> Schreibweise korrekt.

Aber die Simulation wird die vermeidbare warning bzgl +  und 'X''Z''U'
in einem Operand rauswerfen. Besser die Lehrbuchvariane verwenden das 
ist auch der kleinste gemeinsame Nenner unter den synthesetools.

[daniel__m (Gast)]

Fritz Jaeger schrieb:
> process(clk,arst)
> begin
>  if arst = '1' then
>  ---
>  elsif rising_edge(clk) then
> --
>  end if;
> end process;

Ist zwar nicht Betandteil des Threads aber: Die "Lehrbuchversion" hat 
den Nachteil, dass man im asynchronen Reset alle Register des 
Processes aufführen sollte, damit keine ungewollte Ausnahmebehandung 
statt findet: in diesem Fall für txd und sendeTaste. Oder man trennt 
diese in verschiedenen Prozessen, was meiner Meinung nach aber oft der 
Lesbarkeit schadet.

Der asynchrone Reset nach dem clk Teil hat diesen Nachteil nicht. 
Man kann alle Signale in einem Prozess zusammenhalten, und trotzdem nur 
die relevanten Signale resetten. Kennt jemand Toolchains, welche diese 
Schreibweise nicht korrekt umsetzt?

Und zweitens (hier im Forum verdeutlicht bekommen): einen asynchroner 
Reset sollte nur in absolut begründeten Fällen genutzt werden. 
Stichpunkt: Timing, Glitch, etc. . Solange ein synchroner Reset das 
Problem auch löst -> nutzen.

Grüße

[Olga (Gast)]

daniel__m schrieb:
> Und zweitens (hier im Forum verdeutlicht bekommen): einen asynchroner
> Reset sollte nur in absolut begründeten Fällen genutzt werden.

Dann hast du hier im Forum nicht genau genug gelesen ;-) Ob synchroner 
oder asynchroner Reset hängt in erster Linie von der Zielarchitektur ab. 
Bei den hier verbreiteten Xilinxen stimmt die Aussage, aber die Altera 
Cyclones mögen lieber* einen asynchronen Reset.


*bezogen auf die benötigen Ressourcen zur Umsetzung.

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

Olga schrieb:
> aber die Altera Cyclones mögen lieber* einen asynchronen Reset.
Der an sich aber unbedingt(!) wieder einsynchronisiert werden muss. Denn 
ein "lehrbuchhemäßer" asynchroner Reset, der einfach von einem Pin auf 
die FSM geht, wird bei allen Architekturen zu Problemen führen...

[moppel (Gast)]

Danke für die rege beteiligung, wie alexander es empfohlen hat habe ich 
ein signal erstellt dass ich dann zum senden benutze. In der simulation 
scheint es auch recht gut zu funktionieren. was den reset angeht werde 
ich es mir demnächst noch einmalgenauer anschauen.

mein Projekt besteht jetzt aus einem Uart_transmitter und einem 
clk_divider. beide Module habe ich in der simulation getestet wobei der 
clk_divider von mir auch auf meinem nexys3 ausprobiert wurde.

Im nächsten schritt habe ich versucht beide Komponenten in einer 
Top-Level entity zu verknüpfen aber leider tut sich bei der simulation 
nicht viel.



Im anhang habe ich einmal alle dateien angehängt. Könnt ihr mir sagen wo 
der fehler ist? also laut simulation bekommt mein clk_divider zwar den 
clock, aber er selbst generiert keinen clock was sehr komisch ist weil 
das modul durch eine eigene Testbench simuliert wurde. Ich tippe auf 
eine fehlerhafte Top_level entity aber ich weiss auch nicht wo das 
problem ist.

[moppel (Gast)]

EDIT: fehler gefunden, habe vergessen den reset in der Testbench zu 
setzen

[Alexander F. (alexf91)]

Trotzdem erzeugt man so keinen Takt.
Entweder man verwendet eine PLL oder ein Clock-Enable Signal.

Als Beispiel die Clockdivider-Entity in diesem Beispiel:
http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html

[moppel (Gast)]

Danke alexander, ich werde das ändern. was spricht gegen meine Variante?

[Alexander F. (alexf91)]

Der Unterschied liegt im Routing.
Bei der Variante mit dem Clock-Enable wird der Takt über eigene 
Taktnetze geroutet. Das Synthesetool reduziert dadurch den Skew.

Bei deiner Variante hingegen wird der Takt über "normale" Netze 
geroutet, wodurch sich der Skew vergrößert.

Skew ist der Zeitversatz der gleichen Taktflanke an verschiedenen 
Flipflops.
http://de.wikipedia.org/wiki/Taktversatz

[moppel (Gast)]

kann man das irgendwo nachlesen? Das müsste ja irgendwo in bestimmten 
FPGA design rules festgelegt worden sein oder ähnliches. Also nicht dass 
ich dir nicht glaube, ich möchte mich einfach auf eine vernünftige 
quelle stützen können wenn ich einen bestimmten code vorziehe.

[Alexander F. (alexf91)]

Zu Gated Clocks gibt es z.B. im Xilinx Whitepaper 231 etwas:
http://www.eng.utah.edu/~cs3710/xilinx-docs/wp231.pdf

Von Altera:
http://www.altera.com/literature/hb/qts/qts_qii51006.pdf

Auf Seite 8 unter Divided Clocks:

>To avoid glitches, do not decode the outputs of a counter or a state machine
>to generate clock signals.

[Josef G. (bome)]

Was der TO in der entity clock_divider macht, das ist kein
Gated Clock. Er verwendet für die beiden Takte jeweils den
Ausgang eines einzelnen Flipflops, und der ist glitchfrei.

Einziges Problem: Falls mit dem erzeugten Takt mehrere
Flipflops exakt gleichzeitig geschaltet werden sollen, muss
man dafür sorgen, dass der erzeugte Takt über eine Taktleitung
geroutet wird. Je nach Fan-Out-Belastung des Taktes macht das
die Synthese entweder automatisch, andernfalls muss man die
Aufschaltung auf die Taktleitung explizit angeben.
Dieses Problem besteht aber in gleicher Weise,
wenn der Takt per DCM erzeugt wird.

[Alexander F. (alexf91)]

Ja, stimmt, da lag ich daneben. Glitches treten hier nicht auf.

Zumindest ISE liefert aber unter Umständen die Warnung
> WARNING:Route:455 - CLK Net:xxx may have excessive skew...
wenn man nicht über ein Taktnetz routet.

Es spricht also nichts für die Taktteiler-Variante, oder?

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

Alexander F. schrieb:
> Es spricht also nichts für die Taktteiler-Variante, oder?
Doch: es ist der Toolchain nicht mehr bekannt, welchen Versatz dieser 
"Takt" zur ursprünglichen Taktquelle hat, und so muss diese erzeugte 
Taktdomäne wie eine asynchrone Domäne behandelt werden. Bei Takten, die 
über einen Taktmanager abgeleitet werden ist das nicht der Fall, die 
Toolchain kann die Taktbezüge problemlos berechnen.

[Josef G. (bome)]

Lothar Miller schrieb:
> Bei Takten, die über einen Taktmanager
> abgeleitet werden ist das nicht der Fall, die
> Toolchain kann die Taktbezüge problemlos berechnen.

Im User-Guide des Spartan3 sind keinerlei Informationen
über die Phasenlage eines mittels DCM geteilten Taktes
relativ zum ursprünglichen Takt zu finden.

Verwendet man zum Teilen zB. ein als Ring betriebenes
Schieberegister, dann weiss man wenigstens, dass die
Flanken des abgeleiteten Taktes "ein wenig" hinter
einer Flanke des Ursprungs-Taktes liegen.

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

Josef G. schrieb:
> Im User-Guide des Spartan3 sind keinerlei Informationen
> über die Phasenlage eines mittels DCM geteilten Taktes
> relativ zum ursprünglichen Takt zu finden.
Da solltest du nochmal nachschauen...

Wenn du den abgeleiteten Takt in den Feedback aufnimmst, ist der 
Phasenversatz null.

[moppel (Gast)]

ok ich denke ich bin auf der sicheren seite wenn ich es mit dem CLK 
enable mache oder?

ich habe mein Projekt noch um 2 buttons erweitert die zwar in der 
Simulation funktionieren aber beim generieren des bit files sagt er mir 
dass Top_Level_ButtonA und Top_Level_ButtonB nicht verwendet werden und 
deswegen nicht geroutet werden.

denke ich verwende die buttons falsch aber ich, kann mir da einer 
helfen?

die genauen Fehlermeldungen sind

WARNING:Xst:647 - Input <Top_Level_ButtonA> is never used. This port 
will be preserved and left unconnected if it belongs to a top-level 
block or it belongs to a sub-block and the hierarchy of this sub-block 
is preserved.

und

WARNING:Par:288 - The signal Top_Level_ButtonA_IBUF has no load.  PAR 
will not attempt to route this signal.
WARNING:Par:288 - The signal Top_Level_ButtonB_IBUF has no load.  PAR 
will not attempt to route this signal.
WARNING:Par:283 - There are 2 loadless signals in this design. This 
design will cause Bitgen to issue DRC warnings.


also er sagt mir ja quasi dass meine buttons nicht benutzt werden aber 
ich verwende sie ja im Process

[Alexander F. (alexf91)]

Die Abfrage deiner Taster ist absolut nicht in Ordnung, die sollte so 
aussehen wie die Abfrage von sendeTaster im Uart-Modul. Du beschreibst 
ein Flipflop, das auf 2 verschiedene Takteingänge reagiert und dessen 
Wert zusätzlich noch von dieser Flanke abhängig ist.

Da du doch einige asynchrone Eingänge hast, empfehle ich dir diesen 
Link:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
Mit einem 3-bit Schieberegister hast du die Flankenerkennung auch gleich 
inklusive.

Zusätzlich ist es jetzt an der Zeit, das Design auf die Clock-Enable 
Variante umzuschreiben. Wenn du nämlich jetzt die Flankenabfrage der 
beiden Taster im Toplevel implementierst, würdest du das zu 
Top_level_clk synchrone Signal temp in die Taktdomäne des 9600Hz Taktes 
geben (hier ist temp asynchron).
Mit dem Clock Enable vermeidest du die sinnlose 2. Taktdomäne.

Welche Toolchain verwendest du? Unter Xilinx ISE 14.7 lässt sich das 
nicht synthetisieren:
> ERROR:Xst:827 - "/path/to/design" line 71: Signal temp cannot be
> synthesized, bad synchronous description.

Edit: Seh gerade, dass sich das für FPGAs neuer als das Spartan3E doch 
synthetisieren lässt (auch mit deinen oder ähnlichen Fehlermeldungen).
Sinnvoll ist es aber nicht.

[moppel (Gast)]

alexander Danke für die Hilfe soweit. Also mein clk-divider habe ich 
geändert und auf clken umgestellt und dann zwei Instanzen in der 
Top_Level entity erstellt. ich hoffe das ist soweit richtig.

mit den Buttons habe ich immer noch zu kämpfen. Also das externe signale 
einsynchronisiert werden müssen verstehe ich. Die umsetzung funktioniert 
allerdings nicht bei mir. Ich hab jetzt versucht wenigstens ein Button 
wie beim Uart modul zuverarbeiten aber die warnungen bekomme ich immer 
noch.

ich habe mir das schematic angeguckt und auch direkt gesehen dass die 
buttons komplett unconnected sind


Übrigens habe ich da noch eine Frage: wie überprüfe ich ob und welche 
signale asynchron sind?

[Alexander F. (alexf91)]

Weise temp mal einen Defaultwert zu bzw. ändere die Buttonabfrage zu

if rising_edge(Top_level_clk) then
    if top_level_buttonB = '0' then
        temp <= x"55";
    else
        temp <= x"AA";
    end if;
end if;

Da temp bei dir keinen Defaultwert hat und nur einen Wert zugewiesen 
bekommt, legt das Synthesetool "10111011" als Standardwert fest und kann 
so die gesamte Button-Abfrage wegoptimieren, da diese den Wert nicht 
mehr verändern würde.
Einsynchronisiert hast du die Buttons auch noch nicht vollständig. Als 
Merkregel: jedes asynchrone Signal über 2 Flipflops einsynchronisieren, 
bevor du es vewendest.
Mach es so, wie auf Lothars Seite beschrieben, das ist am einfachsten.

Das mit dem Clock-Enable hast du auch noch nicht richtig:
Uart_modul erhält als Takt Top_level_clk und zusätzlich das Clock-Enable 
Signal.
Der Prozess sieht dann so aus:

if rising_edge(clk) then
    if clockEnable = '1' then
        --Uart Logik
    end if;
end if;

Deine Sensitivity-Listen solltest du überarbeiten, die beinhalten meist 
zu viele Signale. Stört zwar nicht, finde ich aber unsauber.

moppel schrieb:
> Übrigens habe ich da noch eine Frage: wie überprüfe ich ob und welche
> signale asynchron sind?
Das kannst du nicht überprüfen, das kommt auf deine 
Schaltung/Beschreibung an. Für den Anfang kannst du jedes Signal, das 
von außen kommt, als asynchron betrachten (also Taster, Uart...).
Im FPGA selbst wird es etwas komplizierter. Solange du nur einen Takt 
verwendest kann dir das aber egal sein.

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

moppel schrieb:
> ok ich denke ich bin auf der sicheren seite wenn ich es mit dem CLK
> enable mache oder?
Ja, aber warum machst du es dann nicht? Das was du da hast sind eben 
gerade keine Clock Enable, sondern "derivated clocks", die gern zu 
seltsamen Problemen führen...

Alexander F. schrieb:
> Deine Sensitivity-Listen solltest du überarbeiten, die beinhalten meist
> zu viele Signale. Stört zwar nicht, finde ich aber unsauber.
Die kann man ruhig so lassen, dann sieht man gleich, dass in diesem 
Anfängercode sicher noch andere Überraschungen stecken... ;-)

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

moppel schrieb:
> ok ich denke ich bin auf der sicheren seite wenn ich es mit dem CLK
> enable mache oder?
Ja, aber warum machst du es dann nicht? Das was du da hast sind eben 
gerade keine Clock Enable, sondern "derivated clocks", die gern zu 
seltsamen Problemen führen...

Beim Clock Enable wird ein Signal nur einen einzigen Taktzyklus lang 
aktiviert. Nicht wie bei dir halb/halb. Also ist z.B. für die 
Baudratenerzeugung ausgehend von einem 50MHz Takt mir 20ns Zykluszeit 
das Enable 20ns High, dann 103980ns low, dann wieder 20ns High, dann 
103980ns low, usw...

Sieh dir einfach mal das Lauflicht dort an:
http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html


Alexander F. schrieb:
> Deine Sensitivity-Listen solltest du überarbeiten, die beinhalten meist
> zu viele Signale. Stört zwar nicht, finde ich aber unsauber.
Die kann man ruhig so lassen, dann sieht man gleich, dass in diesem 
Anfängercode sicher noch andere Überraschungen stecken... ;-)

[Alexander F. (alexf91)]

Lothar Miller schrieb:
> Beim Clock Enable wird ein Signal nur einen einzigen Taktzyklus lang
> aktiviert. Nicht wie bei dir halb/halb.

Das mit dem halb/halb hat er schon behoben, jetzt muss es nur noch 
richtig verdrahtet werden.
Aktuell geht das Clock-Enable Signal nämlich auf den Takteingang.

[moppel (Gast)]

So, habe jetzt die Punkte überarbeitet. muss zugeben ich hatte eine 
falsche vorstellung von dem clk_divider, aber hoffe jetzt habe ich es 
endgültig begriffen.
Also alle module werden eigentlich vom master clock betrieben. mein Uart 
modul bekommt dann noch in einer frequenz von 9600hz ein enable signal.
Meine sensitiy list habe ich auf das clk und rst reduziert.

Bei der einsynchronisation sollte dieses mal auch richtig gemacht haben

[moppel (Gast)]

EDIT: Merke grad dass es von der Baudrate gar nicht passt

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

moppel schrieb:
> EDIT: Merke grad dass es von der Baudrate gar nicht passt
Das kann man den Synthesizer ausrechnen lassen...

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

> txd<= Send_puffer(bitcounter -1);
Die Mulitplexer-Lösung ist auf FPGAs ineffizienter als die 
Schieberegister-Lösung...

[Peter B. (funkheld)]

Sag mal moppel, hast du eigentlich schon mal mit einer seriellen 
Schnittstelle auf einem Atmega oder Pic gespielt in "C"?

Dein ganzes Konstrukt mit Button usw wird so nicht fehlerfrei 
funktionieren beim Senden und Empfangen , wenn es überhaupt 
funktioniert. Du hast dich verlaufen. Und zum ausrechnen der Baudrate 
brauchst du keinen Synthesizer sondern nur einen klaren Sachverstand.

Gruss

[Moppel (Gast)]

Hallo Peter, ja habe ich schon. Wo liegt deiner Meinung nach das Problem 
mit den Buttons? Also ich habe jetzt vorerst einen Button implementiert 
und soweit tut es was es soll. Klar, die Taster müssten eigentlich auch 
nocj entstellt werden, aber die verschwinden sowieso. Das mit den 
Tastern ist erstmal dazu da dass ich in vhdl reinkomme

Im nächsten Schritt soll ein SPi Master implementiert werden mit dem ich 
dann einen Adc auslese. Das uart Modul habe ich gemacht um mir die Werte 
später auf dem Rechner anzeigen zu lassen.

[Moppel (Gast)]

Entprellt müssen die Taster natürlich werden, nicht entstellt:-P
Doofes autokorrekt ...

[Alexander F. (alexf91)]

Moppel schrieb:
> Im nächsten Schritt soll ein SPi Master implementiert werden mit dem ich
> dann einen Adc auslese.

Nicht so schnell!
Beim Uart Modul gibt es noch ein paar Kleinigkeiten, die geändert werden 
sollten.
Problematisch ist, dass du den send-Eingang ebenfalls mit der Baudrate 
abfragst und nicht mit der vollen Taktfrequenz. Bei einem Taster ist das 
noch egal, wenn du den aber eliminierst, wird es problematisch.
Du müsstest jetzt dein Clock-Enable Modul ins Uart Modul integrieren und 
den Prescaler erst starten, wenn der Eingang auf high geht. Nur so 
kannst du garantieren, dass auch bei einem High Puls, der nur einen 
Taktzyklus dauert, sendest.

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

Moppel schrieb:
> Hallo Peter, ja habe ich schon. Wo liegt deiner Meinung nach das Problem
> mit den Buttons?
Nicht jeder, der laut tönt, ist einer, der es sollte...
Glaub mir: Peter hat (falls überhaupt) nur einen unbedeutenden 
Wissensvorsprung vor dir.

Moppel schrieb:
> Im nächsten Schritt soll ein SPi Master implementiert werden mit dem ich
> dann einen Adc auslese.
Als kleiner Denkanstoss:
http://www.lothar-miller.de/s9y/categories/45-SPI-Master

Dort finden sich nach kurzer Suche auch zwei Ansätze für RS232 
Schnittstellen. Eine mit Multiplexer (für CPLD) und eine mit 
Schieberegister (für FPGA).

[Peter B. (funkheld)]

Hmm..., das Start und Stoppbit nimmst du mit in deine Sendedaten  rein:
'1' & TX_Data & '0'

Gruss

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

Peter Bierbach schrieb:
> das Start und Stoppbit nimmst du mit in deine Sendedaten  rein:
> '1' & TX_Data & '0'
Das ist nur logisch, diese Bits werden ja mit denselben Parametern wie 
die 8 Datenbits übertragen.

[Peter B. (funkheld)]

Eben..., die sehe ich aber nicht bei der Übertragung von oben.
Mit Schalter Stop und Go geht es nicht.

Gruss

[Peter B. (funkheld)]

Hmm.., so sah vor Monaten mein erstes RS232-TX aus bei 50Mhz und 
9600Baud. danach habe ich erst die anderen Programme begriffen die sich 
hier rumtummeln. Da habe ich auch gesehen das bei TTL das Startbit "0" 
ist und das Stoppbit "1" sein muß.

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

entity RS232_tx_test is
    Port ( 
           TXD : out STD_LOGIC :='0';
           sw  : in std_logic_vector(0 downto 0);
           CLK : in STD_LOGIC
           );
end RS232_tx_test;

architecture Behavioral of RS232_tx_test is

signal c : integer range 0 to 25000000 := 0; 
signal tx_bit : STD_LOGIC :='0';

begin
process
begin
  wait until rising_edge(CLK);   
  c<=c+1;
  
  if sw(0)='1' then  --start   
    if c = 5208 then --startbit
      tx_bit <='0';
   
    elsif c = 10416 then --00000001
      tx_bit <='1';
   
    elsif c = 15624 then --00000010
      tx_bit <='1';
  
    elsif c = 20832 then --00000100
      tx_bit <='1';
   
    elsif c = 26040 then --00001000
      tx_bit <='0';
    
    elsif c = 31248 then --00010000
      tx_bit <='0';
     
    elsif c = 36456 then --00100000
      tx_bit <='0';
   
    elsif c = 41664 then --01000000
      tx_bit <='0';
    
    elsif c = 46872 then --10000000
      tx_bit <='0'; 
    
    elsif c = 52080 then --stopbit
      tx_bit <='1'; 
    end if;
  end if;  
  TXD <= tx_bit ;  
  
end process; 
  
end Behavioral;

[moppel (Gast)]

Alexander F. schrieb:
> Moppel schrieb:
>> Im nächsten Schritt soll ein SPi Master implementiert werden mit dem ich
>> dann einen Adc auslese.
>
> Nicht so schnell!
> Beim Uart Modul gibt es noch ein paar Kleinigkeiten, die geändert werden
> sollten.
> Problematisch ist, dass du den send-Eingang ebenfalls mit der Baudrate
> abfragst und nicht mit der vollen Taktfrequenz. Bei einem Taster ist das
> noch egal, wenn du den aber eliminierst, wird es problematisch.
> Du müsstest jetzt dein Clock-Enable Modul ins Uart Modul integrieren und
> den Prescaler erst starten, wenn der Eingang auf high geht. Nur so
> kannst du garantieren, dass auch bei einem High Puls, der nur einen
> Taktzyklus dauert, sendest.


Ich habe mir mal ein wenig gedanken darüber gemacht und hoffe ich weiss 
worauf du hinuas willst.

Also den Code habe ich so verändert:

FSM : process (clk, rst) is
begin
  if rising_edge(clk) then
    if sendeTaster = '0' and send = '1' then -- Taktflanke des Tasters
        Send_puffer<= din;
        state <= Sende;
        bitcounter <= 0;
      end if;    
    if Uart_Enable='1' then
      if state = Warte then
        txd <= '1';
      else --Sende
        if bitcounter = 0 then
          txd <= '0'; -- start bit
        elsif bitcounter = 9 then
          txd <= '0'; --stop Bit
          state <= Warte;
        else --Daten senden
          txd<= Send_puffer(bitcounter -1);
        end if; --bitCounter
        bitcounter <= bitcounter + 1;
      end if; --Sende
    
      sendeTaster <= send;
      end if;
  end if; -- clk
  
    if rst = '1' then
      state <= Warte;
      bitcounter <= 0;
    end if; 
  
end process;

zuvor wurde der send status in der Frequenz der Baudrate abgefragt. bei 
einem mechanisch verursachten signal ist das kein problem aber durch 
andere signale könnte das send signal zu kurz sein um erkannt zu werden.

habe jetzt die abfrage so wie du vorgschlagen hast durch den Master_CLK 
implementiert sodass dass das Send Signal alle 10ns abgefragt werden.


Bin ich auf der richtigen spur oder komplett daneben?

[Alexander F. (alexf91)]

moppel schrieb:
> Bin ich auf der richtigen spur oder komplett daneben?

Ja, das passt.
Du startest den Sendevorgang zwar nicht sofort, für Uart ist das aber 
egal.

[Duke Scarring (Gast)]

Peter Bierbach schrieb:
> elsif c = 10416 then --00000001
>       tx_bit <='1';
>
>     elsif c = 15624 then --00000010
>       tx_bit <='1';
>
>     elsif c = 20832 then --00000100
>       tx_bit <='1';
>
>     elsif c = 26040 then --00001000
>       tx_bit <='0';
>
>     elsif c = 31248 then --00010000
>       tx_bit <='0';
>
>     elsif c = 36456 then --00100000
>       tx_bit <='0';
>
>     elsif c = 41664 then --01000000
>       tx_bit <='0';
>
>     elsif c = 46872 then --10000000
>       tx_bit <='0';
>
>     elsif c = 52080 then --stopbit
>       tx_bit <='1';
Was soll denn der Murks?!1elf!!

Jedesmal wenn sich die Übertragungsrate ändert, setzt sich unser 
Pensionär hin und rechnet neue Zeitpunkte aus?

Alle Welt verwendet zwei verschachtelte Zähler: Einen Bitzähler und den 
anderen für die Bitrate. Fertig.

Duke

[Peter B. (funkheld)]

Das war mein aller erstes RS232 um zu testen nach dem Motto: Wie geht 
das eigentlich mit meinem FPGA wenn ich einfach mal die Zeiten für 
9600Baud reinsetze ? Die Boards kannte ich nur vom lesen her. Ich war 
stolz, das die Daten fehlerfrei am PC ankamen.

Wenn ich meine VHDL sehe gegenüber anderen Fachidioten hier , die sogar 
Studierende sind , da war ich ein bisschen weiter.

Wenn ich bedenke das ich jetzt meine 2GB-SD-Karte auf meinem DE1 
betreiben kann (kein FAT usw) ein freies System wo ich immer 512Byte in 
den Sector schreibe oder lese , bin ich doch stolz drauf mit 65 Jahren.

GRuss

[berndl (Gast)]

Peter Bierbach schrieb:
> Wenn ich bedenke das ich jetzt meine 2GB-SD-Karte auf meinem DE1
> betreiben kann (kein FAT usw) ein freies System wo ich immer 512Byte in
> den Sector schreibe oder lese , bin ich doch stolz drauf mit 65 Jahren.

kannst du ja auch sein, ist voll in Ordnung! Und dann lass' bitte das 
arrogante Gehabe, "antworte" mal sinnvoll wenn dir hier jemand 
Hilfestellung gibt... Und dann kann man hier auch mal wieder 'normal' 
diskutieren...

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

berndl schrieb:
> "antworte" mal sinnvoll wenn dir hier jemand Hilfestellung gibt.
... oder wenn du jemandem "helfen" willst. Helfen ist nicht 
"herumprotzen, wie ICH das gelöst habe", sondern "dem anderen einen Weg 
aus seiner Problemstellungen zeigen".
Du, Peter, gehörst für mich zur Zeit zur ersten 
Schau-mal-wie-toll-ich-bin-Sorte. Immerhin ist daraus auch nichts 
geworden: Beitrag "DE1-Steuerung vom PC über RS232"

[Peter B. (funkheld)]

-----------------------------------------------
Schau-mal-wie-toll-ich-bin-Sorte. Immerhin ist daraus auch nichts
geworden: Beitrag "DE1-Steuerung vom PC über RS232"
-----------------------------------------------

Derartige Projekte für eine Verbindung mit Gui und DE1 stossen hier 
nicht so auf Anklang. Darum habe ich mir nicht die Mühe gemacht so etwas 
reinzustellen. Das Projekt ist zum Kaputschreiben von euch zu schade.

Wenn einer ernsthaft so etwas braucht, kann er sich melden.

GRuss

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

Peter Bierbach schrieb:
> Derartige Projekte für eine Verbindung mit Gui und DE1 stossen hier
> nicht so auf Anklang.
Woher weisst du das?

[Duke Scarring (Gast)]

Lothar Miller schrieb:
> Woher weisst du das?
Er hat sich die Threads zum Projekt von Josef G. durchgelesen...