I’m trying to drive a unipolar stepper motor and because there aren’t yet a loop support, I use two clocks, one for a counter that tick every 0.1 sec. and other for reset this counter but it doesn’t work. The counter never reset. Is ther a bug on XOD or I’m doing some thing wrong?
And… It’s normal that XOD use too many RAM of the PC and the atmega32 for a simple program like this?
…looks like we need to craft a standard node like xod/common-hardware/uln-unipolar-stepper.
I see that flip-flops could set, but they never reset (nothing at RST pin). Isn’t this is a problem? Didn’t try running it for myself, but if the problem is not in resets, I will.
BTW, there is a quick hack to monitor link values: use xod/core/console-log node connected to an output you’re interested in and open Serial Monitor in XOD IDE once you’d upload the program to your board.
About memory. There is a large room for relatively easy RAM optimization. AVR microcontrollers employ Harvard architecture which means they have different memory spaces for a program (flash, 32 KiB) and dynamic data (SRAM, 2 KiB). Many things that are immutable in XOD (like a program graph) are now put in the small data section although they may reside in the program section. Will do it in future releases.
Thank you, yes, this is the problem, I forgot that a XOD’s flip-flop is a flip-flop!
About stepper drivers, it isn’t better that you write a low level small and efficient group of booleans and other basics nodes and leave the task to build hardware specific big nodes to enthusiast users?
I’m still surprised that a little group of gates and flip-flops can fill 3/4 of all the atmega’s RAM.
Yes, I know, the oop, the c++ abstraction layer, etc…
In a near future XOD will be a powerful programming tool. Pro tem, I love to play this NSFW logic puzzle
A significant optimization was done in v0.13.0. There’s still room to lower RAM consumption, but right at this moment, the situation is much better than before.
…looks like we need to craft a standard node like 
