Closed seebq closed 1 year ago
No, not yet, how best to do that? Manually? on a linux boxen? README looks like I could.
Will do that next.
p.s. this is a public repo, so let's remove references to hostnames for Greenzie (even though that one is internal sans DNS).
On Tue, May 23, 2023 at 5:46 PM Kristian Kabbabe @.***> wrote:
@.**** commented on this pull request.
Curiosity, have you build this debian and install it on GZDEV9?
— Reply to this email directly, view it on GitHub https://github.com/Greenzie/emuccan-b202/pull/8#pullrequestreview-1440610809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAABXCUB3G43JAHD7YA6EDXHUV2BANCNFSM6AAAAAAYMPER5E . You are receiving this because you authored the thread.Message ID: @.***>
Yes, you can follow the README, it should still be accurate
Tested, installs cleanly and overrides udev and service.
CC: @mfsurvilo
Public repo so being intentionally vague here, but last steps to merge:
I am noticing we still have some print statements to fix as well: https://github.com/Greenzie/emuccan-b202/blob/f5da6f58eb39ccb2bf5ed9e863deb9ab27e07dd5/utility/main.c#L567 just to keep consistent
Sorry y'all, one more commit to update the start script and stop scripts with what Innodesk recommends. I don't like it one bit, using modprobe and rmmod inside a service file (scary!) but it's not only what their start and stop scripts do, but also it works. Tested with @edavies64 and we can now start and stop emuccan.service with this and CAN traffic resumes cleanly. Before, we could never get it to stop and start.
Now we can build a recovery behavior if canbus traffic fails, or if we get that dreaded:
kernel: emuc : bump : parse fail -1.
We can now stop and restart the emuccan.service.
I am noticing we still have some print statements to fix as well:
just to keep consistent
That's not our code.
@edavies64 also wants to upgrade this to latest we built this from, this is all their boilerplate.
I would rewrite a LOT of it if that's the case.
I am noticing we still have some print statements to fix as well: https://github.com/Greenzie/emuccan-b202/blob/f5da6f58eb39ccb2bf5ed9e863deb9ab27e07dd5/utility/main.c#L567
just to keep consistent
That's not our code.
@edavies64 also wants to upgrade this to latest we built this from, this is all their boilerplate.
I would rewrite a LOT of it if that's the case.
Talking with @seebq we're going to push on updating the driver to a later date.
Because we were using /dev/ttyACM9 if you unplug and replug in enough tty devices, they eventually take that device name. It's reserved and the symlink apparently gets overridden or linux doesn't like you using that device name.
Just ask @AGummyBear how many times he had to manually unplug/replug devices (luckily he has per port power USB control and was able to do it via software).
Sadly, the software still requires one of these reserved names instead of a fancy unique udev name or by serial or some other more modern approach.
I tested this briefly by hardcoding the change in the udev rule on a machine and the emucd_64 binary worked:
This should minor version bump.
Would like to test installing this manual deb on a machine to make sure that it updates the udev rule appropriately.
I'm nervous the Debian installation won't allow overwriting this config file.