Weil ich schon gerade dabei war, hab ich mich mit dem Thema auch mal wieder beschäftigt, und musste leider feststellen, daß der Fehler in den aktuellen Sourcen auf github immer noch besteht. Interessanterweise musste ich jetzt aber an einer anderen Stelle den Timeout fixen:
- --- a/opencbm/sys/linux/cbm_module.c
- +++ b/opencbm/sys/linux/cbm_module.c
- RELEASE(ATN_OUT);
-
- RELEASE(CLK_OUT);
- - for (i = 0; (i < 100) && !GET(CLK_IN); i++)
- + i = 100;
- + do {
- udelay(10);
- + i--;
- + } while (i && !GET(CLK_IN));
- if (!GET(CLK_IN)) {
- printk("cbm_write: device not present after talk\n");
- rv = -ENODEV;
Display More
Ok, inzwischen hab ich auch einen anderen PC, mag auch damit zusammenhängen, aber man sollte wohl überall einen Timeout einbauen, wo unmittelbar nach einem RELEASE auf selbige Leitung geprüft wird, sonst kann es wohl passieren, daß man auf seine eigene Flanke triggert.
Aber wo ich noch ein Verständnisproblem habe, ist in der RESET-Routine:
- do {
- RELEASE(ATN_OUT | CLK_OUT | DATA_OUT | RESET);
- /* wait for the drive to have time to react */
- timeout_us(100);
- /* assert ATN */
- SET(ATN_OUT);
- /* now, wait for the drive to have time to react */
- timeout_us(100);
- /* if DATA is still unset, we have a problem. */
- if (!GET(DATA_IN))
- break;
- /* ok, at least one drive reacted. Now, test releasing ATN: */
- RELEASE(ATN_OUT);
- timeout_us(100);
- if (!GET(DATA_IN))
- ret = 1;
- } while (0);
Display More
Hier wird ATN gesetzt, und anschließend gewartet, bis DATA aktiv wird. Das passiert bei mir aber nicht, und das ist auch gar nicht spezifiziert, denn da müsste auch noch CLOCK gesetzt werden, damit der Partner mit DATA antwortet. Daher verstehe ich nicht, was man sich dabei gedacht hat...