Difference between revisions of "PoLabs PoScope Mega50"
Uwe Hermann (talk | contribs) m (Uwe Hermann moved page PoScopeMega50 to PoLabs PoScope Mega50 without leaving a redirect) |
Uwe Hermann (talk | contribs) |
||
| Line 1: | Line 1: | ||
... | |||
See [[PoLabs PoScope Mega50/Info]] for some more details (such as '''lsusb -v''' output) on the device. | |||
== Hardware == | |||
* ''Cypress'' CY7C68013A-56: USB Microcontroller | * ''Cypress'' CY7C68013A-56: USB Microcontroller | ||
| Line 9: | Line 11: | ||
* 4x ''Nexpia'': 74HC4052: Dual 4-channel analog multiplexer/demultiplexer (two per analog channel) | * 4x ''Nexpia'': 74HC4052: Dual 4-channel analog multiplexer/demultiplexer (two per analog channel) | ||
== Photos == | |||
Coming soon. | |||
Coming soon | |||
== | == Protocol == | ||
The main communication when setting it up/changing configuration always goes like this: | The main communication when setting it up/changing configuration always goes like this: | ||
Revision as of 17:22, 5 January 2020
...
See PoLabs PoScope Mega50/Info for some more details (such as lsusb -v output) on the device.
Hardware
- Cypress CY7C68013A-56: USB Microcontroller
- Analog Devices AD9288: 8-Bit Dual A/D Converter
- NXP LPC1111F: Cortex-M0 based microcontroller (For the output probably)
- NXP PCA9555: 16 I/O CMOS device
- 4x Nexpia: 74HC4052: Dual 4-channel analog multiplexer/demultiplexer (two per analog channel)
Photos
Coming soon.
Protocol
The main communication when setting it up/changing configuration always goes like this:
The host sends a "URB_BULK out" command where there are 64 bytes of data.
The device sends a packet with 4 times 0x00 as data
The host returns the same data but with an 0x00 instead of an 0x01 at byte 16
The device returns a "URB_BULK in" command with a lot of data in the 64 bytes of data.
The setup:
// In the following examples, I'm only talking about the 64 bytes of data, because (I think) everything else gets handled by the driver itself
//I'm making assumptions about what the commands do
Booting:
the host sends 0xa2 followed by 63 0x00
the host sends 0xa8 followed by 63 0x00
the host sends 0xa4 + 0x30 + 0x00 + 0x20 + 60 * 0x00
now, the host counts bytes 1 and 2 up in 0x20 steps, always 0xa4 at byte 0 like that:
this is probably to clean out old values
| byte 0 | 1 | 2 | 3 | 4-64 |
|---|---|---|---|---|
| 0xa4 + | 0x30 + | 0x20 + | 0x20 + | 60 * 0x00 |
| 0xa4 + | 0x30 + | 0x40 + | 0x20 + | 60 * 0x00 |
| 0xa4 + | 0x30 + | 0x60 + | 0x20 + | 60 * 0x00 |
| 0xa4 + | 0x30 + | 0x80 + | 0x20 + | 60 * 0x00 |
| 0xa4 + | 0x30 + | 0xa0 + | 0x20 + | 60 * 0x00 |
| 0xa4 + | 0x30 + | 0xc0 + | 0x20 + | 60 * 0x00 |
| 0xa4 + | 0x30 + | 0xe0 + | 0x20 + | 60 * 0x00 |
| 0xa4 + | 0x31 + | 0x00 + | 0x20 + | 60 * 0x00 |
| 0xa4 + | 0x31 + | 0x20 + | 0x20 + | 60 * 0x00 |
until byte 1 is 0x3f and byte 2 is 0xe0
then the host sends: 0xa4 + 0x40 + 0x00 + 0x00 + 60 * 0x00
Starting (setting modes and other stuff probably):
| 0xa5 + | 0x28 + | 0x01 + | 0x01 + | 0x00 + | 0x00 + | 58 * 0x00 | |
|---|---|---|---|---|---|---|---|
| 0xa6 + | 0x28 + | 0x07 + | 0x00 + | 0x00 + | 0x00 + | 58 * 0x00 | |
| 0xa5 + | 0x28 + | 0x01 + | 0x06 + | 0x00 + | 0x00 + | 58 * 0x00 | |
| 0xa5 + | 0x28 + | 0x01 + | 0x01 + | 0x00 + | 0x00 + | 58 * 0x00 | |
| 0xa6 + | 0x28 + | 0x07 + | 0x00 + | 0x00 + | 0x00 + | 58 * 0x00 | |
| 0x06 + | 0x00 + | 0x00 + | 0x00 + | 0x00 + | 0x00 + | 58 * 0x00 | maybe initializes mode change. always comes before b2 |
| 0xb2 + | 0x00 + | 0x00 + | 0x01 + | 0xe0 + | 0x14 + | 58 * 0x00 | b2 could set the mode. it repeats with other data when switching modes |
| 0x05 + | 0xc7 + | 0x00 + | 0x00 + | 0x00 + | 0x00 + | 58 * 0x00 |
after that you can ask for data with:
0ad5ffff000000000900000100ff00860300000000