Posts: 41
Threads: 9
Joined: Jan 2016
01-18-2016, 02:41 PM
Hi there,
I've been experimenting with writing some software to control SCP. Everything I've done so far works okay, apart from sending data from the on-board RAM to the USB port as I keep getting a pr_CommandErr return code.
Could someone please explain to me in more detail how to use this function?
Kind regards,
Francis
Posts: 2,853
Threads: 148
Joined: Nov 2013
Ok, so for your error:
pr_CommandErr = 0x02 ; command error (bad structure, etc.)
This means that you are not passing the correct data as a command.
Note the description of the command 0xA9:
Code:
(Command.b, Payload Length.b, RAM_Offset.l, TransferLength.l, Checksum.b)
0xA9 0x08 0x???????? 0x???????? 0x??
This command sends the data from on-board 512K static RAM to the USB port, using the offset
into RAM and the transfer length.
The payload data contains the RAM offset and the transfer length, both as longwords in big endian
format.
The RAM offset or transfer length can be an odd value. After all data has been transferred, a response packet is then returned
Note: Unlike all other functions, the response packet is sent after all of the data has been
received.
Typically, people forget that the RAM offset and transfer length are in BIG endian format. You should be able to send this hex string command to test the command:
0xA9 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0xFC
That will transfer 0x00000100 (256 bytes) of data from location 0x00000000 in the RAM to the USB port. Immediately after the 256 bytes of data will be 0xA9 0x4F as the response code.
Let me know if you have any issues!
Posts: 41
Threads: 9
Joined: Jan 2016
01-18-2016, 04:18 PM
(This post was last modified: 01-19-2016, 02:30 PM by dfstudios.)
Thanks for the quick reply. I was able to get your example working, but mine would still fail. It wasn't until I did a byte by byte debug output of the packets being sent I realised I had a typo for the payload buffer (meaning that there was no payload being sent)! Oops!
Working now though.
Kind regards,
Francis
Posts: 2,853
Threads: 148
Joined: Nov 2013
Good to hear you got it working. What are you working on?
Posts: 41
Threads: 9
Joined: Jan 2016
At the moment I'm just experimenting. I'm not sure yet how far I will take it.
Kind regards,
Francis
Posts: 2,853
Threads: 148
Joined: Nov 2013
There is example C code for comtrolling the SuperCard PRO and manipulating the image file format.
Posts: 41
Threads: 9
Joined: Jan 2016
I'm aware that there is some C code, but I'm not really a C programmer (I mostly use PureBasic) plus I prefer to try things by myself rather than looking at someone else's code (unless I
really have to). I find I learn better that way, by making my own mistakes!
Something I noticed while trying to copy data from the onboard RAM to USB is that there seems to be a 64K limit on the amount of data that can be sent in one go. Is this correct?
Kind regards,
Francis
Posts: 2,853
Threads: 148
Joined: Nov 2013
The limit is 512KB, because that is the amount of memory on the board.
Posts: 41
Threads: 9
Joined: Jan 2016
So I should be able to request and receive the 512k in one go? At the moment I am only able to receive it in 64k (i.e. exactly 65,536 bytes) chunks.
Kind regards,
Francis
Posts: 2,853
Threads: 148
Joined: Nov 2013
Yes, you get as many bytes sent as requested.
I looked at PureBasic, and it looks to be a bit slow from the serial port side at the max baud rate of 115,200 if you are not using hardware handshaking (which the FTDI driver supports). If you are using the USB COM port without handshaking, you probably need a baud rate of 500,000 or more. The buffer on the FTDI chip is 4K, but the buffer in the COM port is 64K.
I am not sure how you can open a .dll with PureBasic, but if that is possible you could use the transfer routines in the FTDXXX.dll instead of opening a COM port.