Update 'libsharperang/usb.cs'

This commit is contained in:
Maff 2019-09-10 09:39:05 +00:00
parent 6d5e65bbfa
commit 8cecb35315
1 changed files with 0 additions and 45 deletions

View File

@ -6,43 +6,6 @@ using LibUsbDotNet.Main;
/*
* the official software seems to transmit a CRC "token" on first detecting the printer (Paperang P1; MiaoMiaoJi):
* Frame.Begin, PrinterCmd.TransmitCrc, 0x4d0dc477, 0x699295ed, Frame.End
* This differs when connected to a Paperang P2:
* Frame.Begin, PrinterCmd.TransmitCrc, 0x18d2a3df, 0x4ec92265, Frame.End
*
* It's not immediately clear to me whether the segment normally containing the CRC is itself a CRC of the token
* or if the token is simply 8 bytes rather than 4 and the CRC segment of the frame is omitted for this operation
*
* From what I can tell, calculation of a CRC32 checksum can involve a polynomial and a 'check' value.
* It may thus be possible that the Data value is the 'check' value, and the CRC value is the polynomial..
* In ihciah/miaomiaoji:message_process:crc32(data), the CRC32 value is generated by the zlib.crc32(d,v) function
* however I've been unable to reproduce a checksum of 0x906f4576 from a starting value of 0x00 and a polynomial
* of any variation of 0x4d0dc477, 0x699295ed
* Disassembly of the official software indicates it -is- crc32 that's in use, however further investigation is needed
* Finally, it's not clear whether this value transmitted is required to remain the same at all times
* or if the software may use whatever value it wants (whether this is simply a handshake, or whether the specific
* value "unlocks" communication with the printer
*
* standard presence checks performed by the official software consist of simply sending two messages every two seconds:
* Frame.Begin, PrinterCmd.SessionStart, 0x0000, 0x906f4576, Frame.End
* Frame.Begin, PrinterCmd.SessionEnd, 0x00, 0x906f4576, Frame.End
*
* printing out a blank page yields a 1018-byte payload formed of:
* Frame.Begin, PrinterCmd.BeginPrint, 0x00*1008, 0x83c0e20f, Frame.End
* followed by a 634-byte payload formed of:
* Frame.Begin, PrinterCmd.ContinuePrint, 0x00*624, 0xbc1b6bf4, Frame.End
* followed by a 12-byte payload formed of:
* Frame.Begin, PrinterCmd.SessionEnd, 0x2c01, 0xa8347338, Frame.end
*
* printing out a single dash ('-') yields a 1018-byte payload formed of:
* Frame.Begin, PrinterCmd.BeginPrint, 0x00*858, 0x0fe0, 0x00*46, 0xfe0, 0x00*94, 0xc53ad770, Frame.End
* followed by a 634-byte payload formed of:
* Frame.Begin, PrinterCmd.ContinuePrint, 0x00*624, 0xbc1b6bf4, Frame.End
* followed by a 12-byte payload formed of:
* Frame.Begin, PrinterCmd.SessionEnd, 0x2c01, 0xa8347338, Frame.end
*
* based on the above we can extrapolate that:
* - 12 bytes is the minimum size of a payload, and 1018 bytes is the maximum
* - all frames sent to the printer follow the structure of:
* -- Frame.Begin (1 byte)
@ -50,13 +13,6 @@ using LibUsbDotNet.Main;
* -- Data (min. 2 bytes? max. 1008 bytes)
* -- CRC32 sum of the Data block (4 bytes)
* -- Frame.End (1 byte)
*
* Also of interest is that, when a model P2 is connected, the printer will actually reply to messages
* eg., for the standard presence check of Frame.Begin, 0x1a000200, 0x0000, CRC, Frame.End
* the printer will reply with an almost identical message:
* Frame.Begin, 0x1a000100, 0x00, CRC, Frame.End
* The Data segment is a different size (one byte) and the printer appears to be doing its own CRC calculation
* Finally, the command, 0x1a000100, appears to be an acknowledgement of sorts in response to PrinterCmd.SessionEnd (byte 3 changing from 0x02 to 0x01)
*/
namespace libsharperang {
@ -75,7 +31,6 @@ namespace libsharperang {
private byte[] ResolveOpcode(Opcode opcode) {
switch (opcode) {
case Opcode.SessionBegin: return new byte[] { 0x06, 0x00, 0x02, 0x00 };
case Opcode.SessionEnd: return new byte[] { 0x1a, 0x00, 0x02, 0x00 };
case Opcode.CrcTransmit: return new byte[] { 0x18, 0x01, 0x04, 0x00 };
default: throw new NullReferenceException();
}