This is my first GitHub, I want to write a report but this green line keeps popping up next to my text and I don't want it to do so. This is what my text should be but it appears like this: https://gyazo.com/f593db78a387623fcad31c744ac9a120
How can I control this?
System Hardware Final Report
The project designed shows the functioning behind computer's.
The topics covered will include:
Introduction to Binary & Logic Gates
Commonly Used Parts
Logic Functions
The Timing Signal Generator
The Bus, Arithmetic Unit and Program Counter
Data Registers and the Memory Address Register
Program Memory
The Control Signal Generator
The outcome of this project will enable one to build a computer with a CPU (central processing unit) that can do simple
instructions such as moving data from one register to another and performing simple arithmetics.
Introduction to Binary & Logic Gates
Breadboard
The breadboard will be used to setup the components and all circuits. It is divides in 8 parallel coloumns and contains 5 columns that
provides power. In fact, the breadboard is made up of two important supply connections: the VCC for the red
line and the GND for the blue line. The holes are all connected row-by-row in lines of 5.
Switches
This happens when you make changes to a file (this is called a diff), then preview it. Green indicates something was added, while red indicates something was removed. Committing the changes will not make the lines stay in the file.
Related
If the PC register is simultaneously read and written, does its read data contain the previous data or the newly-written data? Based on my understanding of sequential circuits, the effect of the write command does not instantly take effect in the PC register due to propagation delay so, at the rising edge of the clock, the read command will get the old value. But corollary to my question is if this is the case, shouldn't the read command would also have a delay in some sense and could possibly read the newly-written data?
A program counter is normally special enough that it's not part of a register file with other registers. You don't have a "read command", its output is just always wired up to other parts that read it when appropriate. (i.e. when its output is stable and has the value you want). e.g. see various block diagrams of MIPS pipelines, or non-pipelined single-cycle or multi-cycle designs.
You'd normally build such a physical register out of edge-triggered flip-flops, I think. (https://en.wikipedia.org/wiki/Flip-flop_(electronics)). Note that a D flip-flop does latch the previous input as the current output on a clock edge, and then the input is allowed to change after that.
There's a timing window before the clock edge where the input has to remain stable, it can start to change a couple gate delays after. Note the example of a shift register built by chaining D flip-flops all with the same clock signal.
If you have a problem arranging to capture a value before it starts changing, you could design in some intentional clock skew so the flip-flop reliably latches its input before you trigger the thing providing the input to change it. (But normally whatever you're triggering will itself have at least a couple gate delays before its output actually changes, hence the shift-register made of chained D flip-flops.)
That wiki article also mentions the master-slave edge-triggered D Flip-Flop that chains 2 gated (not clocked) D latches with an inverted clock, so capturing the input happens on the opposite clock edge from updating the output with the previously-captured data.
By comparison and for example, in register files for general-purpose registers in classic RISC pipelines like MIPS, IIRC it's common to build them so write happens in the first half-cycle and read happens in the second half-cycle of the ID stage. (So write-back can "forward" to decode/fetch through the register file, keeping the window of bypass-forwarding or hazards shorter than if you did it in the other order.)
This means the write data has a chance to stabilize before you need to read it.
Overall, it depends how you design it!
If you want the same clock edge to update a register with inputs while also latching the old value to the output, you a master-slave flip-flop will do that (capture the old input into internal state, and latch the old internal state onto the outputs).
Or you could design it so the input is captured on the clock edge, and propagates to the output after a few gate delays and stays latched there for the rest of this clock cycle (or half cycle). That would be a single D flip-flop (per bit).
I am currently developing a subset of the 6502 in LogiSim and at the current stage I am determining which parts to implement and what can be cut out. One of my main resources is Hanson's Block Diagram.
I am currently trying to determine how exactly the increment logic works. In a previous project that I worked on in school, the program counter was incremented via a single instruction coming from the decoded instruction memory. In this diagram, the program counter logic looks like it works differently than I have previously encountered.
How exactly does this logic work and does it use an instruction from the instruction memory to increment? As a follow up, Is it possible to simplify the program counter logic to use one or two instructions from the instruction memory to increment?
The 6502 has only one program counter. It is 16 bits wide. Because a lot of other things in the CPU are exactly 8 bits wide, it makes hardware sense to cut the 16 bit program counter into two halves, so that each half fits in 8 bits. For example, each half is loaded separately, one by one, with an instruction like JMP. And the relative branch instructions bring PCL to an ALU input.
Those halves are just called PCH and PCL internally. You can see that PCL has increment logic attached to it, and one of the outputs is a carry out signal called PCLC. That's the input to another circuit that increments PCH.
None of this matters to a program. The program just cares that PC points to the instruction that's going to be executed next, and uses that fact to influence its own flow. But if you're interested in knowing more of these details, I'll point you to the Visual6502 simulation. It's much more accurate and detailed than Hanson's Block Diagram.
So I reverse-engineered an RC toy wireless protocol, and written a flow graph in GNU Radio Companion for reproducing the toy's commands.
The sink block is osmocom sink, and transmitting device is HackRF One.
The problem I encountered is severe lag between pressing button and toy reacting, which is about 1-2 seconds.
Quickly pressing, for example, "forward" button twice will result in toy jerking forward twice in quick succession as well, about a second after pressing. So it's not like the flow graph itself is slow. The CPU usage is also fairly low. This looks like some buffering issue.
I'm pretty sure that the flow graph itself reacts to button presses instantly, as debugging prints appear the same time as button is pressed/depressed, and square waves appear in the GUI scope sink instantly, as well.
I tried to lower number of HackRF buffers to one (by settings device arguments to hackrf,buffers=1), but it didn't help.
I set "Max Number of Outputs" to 10 for flow graph as well, and it also didn't make a difference (I tried some other values, too). Given that signal appears in the GUI scope much sooner than after 1 second, it shouldn't have worked anyway.
How can I reduce the latency then?
EDIT: I followed #Manos's suggestion and tried adjusting sample rate.
Adding a rational resampler block with interpolation of 8 (and adjusting sink sample rate accordingly) AND setting hackrf,buffers=1 makes latency almost non-existent.
However, reducing output sample rate of my custom block to 500k and having 16x interpolation still causes noticeable lag, maybe 400-500ms (still not as dramatic as when it's 1M at both source and sink). I'm not sure how to fix it. Unfortunately, running my custom block at 1M consumes 100% CPU and causes occasional underflows.
I need to control a conveyor (driven by Micromaster 440) from a PC program using SFC14/15.
The scheme will be: Supervisors PC ->(ethernet)-> S7-1200 ->(profibus)-> Micromaster 440.
At the moment, Micromaster's output frequency is controlled via a potentiometer (analog inputs) by the "field" operator. The problem is that sometimes the operator increases the conveyor speed in order to do his job faster and this affects the production negatively. The "supervisor" wants to be able to limit output frequency using the PC program.
Of course I've seen the list of MM440 parameters and I know about P1082, but I've discovered that, unfortunately, MM440 should be stopped before the new value of P1082 takes effect. In my case it's preferable to be able to change the value on the run.
Fortunately, it seems that P0757 - P0760 - (input scaling) can be changed on the run, but this parameter has sign "first confirm", which means that
the “P” button on the operator panel (BOP or AOP) must be pressed before the
changes take effect.
But the MM440 has only one slot for the Profibus/BOP/AOP panel and I'll be using Profibus. So, in this case, what will be the behavior of mm440 like? I want to believe that, perhaps, this condition is not obligatory when using profibus panel...
I would opt for a solution where the operator no longer operates the belt speed directly but tells the S7-1200 PLC a what speed he would like the belt to run (either by using 2 +/- buttons or a pot-meter). The PLC can then control the speed of the belt (either by analog output or 2 digital (+/-) outputs).
As an added bonus you can stop the belt when it is accidentally left on and things like that...
I am implementing some head tracking and I get 2 matrices of horizontal velocities. (A vector field decomposed into vertical and horizontal velocities). For each of these matrices I do some math to calculate the actual head tracking.
My question is, is there a way to do that math (which is a set of blocks) on both matrices without copying the math blocks onto each signal?
It's hard to explain so here's a screen shot of my model:
You can see that the "complex to real-imag" block has 2 outputs (this is the little one in the middle). The mean block and the integrator circuit then calculate the head velocity and position for the real matrix (horizontal position). I want to do exactly the same routine on the imaginary matrix (vertical direction). Obviously I can just copy the blocks, but surely there must be a better way of doing it? In a way I'm looking for an analogue of a loop in "normal programming" like C or something, where a block of code is executed several times on different inputs.
You can create a Library in Simulink that contains code you can reference multiple times.
Go to File -> New -> Library. In the model window that opens, you can create any number of subsystems with whatever code you want. Then, just drag a subsystem from the library into your model. The subsystem will now appear in your model with a little arrow icon in the lower left. This indicates that the subsystem in the model is a link. You can drag as many instances of the library subsystem into your model as you wish, just as you can call a function as many times as you wish in any other programming language.
If you right-click on the subsystem in your model, you can select "Link Options -> Go To Library Block" to get back to the library. You can make changes in your model and propogate them back to the library as well.
One way to easily reuse a set of blocks is to create a subsystem out of them. In your case, you can create a subsystem by grouping existing blocks, then simply copy and paste your subsystem to use it for your imaginary output.
Although potentially more complicated, you could also look into using mux signals to avoid having to copy parts of your model.