I need to check which button has been pressed and compare it with a function. For example if button 0($01) is pressed, the program will compare it with the OP, 3, and if both conditions are true, the program will start again (init), otherwise if one of the conditions is false the program will loop through the subroutine again. At the moment It doesn't do anything, it should compare the button press, but it seems not to. So far I have done this:
;$01 == XOR button, $02 == NOR button, $04 == OR button, $08 == NAND button, $10 == AND button
button_pressed:
in temp2, PIND
xor_pressed:
cpi OP,3
cpi temp2, $01
brne button_pressed
rjmp init
nor_pressed:
cpi OP,4
cpi temp2,$02
brne button_pressed
rjmp init
or_pressed:
cpi OP,0
;cpi temp2,$04
brne button_pressed
rjmp init
nand_pressed:
cpi OP,2
cpi temp2,$08
brne button_pressed
rjmp init
and_pressed:
cpi OP,1
cpi temp2,$10
brne button_pressed
rjmp init
I do not know if you really need to use assembly instructions.
May I recommend using atmel studio which is a free for personal/commercial use IDE cross compiler which work for all Atmel microcontrollers?
Install Atmel studio and goto create new executable project and it will allow you to select the target controller.
I am sure you can finish your coding in C or C++ at fraction of the time you will spend debugging assembly code.
Related
Well, my problem was this, but I solved it!
I'm posting this in case this can help someone else.
I'm using Logic Pro.
I wanted to use sustain pedal midi data to toggle (latch) a button, such that I press the pedal once, and the button goes to 'ON' position. Press again and it goes 'OFF'. I wanted to use this to mute/unmute a talkback mic.
Here is my solution. If anyone can improve, go ahead!
Basic Logic ENV :
Logic ENV
Filter 0: (Filter out 0 values)
Alt Split: (alternate pedal down instructions between 2 outputs)
Rev Pol: This generates sus pedal value 0 for every other pedal down
The object 'TALK' is just to display current state, but could be patched to anything.
See the above images for mu own solution
The MSDN documentation says that the elements of button state are focus, push, and check.
Looking into the header we see:
BST_CHECKED 0x0001
BST_INDETERMINATE 0x0002
BST_PUSHED 0x0004
BST_FOCUS 0x0008
but when I push a button in my application Button_GetState yields the integer value 108 (then 104 if I drag outside of the button). So here we have the first four bits accounted for, but what about after that? What about 16,32, 64? My button is not one that uses check state as far as I can tell, yet I still see these being used.
In short, what are the other individual bits doing?
I have been working on an assembly language project for a class and though I have finally been able to work through all problems in this code ( I believe ), I now can't seem to get the Register contents to display.
Here is my code...
include C:\Irvine\Irvine32.inc
.data
;Variables are listed in following order VAR DATATYPE DIGITS[RADIX] with
comments showing binary version of listed digits
left DWORD 321 ;101000001b
right DWORD 4247 ;1000010010111b
total DWORD ? ;uninitialized
diff DWORD ? ;uninitialized
;Define a string called message containing HELLO WORLD!
message BYTE '"Hello world!"'
;Calculate length of Array and move to var ArrayLength
Array WORD 1,2,4,8,16,32,64 ;Array
ArrayLength = ($ - Array) / 2
.code
main PROC
;Move left and right to respective registers
MOV eax,left
MOV ebx,right
;Add left var and right var and store in new var called total and move to
ecx
MOV total,eax
ADD total,ebx
MOV ecx,total
;Subtract left var and right var and store in new var called diff and move
to edx
MOV diff,eax
SUB diff,ebx
MOV edx,diff
;Move Array to esi
MOV esi,ArrayLength
call DumpRegs
exit
main ENDP
END main
When I debug I get no error messages but the IDE does not display the registers or its contents which I need.
I searched everywhere to try and see what might be the problem and got some answers and was able to find some regarding opening the register window in VS on this website...
https://msdn.microsoft.com/en-us/library/62680774.aspx
But I tried to find this window in my IDE even after enabling address-level debugging but to no avail. I don't know if it is a problem with how I installed or is there no register window in VS2017 ... any help would be very welcome
For the record I am using Visual Studio 2017
I have tried adding a wait after call DumpRegs and even a breakpoint but that simply stalls the run and doesn't display the registers whatsoever..
What it looks like after I add a breakpoint
Thanks to #Jester I was able to see the registers window. (See how to use the registers window in the Visual Studio docs.)
It may be trivial but I will state it nonetheless. In order to see the register window you need to input a breakpoint before the exit of the program or write your program to pause on it's own using the Irvine wait macro, or call ReadChar, or similar.
After it pauses, you can reach the register window by going to debug window and windows sub-window, and voila, you have the register contents visible.
Right click in the register window and select UC and all data you want to display
I've spent hours and a trees worth of paper sketching and I haven't been able to stumble upon anything to get me past this problem. I'm able to switch back and forth between two motors but I can't figure out how to turn the motors off while switching between them, while still following the criteria below.
Using ladder logic:
Use only one start stop station consisting of only one NC contact and one NO contact, two motor starters and three control relays create the following cycle. (No timers or counters)
When the start button is pressed motor 1 will start and run until stopped by pressing the stop button.
When the start button is pressed again motor 2 will run until stopped by pressing the stop button.
When the start button is pressed again motors 1 & 2 will run until stopped by pressing the stop button.
Pressing the start button again will now start the cycle over.
Any help is very appreciated.
Thank you
Ira Baxter is right. You should use a state machine. I have set-up one below. Normally you would draw such a state machine using circles and arrows, but this will do for now I guess...
Although you talk about having 3 different steps (states) I actually see 6 states:
State0: Both motors are switched off (If start button pressed goto state 1)
State1: Motor 1 running (If stop button pressed goto state 2)
State2: Both motors are switched off (If start button pressed goto state 3)
State3: Motor 2 running (If stop button pressed goto state 4)
State4: Both motors are switched off (If start button pressed goto state 5)
State5: Both motors are running (If stop button pressed goto state 0)
What you should do is have one block determine the state (0..5) and have the motor-control blocks react to that state.
If you are limited on relays and don't want state machine you can do it with only 2 relays. Use logic flags to solve it. This example assumes you have rising edge contacts and set+reset coils as starters. I can't write ladder code here so I do what I can:
START is NO button and STOP is NC button. M1+M2 are motors F1+F2 are relays
START M1 M2 F1 F2 M1
-|P|--|/|--|/|--|/|--|/|--(S)
STOP M1 M2 M1 F1
-|N|--| |--|/|--(R)--(S)
START M1 M2 F1 F2 M2
-|P|--|/|--|/|--| |--|/|--(S)
STOP M1 M2 M1 F2 F1
-|N|--|/|--| |--(R)--(S)--(R)
START M1 M2 F1 F2 M1 M2 F2
-|P|--|/|--|/|--|/|--| |--(S)--(S)--(R)
STOP M1 M2 M1 M2
-|N|--| |--| |--(R)--(R)-
Imagine an application that displays a button: OK. Is it possible to break the execution of the program and view the disassembly using WinDbg, right after the button has received a click? How would I do that? In this scenario, the source code is not available.
So, your description is very general, and not very well defined, and the exact research really depends on the application that you are trying to reverse. You will have easier time if you have symbols, but these aren't required.
First, some (trivial) background: Windows communicates with the application through Windows Messages. The application will fetch messages from the message queue, and almost always will dispatch those messages to the appropriate Windows Procedure.
So, first - what do you mean: "right after the button has received a click"? I suspect that you actually don't care about this code. Although your application could have a custom button, and you really care how the button handles a WM_LBUTTONDOWN message. I'm going to assume that your application has a Windows stock button (implemented in user32.dll or comctl32.dll), and that you don't care about that.
The default implementation of a button control handling WM_LBUTTONDOWN is to send WM_COMMAND to the window that contains the button. Typically, the application that you want to investigate handles the "click" there. Now, if this is the 'OK' button, it's ID would be IDOK (defined to be 1), and Windows will send you the same message also when you click the 'Enter' key.
So, we are now looking for how the application handles WM_COMMAND. What you want to find is the Windows procedure. Do that with Spy++. Open Spy and find the Window that contain your button. Most chances that the code you are looking for is in the Windows Procedure of that window. Spy++ will tell you the address of the Window Procedure.
As an example, let's look at the 'Save' button of the 'Save As' dialog in Notepad. On my machine the address is: 0x73611142, which is in ComCtl32.dll
Go to WinDbg, and take a look at the function.
0:000> u 73611142
COMCTL32!MasterSubclassProc
73611142 8bff mov edi,edi
73611144 55 push ebp
73611145 8bec mov ebp,esp
73611147 6afe push 0FFFFFFFEh
73611149 6858126173 push offset COMCTL32!Ordinal377+0x146 (73611258)
7361114e 68a1b06273 push offset COMCTL32!DllGetVersion+0x336f (7362b0a1)
73611153 64a100000000 mov eax,dword ptr fs:[00000000h]
73611159 50 push eax
This is indeed a function. Like all Windows, it starts with move edi,edi, and then it sets the frame pointer.
Put a break point, hit go, and you'll almost immediately break. Let's take a look:
0:000> bu 73611142
0:000> g
0:000> kb1
ChildEBP RetAddr Args to Child
0101f220 75d87443 00120c6a 00000046 00000000 COMCTL32!MasterSubclassProc
The first argument (00120c6a) is handle of the window. Compare with the value on Spy++, it should be the same. The second argument is the message. In my case it was 0x46 which is WM_WINDOWPOSCHANGING.
OK, I don't care about all those messages, and I want to break only on the messages I care about. You care about WM_COMMAND which is 0X0111 (winuser.h)
Now, put the following (a little bit complex command):
0:000> bu 73611142 "j poi(esp+4)==00120c6a AND poi(esp+8)==111 AND poi(esp+''; 'gc'"
breakpoint 0 redefined
You set a breakpoint on the windows procedure, and you tell WinDbg to break only when the first argument ( that's the poi(esp+4) ) is your Windows handle, and the second argument is 111. The 'gc' tells WinDBG to continue the execution when the condition will not meet.
Now you can debug the disassembly. If you have symbols, you'll have an easier job, but this isn't necessary. In any case, remember to download the Microsoft stripped down symbols from the symbols server, so if the code you are debugging is calling a Windows API, you can see it.
That's about it. Modify this technique if your requirements are different (different Window, different message, etc). As a last resort consider putting a breakpoint on PostMessage or DispatchMessage if you can't reliably find the Windows Procedure (although, you'll have to follow that code). For heavy lifting reversing use IDA, which will disassemble the executable, and solve various cross reference.
Assuming you had the pdbs and they did not have the private symbols stripped then you would set the breakpoint on the button handler like so:
bp myDLL!myWindowApp::onOKBtnClicked
If you had the pdbs then you could search for a likely handler using x:
x myDLL!myWindowApp::*ok*
this presumes that you know or can guess which dll and what the function name is, otherwise you could gleam this information using spy++, Win Spy++ or Win Detective to get the handle for the button and intercept the window messages and from that info set the breakpoint.
Once it hits the breakpoint you can view the assembly code using u, there is a msdn guide if you require it.