CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

IGT SAS (Slot Accounting System) protocol
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
PCM programmer



Joined: 06 Sep 2003
Posts: 21675

View user's profile Send private message

PostPosted: Sun Mar 27, 2022 1:25 am     Reply with quote

PrinceNai wrote:
#INT_RDA
void RDA_isr(void)
{
Tmp=getc();
fputc(Tmp, PORT1);
set_timer0(0);
RX_Idle_Timer = 0;
}

For consistency, the line in bold above should really be:
Code:
Tmp=fgetc(PORT1);

When you only have one stream defined, CCS defaults to
using it when you type getc or putc, but it's best to be consistent.


PrinceNai wrote:
port_b_pullups (TRUE);

For the 18F46K22, the datasheet says:
Quote:
10.3.1 WEAK PULL-UPS
Each of the PORTB pins has an individually
controlled weak internal pull-up.

This means you should use 0x01 to enable pull-ups on Pin B0:
Code:

port_b_pullups (0x01);
delay_us(10);  // Allow time for pull-ups to fully pull up

To turn all of them on, you would use 0xFF as the parameter.
Also, for safety, I've added a short delay after pull-ups are enabled.
These are weak pull-ups and need time to fully pull up.
PrinceNai



Joined: 31 Oct 2016
Posts: 359
Location: Montenegro

View user's profile Send private message

PostPosted: Sun Mar 27, 2022 2:33 am     Reply with quote

Thanks, noted. What is the point of defining a stream and later let yourself at a mercy of a compiler? For a pull-up, if this ever comes to life, there will be a real resistor on the board.
I've already edited the code above as suggested.
PrinceNai



Joined: 31 Oct 2016
Posts: 359
Location: Montenegro

View user's profile Send private message

PostPosted: Sat Aug 13, 2022 9:24 pm     Reply with quote

Almost half a year later :-).

I finally got around to write a code that after a week or so testing and tweaking does well all it needs to do regarding various timings and actions connected with card insertions and removals. It is no nuclear physics, but it took some time to cover all the possibilities of how it is done in real life and where it could go wrong. I am aware of the Murphy's law, though. Another one or ten possibilities will pop up when real (ab)users get their hands on it :-).

Now to the problem. The protocol specification says:

Quote:

Communication between the host and gaming machines occurs through a serial data link operating at
19.2 KBaud in a "wakeup" mode. The 11-bit data packet consists of one start bit, eight data bits, a
ninth ‘wakeup’ bit, and one stop bit.

Wakeup Mode

In wakeup mode, the host sets the 9th (wakeup) bit each time it sends the first byte of a
message to the gaming machine. For all additional bytes in the message, this bit is cleared.
Gaming machines use the wakeup bit to determine whether the received byte is the first byte of
a new message or an additional byte of the current message.
Gaming machines clear the wakeup bit for all bytes when responding to the host, except when
reporting a loop break condition.


My dummy code right now in RS232 interrupt is simply this:
Code:

   Tmp=fgetc(FROM_HOST_TO_SLOT);                // get received char from HOST and with that also clear interrupt flag               
   fputc(Tmp, FROM_HOST_TO_SLOT);               // send the received character forward to SLOT from Tx immediatelly 


How can I implement hardware 9bit reading on RX and transferring and injecting 9bit to TX?

Regards,
Samo
Ttelmah



Joined: 11 Mar 2010
Posts: 18233

View user's profile Send private message

PostPosted: Sun Aug 14, 2022 12:58 am     Reply with quote

Fortunately, the PIC you are using supports 9bit serial (a lot don't).

Set bits=9 in your #USE_RS232, and 'LONG_DATA'.

This now means the getc/putc will accept a int16, instead of an int8.
All you then do is for the character that needs the 9th bit set, use:

fputc(Tmp | 0b100000000L, YOUR_PORT);

This makes the code write a 16bit value with bit 9 set.

By default just sending an 8bit value will result in the 9th bit not being
set.
PrinceNai



Joined: 31 Oct 2016
Posts: 359
Location: Montenegro

View user's profile Send private message

PostPosted: Sun Aug 14, 2022 12:29 pm     Reply with quote

Thanks,

works perfectly.
Ttelmah



Joined: 11 Mar 2010
Posts: 18233

View user's profile Send private message

PostPosted: Sun Aug 14, 2022 11:29 pm     Reply with quote

Great. Very Happy

Another 'step forwards'.
PrinceNai



Joined: 31 Oct 2016
Posts: 359
Location: Montenegro

View user's profile Send private message

PostPosted: Thu Sep 22, 2022 10:05 am     Reply with quote

It was a nice and sunny day here in Montenegro. Twice as nice because I finally cracked the protocol and actually managed to lock and unlock the slot :-). All the logic of when and why was working fine on my desk before, I just haven't been able to produce the right signal to actually do that live. With a lot of help from another topic regarding 9 bit transfer I saw where I was wrong. The first mistake was a wrong CRC. Protocol wants Kermit and CCS example does Xmodem (but the brains behind the protocol don't advertise that, just CCITT and polynome). The second mistake was, and that one was mine alone, that it is clearly written in the specification that binary data goes out LSB first. I was sending a wrong CRC MSB first. Anyway, success.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group