Discussion in "Project Addition or Changes" started by    Milz    Dec 17, 2007.
Thu Dec 20 2007, 08:10 pm
#11
weeeeeww... That last post made it a lot clearer thx..

another thing, this is UART transmission right ? (between 8051 and VB)
if so, how many bits are we transmitting, 8 or 9 ?

as a last question for today , '#30H' is 30 in Hex right? u didnt use the standard RC5 commands ..
Thu Dec 20 2007, 11:53 pm
#12
yes transmission is between VB and 8051 and its only 8 bit

30H is 0x30 or 30 hex. i read the standard commands but i send back the normal digits.. coz its easy to debug using a simple hyper terminal
Sun Dec 23 2007, 08:28 pm
#13

whenever you change the mode from WMP to Mouse or Mouse to WMP control, mode bit is changed and VB software is informed about the changed mode.



I dont quite get that, you mean one of the 8 bits sent, informs the vb abt the mode status? Or is it just that the vb starts off with a certain mode initially, and toggles it everytime the user presses 0 ? ( cause that's how i understood it )

Another thing i do not understand in the code, in the mouse routine...
mskip2:  
	cjne a,#03H,mskip3
	acall chk_valid
	jb VALID,ok2
	ret
ok2:
	mov a,#33H
	acall tx
	ret

What does the chk_valid do? and why it is only for a few commands of the mouse routine ?


mskip6:
	cjne a,#26H,mskip7
	mov a,#37H
	acall tx
	ret

also in the mouse routine, why are you expecting a 26hex , since it's the 7 button?:-/
Mon Dec 24 2007, 01:08 am
#14


whenever you change the mode from WMP to Mouse or Mouse to WMP control, mode bit is changed and VB software is informed about the changed mode.



I dont quite get that, you mean one of the 8 bits sent, informs the vb abt the mode status? Or is it just that the vb starts off with a certain mode initially, and toggles it everytime the user presses 0 ? ( cause that's how i understood it )

Milz


Yest it starts with mouse mode initially.. and toggles it after pressing power key. when power key is pressed controller send 0 and then software replies back with mode.. if software send 'm' that means its in mouse mode.. so mode bit is toggled and controller switches to keyboard mode.

Another thing i do not understand in the code, in the mouse routine...

mskip2:  
	cjne a,#03H,mskip3
	acall chk_valid
	jb VALID,ok2
	ret
ok2:
	mov a,#33H
	acall tx
	ret

What does the chk_valid do? and why it is only for a few commands of the mouse routine ?

Milz


As i already said.. for navigation keys like Up, Down, Left, Right Toggle bit is not checked.. but for others like left click and right click toggle key is checked. So for only few commands this routine is used.


mskip6:
	cjne a,#26H,mskip7
	mov a,#37H
	acall tx
	ret

also in the mouse routine, why are you expecting a 26hex , since it's the 7 button?

Milz


well.. this is a different story you will see an extra piece of code added for 26H and 38H the reason was.. i was not having volume+/- keys on my test remote.. as it was a custom made... so i used those keys for same operation of Vol+/- you can remove that code if you want.. it was only for my convenience did not bother to remove it.. coz it wont harm anyone
 Milz like this.
Mon Dec 24 2007, 07:51 am
#15
Ajay rocks ! hehe

Yest it starts with mouse mode initially.. and toggles it after pressing power key. when power key is pressed controller send 0 and then software replies back with mode.. if software send 'm' that means its in mouse mode.. so mode bit is toggled and controller switches to keyboard mode.


ok might sound stupid, but i had no idea vb sends back to the controller .. ! :-|
from the few things i understood from the 8051 code, i didnt see any rx routine!
.. or i didnt get you ... that's an option too


Mon Dec 24 2007, 11:24 am
#16
check in the Timer1_timer sub

Case &H30
If Mode Then
    MSComm1.Output = Chr(Asc("m"))
    Mode = False
            
    StatusLog.SelText = vbCrLf & "0 Received, Mouse Mode"
        
Else
    MSComm1.Output = Chr(Asc("x"))
    Mode = True
            
    StatusLog.SelText = vbCrLf & "0 Received, Keyboard Mode"
End If


after checking the Mode variable.. i send 'x' or 'm'. this is how it work..
Tue Dec 25 2007, 11:44 pm
#17
keyboard:				;Routine for Keyboard operation
	mov a,TEMP
	cjne a,CMD,k_valid1
	ret


As soon as you enter keyboard mode, you're checking if the command is the same as the previous command and if they are you're disregarding the command ... Ok but what if the user presses two 'Next' button twice in a row, but with an acceptable delay between the two .. will the program disregard the 2nd click ?
Wed Dec 26 2007, 12:48 am
#18
it will accept.. i know your confusion.. because even i was confused when i coded it.. and believe me it works.. maybe the data reception is way too fast..
also sometimes.. you get error in sending commands.. reason for error is.. after reception of first bit.. we give delay with a wild guess that next bit might come at this place.. even a small mistake will make big difference.. even if no data is coming.. sometimes a flicker in ambient light cause circuit to get activate. Try it in sun you will get to know.. it just one example of error... there are many other possibilities like the way you handle the remote.. direction and angle.. etc... I tested the whole thing with almost all possibilities.. well you will understand when you use it... or make it from scratch
Thu Jan 03 2008, 03:10 am
#19
Hello again Ajay! happy new year to every1..

Ok so im finally trying out my pic , and while trying as a first step to simply test the decoding part, where the pic should output the command bits on Port D through LEDS .. It did Not work.. But what really is blowing my mind, is that it works perfectly well when i tried the code on Proteus !

So im just wondering , what could be the problem , if it works on Proteus, but not on hardware?
P.S: When i click on my remote, it simply gives me random bits everytime... nothing close to the command i clicked on, even if i click the same button twice! :mad
Thu Jan 03 2008, 03:25 am
#20
PROTEUS?? how did u simulate there???
and.. there is surely delay problem.. the timings are not correct..
even thought the theoretical values say about the timings..
but.. in reality.. there is sometimes a lot of difference.. try to decrease the delay.. slowly.. till you get right bits.. only way to get it working is testing on hardware..
it took me 7 days for perfect decoding..

also.. once you finish with your code.. i will add ur PIC code in my library will be useful.. so test test test..

Get Social

Information

Powered by e107 Forum System

Downloads

Comments

Bobbyerilar
Thu Mar 28 2024, 08:08 am
pb58
Thu Mar 28 2024, 05:54 am
Clarazkafup
Thu Mar 28 2024, 02:24 am
Walterkic
Thu Mar 28 2024, 01:19 am
Davidusawn
Wed Mar 27 2024, 08:30 pm
Richardsop
Tue Mar 26 2024, 10:33 pm
Stevencog
Tue Mar 26 2024, 04:26 pm
Bernardwarge
Tue Mar 26 2024, 11:15 am