Teacup_Firmware
Teacup_Firmware copied to clipboard
Traumflug
Log of general stuff
This isn't an issue, more a blackboard to announce general achievements and changes.
As there are apparently no longer blocking issues with the experimental branch, I've picked almost all of it over to the master branch. Let take everybody advantage of look-ahead :-)
After doing so I rebased most of the other branches to branch closer to the top. When pulling you should receive a lot of updates, but identical code at the end of each branch.
Today former experimental was cherry-picked entirely over to master and experimental received different kinematics support, CoreXY support and a few loop-ups in dda_lookahead.c.
Perhaps you've seen it, I've created a milestone for Configtool: https://github.com/Traumflug/Teacup_Firmware/milestones/Configtool%20out%20to%20the%20public
Also opened quite a number of issues connected to this. Most of these issues are an easy fix, still it has to be done. Newbies have an entirely different reception and a little showstopper, which we know to work around in seconds, blasts them entirely away. I guess I have some insight, from these "help me, it doesn't work"-Emails I get occasionally.
You're welcome to pick one or another of them, of course. The earlier we catch this milestone, the better. Easier to use => more users => more developers => more bug fixes => {"works for me" => "works for me much better than before"} => better prints for you.
Thanks for putting these issues all together. I didn't even know the concept of a milestone existed here. I'll start picking these off. The one where perhaps I have the most questions is the one about thermistor presets. Like the example in your issue statement, I'm one of those users who only know about the EPCOS 100K. If you (or anyone else) can give me profiles of typical thermistors, I'd appreciate it. Of course my aim is to make this list easily modifiable - perhaps load it in fro the ini file - so all I'm really looking for is a starting point.
Before I forget it: please make at least one commit per issue. Thanks :-)
I was wondering if you were going to make that request.
I've been working at this all day and have many of them done. I understand you want to review each before accepting, so we should make them straight-forward, but so I don't have to pull my code apart again, let me suggest the following compromise.
There are some trivial changes - auto load config.h, remove analog ref and debug from the screens/header files, eliminate successful dialogs, and use absolute paths for file names. I propose delivering these as a single commit. Even the bootloader baud rate is a simple fix, but it's islated enough that I can make it separate.
For thermistor presets and properly validating the sensor dialog, I would like to combine these.
The others I am ok with making separate commits.
A question here - many of these commits are touching the same files. If two issues change the same file, then the first commit is simple - you just get the changes. But for the second issue, are you expecting the file to again be based off of the experimental branch or can it be based on the previous commit. I'm hoping the latter, but that also implies an ordering to how these should be incorporated.
Apparently you have an interesting workflow :-) Something like "fix five things at once"? Perhaps we differ here a bit, I do only one thing and test this before I even start thinking about the next, so doing a git commit in between is simple. Actually I do so before testing to allow doing and reverting diagnostic changes for testing. There's git commit --amend for fixing these ineviteable typos without making another commit.
Another reason for these separate commits is better bisecting in case of regressions. The smaller a commit, the easier a bug can be pinned down. Third reason is conserving knowledge. If there's a commit just adding a checkbox and nothing else, it's easy to re-do such an operation for yet another checkbox in a year or so. Or to remove it when it became obsolete.
Anyways. Your compromise sounds good. The last thing I want is to distract you from the workflow you're comfortable with.
many of these commits are touching the same files. If two issues change the same file, then the first commit is simple - you just get the changes. But for the second issue, are you expecting the file to again be based off of the experimental branch or can it be based on the previous commit.
Previous commit is entirely fine. Even better, because else you easily run into conflicts, if changes not only touch the same file, but also the same area of that file. And often things simply depend on each other.
I just moved the eeconfig branch to the attic (attic/eeconfig/). Now that Configtool works fine it becomes even more unlikely this ever becomes part of the standard distribution.
In case somebody disagrees, please create this branch again, make it working on current experimental and also sure this stuff is properly wrapped in #ifdefs. Then there's no reason to not deploy it for those who prefer runtime calibration with M-codes over Configtool.
Removed the branch newdda entirely. This was an attempt to execute steps very early in dda_step(), then to allow nested interrupts. These nested interrupts were always a source of trouble.
There was also code to check endstops during normal moves. This is pretty much implemented now in dda_clock() and used for homing, just a configuration flag to do so during normal moves is missing.
All together, there were so many changes to movement code since this branch was created, there's nothing left which could be applied to todays code.
Big collection today:
- Forwarded master to what was experimental
- Picked all commits of sdcard (bufferless, faster reading) onto experimental.
- Same for branch configtoolupdate2 (updating new options to user-saved configs in Configtool).
- Removed the branch configtoolupdate.
- Picked most from the issue-104 branch and rebased this branch to experimental.
Doing the latter I realised too late that the commits on the diverged experimental branch were a bit different from these on the sdcard branch. So these differences ended up as extra commits. Sorry for this, I'm simply not used to others doing work in this area and obviously missed the notification for these changes. Will do better next time.
Forwarded master to experimental of yesterday again. ARM support is now on master.
@Traumflug thoughts on using labels to identify issues as Informational, Question, Documentation or Bug or Feature request etc?
I'd be happy to do it :+1:
Forwarded master to experimental of today.
Huge space improvements:
| config | Program | Data |
|---|---|---|
| config.regtest-gen7-avr.h | -2534 | -161 |
| config.regtest-ramps.h | -2618 | -161 |
| config.regtest-nanoheart.h | -1274 | -163 |
| config.regtest-teensy2.h | -2764 | -161 |
| config.regtest-gen3.h | -2886 | -157 |
| config.h.Profiling | -2284 | -323 |
| config.regtest-display.h | -2672 | -161 |
| config.regtest-acceleration-reprap.h | -3150 | -25 |
| config.regtest-acceleration-temporal.h | -3446 | -33 |
| config.regtest-gen7-arm.h | -296 | -158 |
| config.regtest-no-endstops.h | -2614 | -161 |
Performance improvement:
Master:
smooth-curves.gcode statistics:
LED on occurences: 22589.
LED on time minimum: 308 clock cycles.
LED on time maximum: 738 clock cycles.
LED on time average: 354.088 clock cycles.
Experimental:
smooth-curves.gcode statistics:
LED on occurences: 22589.
LED on time minimum: 217 clock cycles.
LED on time maximum: 537 clock cycles.
LED on time average: 284.746 clock cycles.
