Maybe make the TC change with a script (if that is even the fix)?
I jumped the gun. https://github.com/MarlinFirmware/Marlin/pull/19545
That’s ok. It’s better to keep them atomic. So they can be addressed separately.
What about going into that file where TC is defined and adding a #ifdef <archims> to choose which freq to pick?
Oh, but what file is that? That looks like it is outside of Marlin…
Looks like maybe it is generated? buildroot/bin/generate version?
ooooooh…
IDK. This seems like it’s in a hard place for us to fix.
My understanding is that there is another repo that gets pulled in to make the archim cpu look like arduino compatible code. I think this frequency number is in there. I think the variant stuff is making a special case only for archim boards, and only for platformio builds, and a lot of that code might be copied from that other repo.
I don’t see TC_FREQUENCY anywhere in the Marlin repo at all. I think that is something specific for this CPU.
It is also set to 100000, not 31000 in the PR you sent me.
Is this where it is supposed to come from? Or is this just the arduino version?
This is the repo that I put that issue up on about the PWM pins (that hasn’t been answered).
There aren’t that many variants in Marlin:
I think this might just be a plain ol’ new one, built from the files in the archim add ons. That PR might still be the right thing to add, even though it is old.
How can I test it?
Do I pull/fork/branch) it, update to the current bugfix (including the $source fix), and try to flash?
The last file in that link is what worries me. It has the old way of adding the windows fix, I think I can undo that part though.
You don’t want to fork it, because you already have a Marlin that is forked from the main Marlin.
I would probably just clone that repo and then add MarlinFirmware as a new remote. Check out the MarlinFirmware bugfix-2.0 or 2.0.6.1 and then try to cherry-pick the commits in that PR. That all sounds pretty hard though, so at a moment’s notice, I would drop back to just copying the files into a clean repo. 
.
1 Like
Functionally, you want to test the latest bugfix, with those files in it. Then, if that’s better, you want to make a PR with a branch that is based off of bugfix-2.0 and includes those changes. Ideally, that would be in the ultimachine repo, so they could manage the PR. But if they aren’t cooperating, then you should just make your own branch, add the files, and submit the PR. Check the licenses and make sure you aren’t taking anything that doesn’t say you can.
I must be learning, I was looking up cherry picking…
1 Like
Oh…and I think I did it. Dam I feel like a code samurai right now…you are a full on Jedi. Enough patting myself on the back, I will try to test it now.
1 Like
Oh dang!
Cherry picked the two commits to a fresh bugfix, removed the extra archim ENV list, branched it to make a archim config, dropped the bootscreen and configs in and it is flashing…verifying…and the steppers still do not work.
Shoot. So maybe that TC part is not the fix.
Just need figure out how to get it online…
Do you need to enable that variant somehow? Like set the board type to something different, like archim instead of due?
You might try putting in an obvious error, like:
#error this is being compiled
Yup.
I don’t have the platformio.ini correct. Poop
Current, not working, new version
Archim SAM
[common_DUE_archim]
platform = atmelsam
extends = env:DUE
build_flags = ${common.build_flags}
-DARDUINO_SAM_ARCHIM -DARDUINO_ARCH_SAM -D__SAM3X8E__ -DUSBCON
board_build.variants_dir = buildroot/share/PlatformIO/variants/archim
extra_scripts = ${common.extra_scripts}
Marlin/src/HAL/DUE/upload_extra_script.py
[env:DUE_archim]
platform = ${common_DUE_archim.platform}
extends = common_DUE_archim
What he had,
I tried without the archim directory as well
What if you used board = archim?
The board_build.variants_dir also seems like a smart thing to add.