Show all posts by user
Page 1 of 1 Pages: 1
Results 1 — 9 of 9
I've pushed few things for now. Main core is working, parser and core routines works too, i've tested it on real hardware, looks great now. Overall code layout looks more or less what i want to achieve. What it broken is steppers, dda, and a lot of other code is not tested on hardware. I'm still fighting with dda, because of bunch of optimizations some of calculations done in steps, some in um, s
by
x86_64
-
Firmware - experimental, borrowed, and future
Triffid_Hunter Wrote:
-------------------------------------------------------
> it already was a state machine
And now it looks like it too.
Traumflug Wrote:
-------------------------------------------------------
> When can I start to cherry-pick the first few of
> your enhancements?
Well, bad news is that because of gcode processing reconstruction some code is in other files, so
by
x86_64
-
Firmware - experimental, borrowed, and future
I'm rewriting dda for now, code is very tight and weird in some places. Also rewrote gcode parser into state machine with saving about 1kbytes of code. Moving very slowly unfortunatly.
by
x86_64
-
Firmware - experimental, borrowed, and future
Didn't find such functionality in soupcup, maybe looked in wrong direction. Anyway, i've wrote software timers as i was intended to. It is here:
New functions for setting up timer and enable/disable. Looks like it works fine (attach), at least i've tested it on attiny2313 with 1Mhz default clock for now. If you have time to test out on other hardware and/or with different timer settings - this w
by
x86_64
-
Firmware - experimental, borrowed, and future
What if there would be only one hardware timer and code which makes from it software timers, like if i have a timer for 100ms and other for 150ms, i set up hardware to 100ms, wait for it, fire up first software callback, then set up hardware timer for 50ms, and wait for it. This will be a bit unaccurate if callback is taking a lot of time to complete, but worst what could happen is user will get
by
x86_64
-
Firmware - experimental, borrowed, and future
Yeah, i'm sorry about deleted code, i'll restore it anyway - i've started to comment out it with FIXIT mark. Shuffling code i think is nesessary because for example max6675 sensor's code i found in several different places, which make this almost impossible to maintain or make changes. As for steppers, mostly my task at least is to split out code for extruder, to make them run independtly with se
by
x86_64
-
Firmware - experimental, borrowed, and future
Well, some of those things just commented out, i thought of moving it to other files. I know that this looks broken in most places, but i'll hopefully fix everything then overall structure will be defined and work correctly.
As for synchronization - if i send gcode in same time (almost, few cpu ticks later) to all modules, and every module do their job correctly - i think this would be pretty syn
by
x86_64
-
Firmware - experimental, borrowed, and future
Hi everyone!
I've been rewriting code for teacup for last few days. Basically i want to separate all modules in different files to make them work without weird ifdef constructions. Also to try clean up code, because it is too tight and depend on each other. As i see this project - there should be gcode parser alone and support for callback functions, there i can catch any gcode and do anything i
by
x86_64
-
Firmware - experimental, borrowed, and future