{"action":"opened","issue":{"url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/121","labels_url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/121/labels{/name}","comments_url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/121/comments","events_url":"https://api.github.com/repos/Traumflug/Teacup_Firmware/issues/121/events","html_url":"https://github.com/Traumflug/Teacup_Firmware/issues/121","id":59359757,"number":121,"title":"Reliability of the clock interrupt, especially dda_clock()","user":{"login":"Traumflug","id":318581,"avatar_url":"https://avatars.githubusercontent.com/u/318581?v=3","gravatar_id":"","url":"https://api.github.com/users/Traumflug","html_url":"https://github.com/Traumflug","followers_url":"https://api.github.com/users/Traumflug/followers","following_url":"https://api.github.com/users/Traumflug/following{/other_user}","gists_url":"https://api.github.com/users/Traumflug/gists{/gist_id}","starred_url":"https://api.github.com/users/Traumflug/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Traumflug/subscriptions","organizations_url":"https://api.github.com/users/Traumflug/orgs","repos_url":"https://api.github.com/users/Traumflug/repos","events_url":"https://api.github.com/users/Traumflug/events{/privacy}","received_events_url":"https://api.github.com/users/Traumflug/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-02-28T21:42:33Z","updated_at":"2015-02-28T21:42:33Z","closed_at":null,"body":"@NickE37 brought it up in https://github.com/Traumflug/Teacup_Firmware/issues/117#issuecomment-76409732 , dda_clock() apparently isn't as reliable as it should be. To investigate this I've pushed some code to the interruptreliability branch. The idea is to make a copy of the movement duration, then to count this backwards in dda_clock(). This counter should be zero at movement end, else dda_clock() calls got lost.\r\n\r\nFirst tests with ACCELERATION_TEMPORAL, without Delta, aren't that promising. The following is a transscript from real hardware, ATmega1284P @ 16 MHz:\r\n\r\n```\r\nstart\r\nok\r\n2 milliseconds = 32000 CPU clocks.\r\n\r\nX10 F200\r\nok\r\ninterval 3750\r\nexact 48000000  duration 48000000\r\n = 3000 ms / 3000 ms\r\nexact 128000  duration 128000\r\n = 8 ms / 8 ms\r\n\r\nX20 F400\r\nok\r\ninterval 1875\r\nexact 24000000  duration 24000000\r\n = 1500 ms / 1500 ms\r\nexact 96000  duration 96000\r\n = 6 ms / 6 ms\r\n\r\nX30 F600\r\nok\r\ninterval 1250\r\nexact 16000000  duration 16000000\r\n = 1000 ms / 1000 ms\r\nexact 96000  duration 96000\r\n = 6 ms / 6 ms\r\n\r\nX50 F800\r\nok\r\ninterval 937\r\nexact 24000000  duration 23987200\r\n = 1500 ms / 1499 ms\r\nexact 32000  duration 19200\r\n = 2 ms / 1 ms\r\n\r\nX100 F1000\r\nok\r\ninterval 750\r\nexact 48000000  duration 48000000\r\n = 3000 ms / 3000 ms\r\nexact 224000  duration 224000\r\n = 14 ms / 14 ms\r\n\r\nX0\r\nok\r\ninterval 750\r\nexact 96000000  duration 96000000\r\n = 6000 ms / 6000 ms\r\nexact 448000  duration 448000\r\n = 28 ms / 28 ms\r\n\r\nX90\r\nok\r\ninterval 750\r\nexact 86400000  duration 86400000\r\n = 5400 ms / 5400 ms\r\nexact 384000  duration 384000\r\n = 24 ms / 24 ms\r\n\r\nX0\r\nok\r\ninterval 750\r\nexact 86400000  duration 86400000\r\n = 5400 ms / 5400 ms\r\nexact 512000  duration 512000\r\n = 32 ms / 32 ms\r\n\r\nX100 F1100\r\nok \r\ninterval 681\r\nexact 87200000  duration 87168000\r\n = 5450 ms / 5448 ms\r\nexact -4032000  duration -4064000\r\n = -252 ms / -254 ms\r\n```\r\nAs one can see, we have non-neglibile errors at a boring 200 mm/min already. Having 1280 steps/mm, that's 4266 steps/s or 3750 CPU clocks per step. Things don't get worse up to 1000 CPU clocks/step. At 750 clocks/step ( = 21'000 steps/s) noticeable errors appear, 680 CPU clocks/step are not good."}}