)]}'
{
  "commit": "821a085cb30897aae4103c2d19c5dab10daeecaa",
  "tree": "a8e858935021b4bd2a8bfb97800f0e1155775545",
  "parents": [
    "274e655e5cabb672845f1858aba4ed877b95d444"
  ],
  "author": {
    "name": "Nico Huber",
    "email": "nico.h@gmx.de",
    "time": "Sun Mar 24 13:34:51 2024 +0100"
  },
  "committer": {
    "name": "Nico Huber",
    "email": "nico.h@gmx.de",
    "time": "Mon Mar 25 21:54:06 2024 +0000"
  },
  "message": "dediprog: Implement id reading for SF600 and later\n\nFor the SF600, we simply use the more canonical read EEPROM command.\nNewer devices use a special command that allows to read the id over\nthe bulk endpoint.  The exact meaning of the magic command bytes is\nunknown at this time.\n\nReading from the bulk endpoint times out on about every other attempt\nto fetch the id, unless it\u0027s queried twice in a row. `dpcmd\u0027 comments\nthat this is necessary. And traces also show that the Windows applica-\ntion runs it twice too (even if not in a row).  Tests have shown that\na working read takes up to 5ms. So we lose 10ms tops, which seems ok.\n\nAnother observation when only querying the id once (or only repeating\nthe read when it failed) is that the bulk-in endpoint only keeps wor-\nking during the current flashprog run. Future runs fail unless the id\nis queried again.\n\nTested with \"SF600PG2. V:01.01.012 HW:01.00\", \"SF100   V:5.1.9\".\n\nChange-Id: I8056d936d41a24824c089e80d6dfed23ad5e0d1c\nSigned-off-by: Nico Huber \u003cnico.h@gmx.de\u003e\nReviewed-on: https://review.sourcearcade.org/c/flashprog/+/103\nReviewed-by: Arthur Heymans \u003carthur@aheymans.xyz\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5debf32db72d7069959b76fcd3a9aa7fdfb073de",
      "old_mode": 33188,
      "old_path": "dediprog.c",
      "new_id": "4d6df5c82a42c4e22a9bf4a66532b6eb4a6942aa",
      "new_mode": 33188,
      "new_path": "dediprog.c"
    }
  ]
}