Personally I prefer:
servo3 equ 0
and in the code:
PORTC, servo3

rather than:
#define servo3 PORTC, 0
and in the code:
servo3

OK!

purely because if you hover the mouse over the first one you can tell what it is, but if you use the second version the IDE won't tell you so you have to scroll back up to check the define section.

I don't really get your point...but I think I see a little bit what you mean...will fix that too!

Also should all the SFRs be in capitals?
The external clock should be in the config word, check that section of the datasheet or possibly the 16F877.inc file.

Will fix the SFRs to capitals...the datasheet I attached does not talk about the clock...Ok then if you say it is set in the config word...


thanks!

 

Anyone with a little algorithm for the scanning routine...I have a little idea but its Not complete!

All I have in mind right now goes like this:

- enable column1 then check the 8 rows. "and if there's a change compared to the initial position" then "send that change to PC."

repeat for remaing 7 rows...

I am still thinking how to translate the two lines in "" into good code taking into account the comms protocol I explained in some post back...

Will sleep on it and hopefully will come up with something good! but if anyone got a suggestion...cool...

Also how often each column is checked!? well...

 

You will need 8 bytes, one for each column, to store the old values, then XOR them with the port to see if there is a change. It is possible, and easy, to just send the entire state of the board to the PC when a change is detected.
Probably scanning the whole board as slow as four times per second would be fine, maybe 20ms per column.
Also it's best to read the port, then change the column transistor for the next read, as it may take the sensors some time to power up, so if you change the column and then immediately read, you might get invalid data.

 

You will need 8 bytes, one for each column, to store the old values, then XOR them with the port to see if there is a change. It is possible, and easy, to just send the entire state of the board to the PC when a change is detected.
Probably scanning the whole board as slow as four times per second would be fine, maybe 20ms per column.

The bold quoted line is a big problem!!! The comms protocol MUST be respected meaning only the change is sent to the PC and NOT the entire state...sending entire state means changing the comms protol which is impossible as Having the chess engine complete took if I am correct 40 days...I have shown the simulation and it cannot be changed due to complexity and especially the remaing TIME for this project!


Only 5 digit needs to be sent to the PC when a piece has changed its location! Also I think we only need to scan for pieces played by the human being!!! coz the chess engine already knows the location of its pieces...this also implies that the small magnet will be put ONLY for the pieces played by the human being! Please tell me if this paragraph makes sense!

Also it's best to read the port, then change the column transistor for the next read, as it may take the sensors some time to power up, so if you change the column and then immediately read, you might get invalid data.

Yes there should be some delay before reading to avoid false reading!

 

I only suggested it as a possibility, if you wanted to send as ascii text from the PIC, you could send 16 bytes where each pair of bytes was a hex value "00"-"FF" representing the sensors on a row or column.
I thought you had the source code of the chess engine and could make a change to the parts that send and receive commands easily enough.
Anyway it's probably not much harder to process the changes in the PIC and then send them to the PC in the standard format.
It' possible to put magnets in just one colour of pieces if the human will only play one colour. I think you mentioned that before.

 

As constraint...The human being will ONLY play with 'white' piece...and the comms protocol, the 1st digit distinguishes the type (white or black) piece moved...

This implies the 1st digit (out of the 5) to be sent to the PC will always be '2'...maybe later on when everything works the system can be enhanced whereby the human could choose either white or black...guess this way will make programming easier...making sense!?

Now my question is how to send '5 digits' to the PC!? (I have never used the UART, ...feature of PIC maybe that's why I have this question in mind)?

The worst case would be for instance sending '28887' to PC...? in the simulation (PC) I'll just type '28887' and click the 'send' button...

And how to do that in PIC? coz the 1st digit only needs '2bits' but the remaing 4 digit needs '4bits' each (taking worst case scenario)...and we only have 8-bit register to hold data!!

thanks!

 

@ Mark: you probably posted post #105 when I was typing...will read it now...

 

You may still need to put magnets in all the pieces so the board can "tell" if there is a piece at a certain location, so if one player is "taking" another players piece, the arm needs to know to move existing piece from the position being taken over by another piece. Plus, it will have to be used to verify that even a black piece was moved to the right location when PC takes its move.

 

as for the scanning.... the board should not have to scan all columns and all rows, just the column + row where a piece needs to be moved to or moved from, this will shorten required time to have to scan the whole board even if only one piece has moved. The only time you should have to scan the whole board is at the start of each game, just to verify all pieces are occupying their respective place to start.

 

.......
I thought you had the source code of the chess engine and could make a change to the parts that send and receive commands easily enough.
........

I have the source code! written in VB.Net and can make some change (adding functionality) BUT will do that ONLY if it a MUST!!! and will make thing easier...like when we'll discuss about the arm part of programing...

Just need to focus and finish up with the scanning part first then move on to the arm...

Still analysing the other posts...

Thanks y'all

 

You may still need to put magnets in all the pieces so the board can "tell" if there is a piece at a certain location, so if one player is "taking" another players piece, the arm needs to know to move existing piece from the position being taken over by another piece. Plus, it will have to be used to verify that even a black piece was moved to the right location when PC takes its move.

Well one thing for sure is that all pieces will have the metal thumb stack on top...for the arm to pick up/drop any pieces (capturing and castling...don't know much about chess) but as for scanning purposes I don't really see the point of scanning for the chess engine's pieces as well!!!

what I think is the human being's pieces need scanning in order to tell PC which of his pieces made a move...coz that's all the chess engine needs to know...well still thinking but I guess will implement this method first and like I said will enhance system later on...

thanks

 

as for the scanning.... the board should not have to scan all columns and all rows, just the column + row where a piece needs to be moved to or moved from, this will shorten required time to have to scan the whole board even if only one piece has moved. The only time you should have to scan the whole board is at the start of each game, just to verify all pieces are occupying their respective place to start.

Again, I never played chess before until I was given this project...I have tried playing a little bit with againt the computer to get the picture...
But I think the whole board needs scanning (Not only at start of each game) coz if I am correct one can sometimes move a piece to its initial position...well maybe I am wrong...

well will try to get some coding done and post as soon as I can...

 

Nope, you just need one bit to store the presence or absence of a piece, not one byte.
8 bytes total.

Lol... That was very stupid of me...got to remove that post...

 

So basically we gon have something like this:

rows_col1 = rows_col2 = rows_col3 = rows_col4 = rows_col5 = rows_col6 = rows_col7 = rows_col8 = b'00000011' (initial value) where 2 lsb = presence of pieces in row1 and 2. And rows_colX will be updated after each xor!

to be xored with PORTD = rowport, correct?

A quick question: when the sensor is activated/triggered by the magnet it outputs '1' or '0'!??

thanks

 

Pretty much, you will also need somewhere to store the location of the piece picked up and then wait for it to be put back down before sending the message.
The switches are active low.

 

Pretty much, you will also need somewhere to store the location of the piece picked up and then wait for it to be put back down before sending the message.

Yep! meaning other register to store current location of each piece --> 16 registers needed, correct? and they must have some initial values...

Now there should be some kind of mapping between the xor computation (mentioned earlier) and the location! then combine the start location with the end location prior sending...--> tracking based on initial position

The switches are active low.

Active low meaning when its triggered by the magnet it outputs a '0', correct?

 

I was thinking of having something like below to store location of each piece! example pieceXY = d'XY' where x and y represent the row (x-axis) and column (y-axis) location respectively! and pieceXY = piece located at row x and column y.

piece11 = d'11'
piece12 = d'12'
piece13 = d'13'
piece14 = d'14'
piece15 = d'15'
piece16 = d'16'
piece17 = d'17'
piece18 = d'18'

piece21 = d'21'
piece22 = d'22'
piece23 = d'23'
piece24 = d'24'
piece25 = d'25'
piece26 = d'26'
piece27 = d'27'
piece28 = d'28'

The above would be the initial positions. but what about the end-location!? do another 16 registers or we can just the ones above and play around with it!?

coz I think before sendind we need to concatenate '2' (white piece) with 'X1Y1' (start location) with 'X2Y2' (end location)

making any sense!?

 

Yep! meaning other register to store current location of each piece --> 16 registers needed, correct? and they must have some initial values...

I would think 2 (or possibly even 1) registers would work, you just have to store the X and Y location, eg 1,3 of the piece that has been lifted. This is the same as the message that the PIC should send to the PC.

Active low meaning when its triggered by the magnet it outputs a '0', correct?

Yes.

 

I would think 2 (or possibly even 1) registers would work, you just have to store the X and Y location, eg 1,3 of the piece that has been lifted. This is the same as the message that the PIC should send to the PC.

well I am thinking about this quote and my post #117...

do I have to store the 'Xs' and the 'Ys' in different registers or the way I suggested in post #117 (storing the x and y in same register) is ok!?


Also do I have to do this foe the end location as well?

example: a white pawn moves like this: A2 -> A3 -> A4 .

with this scenario we'll have: 2, (A2,A3) to be sent then 2, (A3,A4) to be sent! meaning after sending the message to the PC, the end location becomes the start location for the next message...

I am trying to get a clear picture of how this would work in its simple form...so I can post a code...

[edited] Like in the attachment how do you track a piece like the 'queen' for instance that moves in all direction!?

As we all know algorithm first and code second!

Thanks!

 

The structure in post 117 might be nice to have, but probably not required. I think you would only need one register to store the location of a piece that has been lifted by the human, eg. if the rook moved from D5 to H5, the scan would notice that D5 is no longer present and store 0x45 in the register and maybe set a flag to say that it is waiting for it to be put down, then the scan would notice a magnet at H5, then you send the ASCII string "24585".
Of course if the player slides the piece then all the sensors in between get activated, but you still want to send the same command to the computer, so you would have to store the initial absence, then set a timeout of maybe a couple of seconds and reset it every time a change has happened, of course waiting for the piece to be put back down if it has been lifted and moved.
Also if the computer takes a human piece, the PIC can't interpret that as the start of a human move, so if the computer move finishes on a human piece it should be treated specially.