I began to study PIC assembly and I have one issue with PIC16F877 related with push buttons. Firstly, I show you configuration:
I want to check if SW04,SW05,SW06,SW06,SW11 are pressed, but I guess RB7 is responsible for SW07 and SW11. Will it cause problems, if I will only check for RB7, because in one function I must check SW07 and SW11 buttons.
No, it is not going to cause problems because when you check RB7 at certain moment of time you know for sure what line caused the signal: RB2 or RB1. If you register RB7 and RB1 is the active one, that means SW07 is pressed, if RB2 is active - then SW11 is pressed. I am assuming your program moves the logic '1' from RB0 to RB3 and every line has '1' at certain moment whilst others are Zeros.
No worries. Turning on pull-up resistors at RB4-RB7 inputs should not cause problems, it is just the determined state of input when it is in tri-state. These inputs should work well and normally see what RB0-RB3 outputs give them: '0' or '1'. By the way you can choose between two methods: when '0' moves among RB0-RB3 and others are '1', or when '1' moves around the RB0-RB3 among zeros. Depending on this you are scanning for '0' or for '1' respectively at RB4-RB7.
Related
I'm going to write a code with three cases(PINA first three ports as inputs and PORTB as outputs), One, toggle all led's connected to PORTB simultaneously with a period T1 when PINA.0 has went HIGH,Second toggle all led's one after one with a period T2... when PINA.1 went HIGH...
The problem is when ever an another input has went high the process should be stopped and switched to the corresponding input, can I use timers and interrupts for this goal?
... can I use timers and interrupts for this goal?
Answer is YES :)
I'm working on a FPGA project where I need to read data from an image sensor. This sensor has different image modes (like test pattern, frame, binning, etc.) and in order to change image mode I need to look for specific signals before writing into the registers.
I have inherited some code that I need to fix since the image sensor sometimes gets stuck when we change image mode.
Concerning the change of image mode, a state machine is used.
The following piece of code shows how the registers for changing mode are currently written.
Essentially, when we want to change mode, we need to wait that the signal MODE_SIG_HIGH becomes high before writing into the registers. Then, when this condition happens, we check what mode we want to set. For example, to set set test pattern, we check if bit S2 is set. Then we performs all the operations to actually change mode (line 10).
01. ...
02. WHEN MODE_SIG_HIGH =>
03. NEXT_ST <= MODE_SIG_HIGH;
04. ...
05. IF S2 = '1' THEN
06. -- configure the sensor to
07. NEXT_ST <= CONFIGURE_TEST_PATTERN;
08. END IF;
09. ...
10. WHEN CONFIGURE_TEST_PATTERN =>
11. ...
I'm having a debate with a friend of mine concerning what is the best way to change state when a new event happens. The above solution doesn't seem right to me.
As far as I understood, when we enter a sate, all the instructions contained in that state are performed in parallel. Therefore, concerning the above piece of code, when we enter the state MODE_SIG_HIGH the instruction at line 03 is executed in parallel to the IF condition. My point is that if the bit S2 is set to 1, the IF condition is true and we end up assigning the value CONFIGURE_TEST_PATTERN to the NEXT_ST. An this ends up in assigning two different values to the same variable (in parallel), in line 03 and in line 07. Am I right or am I missing some basic behavior? The reason for having the instruction at line 3 is because after we enter MODE_SIG_HIGH, it could take some clock cycles before we see on of the mode bits set.
As far as I understood, when we enter a sate, all the instructions
contained in that state are performed in parallel.
Not quite. The only things in VHDL which are concurrent ('performed in parallel') are:
processes
concurrent signal assignments
component instantiations
concurrent procedure calls
concurrent assertions (inc.PSL)
generates
blocks
The code inside a process or subprogram (function/prodedure) executes sequentially. This is where you do your conventional programming, using sequential statements (ie. nothing in the list above). These are your standard control constructs (if, case, loop, etc), sequential signal assignments, and so on. If you carry out signal (or variable) assignments in a sequential region, the last one wins, just like a conventional programming language. There are scheduling rules that make this happen, but you don't need to know about those (yet!)
I am using the internal oscillator (FOSC = 7.37 Mhz) of the dsPIC33EV256GM102. I have a 1602 LCD connected to the PIC via 4 data, and enable, RW, and RS control lines.
I write initialization commands to the LCD and then two lines of text. That works fine.
After 2 minutes and 10 seconds the enable line quickly pulses high-low causing something to be written to the LCD. It happens again in another 2:10 and then again, repeatably.
All my program does right now is initialize the LCD, write two lines of text and go directly into a while(1).
I have tried setting the LCD enable low on every iteration of the While. I have tried latching the enable low before going into the While. I have moved the enable to another pin but the pulse still occurs on that pin. If I remove the enable line after writing the data, the problem goes away.
Any thoughts what might cause this kind of behavior or what additional troubleshooting steps I might take?
I am using pin 24 labeled RPI45/PWM1L2/CTPLS/RB13 for the enable but I have also tried pin 23 labeled RPI44/PWM1H2/RB12. I am not executing any code related to peripheral pin select yet.
When I download the program via the Pickit3, for the first POR while the Pickit3 is still in the circuit, there is some spurious text written to the LCD. So I have to disconnect the Pickkit3 and do another POR before the two line of text are written correctly without any unwanted additional data writes.
In conclusion there are two issues really or perhaps they are related?
When using SignalTap I do get a timing violation with a negative slack, between the System-Clock (FPGA_CLK1) via the internal ADC and the SignalTap signals. Here some screenshots:
TimeQuest
ChipPlanner
TechnologyMap
If SignalTap is not included to the design, no timing issues at all. How to avoid such timing violation when using SignalTap in the same design and/or is there another issue for example with the FPGA_CLK1?
Thanks in advance for some hints..!
One possible solution, is to register the signals you are trying to capture. So basically, you are capturing one clock later than the "real" signal. But if you register all the signals being monitored, then you should get better timing because those registers will be closer to the signal tap blob.
Also do it without a reset to take that timing element out of the equation.
always # (posedge clk)
begin
sig1_out <= sig1_in;
sig2_out <= sig2_in;
sig3_out <= sig3_in;
....
sigX_out <= sigX_in;
end
Hope that helps.
Each module can be consider to have following power:
[1] It can store data.
[2] It can operate on the data.(arithmetic operation)
some property of modules (listing just that, i am concerned with right now.)
[1] all register/memory element in modules are RAISING edge triggered.
Now this architecture can be use to create a model of a computer processor.
Real Deal:
Is it neccessary to have "control unit next state register" to be FALLING egde triggered ?
(below i explain why i think so)
CLOCK:
|------| |------|[1] |------| |------|
_____| |_________| |_________| |_________| |____
|----|
Data should be valid in this region at least.(considering the setup/hold time).
|----------------|[1]
____________| |_________
So the write signal should be up (if control unit want to) in this region.
This control signals are just the conbinational result of input and CURRENT STATE.
SO that means as the current state changes the control signal changes, which implies the state should change at falling edge[1].
So change of state is simply the change in "control unit state register" which is happening at the falling edge of the clock.
Thats why i think "Is it necessary to have "control unit next state register" to be FALLING edge triggered" ....am i thinking/considering things right ?
If yes then the same(falling edge triggered of control unit state register ) should be happening in actual processor as well.
I am learning stuff so please forgive + correct my mistakes
A common way to handle this is to consider the rising edge of the clock to trigger the “fetch” cycle, and the falling edge to trigger the “execute” cycle.
During “fetch” the memory address is incremented and data from memory is alowed to stabilize and propagate to control circuits (such as ALU’s settings , demultiplexers to control things, multiplexers to sample states for conditional tests, set up shift logic, etc).
During “execute” the things being controlled by the control circuit outputs are triggered (i.e. the test state being read by a multiplexer would be tested, and if true a branch might be taken by loading the program counter with the branch address,so that during the next fetch cycle the system would load the next instruction from the branch address instead of simply incrementing to the next address in memory ).
ANSWERED by: a generous man "BL" (name initials)