First off - I am very much in favour of your software and absolutely love the format of the application (with some exceptions). I have been waiting for over thirty years for a product like yours!
Anyway now the bad news - the reason for my post is, that in it’s present form, I will not be using XOD and I think it is only fair to give you guys feedback on the reasons why and some suggestions for the future.
You are too tied to the (cr**py) Arduino IDE and its software.
You force us to use the Arduino boards pin No. designations (probably because of point 1 above). This is restrictive for many users.
You are forcing me to use Arduino’s pre-built boards. Uno, Nano etc. I use individual chips (Atmel328P)
You have chosen a 0 to 1 numerical designation instead of the more usual 0 to 100(%) - Very very annoying and counter intuitive!!
A massive lack of information or proper exampls on how to use your software.
Its Is REALLY frustrating not to have Right Click functions on the mouse
Having to constantly search through the list of commands to find the one you want in the browser is frustrating and annoying to use -
We must have an inbuilt simulator. We should not have to ‘burn’ our code to see if it works.
You Website is poor and lacking information It has taken me multiple attempts with different user names to be able to post this.
The produced code seems to be massive
not having an auto line placement or just bad practice
Suggestions-
Design your own optimised compiler, which could be used for other microcontrollers, and is focused on an object event or an interrupt based system which would run quickly.
Because of Point 1 other microcontrollers could be programmed by just changing the compiler.
Give me the flexibility to use XOD as a microcontroller development system NOT a Arduino board development system.
Use the universal convention of 0 to 100 or 0% to 100% NOT 0, 0.25, 0.60 or 1. Conventionally 0 and 1’s are used for boolean operations.
Improve the user GUI and Mouse input options to streamline input actions. We need to be able to just drag a node from the browser to the main screen.
Design a way to contextually limit the vast number of entries in the Browser.
Allow the flexibility to use existing Arduino libraries and if possible convert them to XOD patches.
We need a simulator!
More contextual help for nodes within XOD
YOU need to post a LOT more tutorial videos to YouTube showing us how to use XOD.
We need good tutorials on how to make a ‘component’ which is not included in your library or and Arduino library. I have, say, a 1wire device I want to use with XOD how do I do it?
When we connect/link points together do so with either 90 or 45 deg bends. Allow us to drag the connections around and perhaps indicate jump over connection as necessary
Colour code the lines especially for inputs and outputs etc
Gives us the option to have ‘Favourites’ and / or ‘used nodes’ for our common selection helping us to quickly select frequent selections.
A search function or auto search as we type or similar is need in the Browser to help us find what we are looking for
A simpler naming convention is needed for the Browser items
Check out Flowcode. I paid about £60 for the basic package and another £60 for device pack add-ons.
I would love to use your software, I really would, but in it’s current form it’s a non starter for me.
I will revisit XOD in a few months.
Have you looked through the documentation that is available (starting with https://xod.io/docs/)? The beginning tutorials show that several of the items you are asking for already exist.
XOD is advertising itself as Alpha code; it has been available for less than year. The last couple releases that I have been around for have made significant changes. To my knowledge, nobody has paid a penny for it. It uses an object-oriented approach and is nothing at all like flowcode.
As for your specific suggestions:
“Design your own optimised compiler.” Judging from your statements, I have to assume you have never tried writing a compiler. It makes little sense to re-invent this wheel
“Support other microcontrollers ‘by just changing the compiler’.” A custom compiler would likely make porting to other hardware harder rather than easier.
“Provide support for other microcontrollers” This is in the plans, but it doesn’t make much sense to devote resources to this for alpha software that is still undergoing significant re-writes with only about 2 people doing 99% of the work in their spare time (a guesstimate based on responses I’ve seen in this forum).
“use 0-100, not 0-1”. Digital pins are 0 & 1; analog output is 0-255 & analog input is 0-1024 (at least on Arduino). Auto-mapping analog input to match analog output reduces the learning curve. Allowing graduation from full off (0) to full on (1) for analog makes logical sense. It was a design decision that seems reasonable, and I haven’t seen anything (at least in Arduino) approaching “universal convention of 0-100”.
“Option to drag node from browser.” This is already supported
“Limit # of entries in browser.” Not sure what you are looking for. Nodes are already grouped into sub-categories and you have the option of doing a text search rather than browsing through the list. I use the text search 99% of the time.
“Use existing Arduino libraries.” There are several discussions in this forum trying to determine the best way to do this. Since libraries are functional & XOD is object-oriented, an auto-conversion is probably never going to be possible.
“Need a simulator!” ‘Need’ is a strong word. Boards to test with are cheap. Why would a small team still in the early stages of development want to devote resources to create a simulator rather than making the product better. How do you even begin to add simulator support for all the add-ons available for microcontrollers???
“Contextual help for nodes within XOD.” This already exists. The tutorials show you how to use it.
“More tutorial videos.” Some of your suggestions here indicate you have not looked at the documentation already available. How is more documentation/videos going to help? Making a large # of videos for a product that is still undergoing major changes is counter-productive.
“Tutorials on making new component.” What level do you propose these be made for? Assuming your “1 wire device” is really one data pin plus power, it is probably either digital or analog & existing nodes can be used to read or control it. You cannot make tutorials to cover every possible option.
“Allow routing of connecting wires.” This would be nice, but Visio gets lots of money and has lots of developers and has been working on this for years and it is still a pain to use & make things look right. An alternative using tags/flags has been discussed and would probably be a better use of developer time.
“colour code the lines.” This is probably personal preference. The pins you connect to are already color-coded. Do you use color for input or output pin if they differ and auto-casting is being used? What do you really gain? Some would see it as additional screen-clutter.
“Option for favorite and/or used nodes in browser.” A nice-to-have for some people. Since I use the quick-search text input option, I would never use this.
“search function in browser.” This already exists. The built-in tutorial shows you how to use it.
“simpler naming convention for browser items.” Not sure what you are asking for here. You can name your new nodes anything you want. Built-in nodes have a library grouping and short-description (xod/core/add, xod/bits/shift-left). How do you get simpler than that?
Having defended XOD as someone who found it to be a life-saver while teaching a robotics class to students who couldn’t grasp Arduino IDE, I will admit that XOD is not fully ready for prime-time. I have several libraries I’ve shared with the community that have not been updated to work with the latest rewrite of XOD. Once I started the class, I could not easily update to newer versions of XOD and expect the students to keep up & I will have to re-write parts of the class to use with the latest version when it comes time to teach it again. There is no good way to add your own Arduino header files yet. Other cool features are only “in discussion.” These are trade-offs you make when using Alpha software.
I concur with gweimer on almost all points. The simulator functions your asking for exist in several electrical softwares and should be unrequired for most programmers. Based on your desire to clean the links I’d say you are used to doing that with traces. I’d suggest you try EasyEDA.
That said, I am in favor of adding link types or groupings. Think of it as a sort of spacial MUX.
No point in having 5 parallel links when 1 link with a symbol/color/tag would do as well.
Yeah, indeed many things are in their current state because we have very finite development resources. Thanks, @gweimer, you’ve almost cover the question. I’ll try to elaborate a bit:
You are too tied to the (cr**py) Arduino IDE and its software. You force us to use the Arduino boards pin No. designations (probably because of point 1 above). This is restrictive for many users. You are forcing me to use Arduino’s pre-built boards. Uno, Nano etc. I use individual chips (Atmel328P)
Well, when you start something it’s a good idea to bind to an existing audience and hardware which looks congenial. So the logic behind it:
Arduino as hardware is simpler than a bare microcontroller
??? is simpler than the textual C++ programming
OK, let’s make a tool for people who use Arduino’s. One of the nearest purposes on the roadmap is to make every Arduino IDE compatible board (like ESP8266) be XOD-compatible out of the box. Not sure about anything further than that.
A massive lack of information or proper exampls on how to use your software. YOU need to post a LOT more tutorial videos to YouTube showing us how to use XOD. We need good tutorials on how to make a ‘component’ which is not included in your library or and Arduino library. I have, say, a 1wire device I want to use with XOD how do I do it?
Not sure whether you found the docs, I agree there could be much-much more materials. We’re working on it and not always have enough time. If you can help and share a note/article/whatever, that’s great!
I just wanted to say ‘THANK YOU’ to all developers, contributors and supporters.
@cb900 beside your appreciated feedback have a look into https://xod.io/docs/contributing/ - you can find several ideas on how to take part in making XOD even better and influence its development.
Just start doing something prototypish in your free time and use XOD for it. Maybe even start publishing your experiments or experiences. There will be a point where you cross the rubicon. I predict you’ll gonna be amazed.
Otherwise we all are happy to see you again in a couple of month.
1. XOD is free software. I can ask for features but I can not command to implement new features.
2. XOD was announced from the beginning as a “visual programming language”. Functions are implemented in nodes. There is a help function and a node browser implemented. If the help manu says the output range is from 0 - 1 and not 0 - 100 % the developer of this nice software did it this way. It is not right or wrong; it is just different from other software’s usage.
3. XOD is still in developement and becomes more and more complex. The last update to 0.22 shows my personal limitations. Yes, there are examples how to use the UART. I tried to understand them but without a tutorial this becomes to complicated for me. In Arduino IDE it is much easier to set up a serial communication. The more I started experimenting with graphical programming languages, the more I have learned programming with Arduino IDE. It is easier for me to download some code snippets from existing projects and adapt them to my personal needs with Arduino IDE. The benefits of XOD are to produce quick results using different kinds of sensors and actors. Using not implemented hardware in very complex projects with unusual serial communication settings is impossibole for me at the moment.
In regards to the complaint of the OP “the produced code seems to be massive” I wonder whether he means the trans-piled output or the actual size of the binary when compiled and uploaded to the device? The C++ code generated by the transpiler can run to several thousand lines, sure. However the ideal of C++ is zero-overhead abstraction; most of the actual code you see prior to compilation is abstraction for the benefit of the software developer, not necessarily some one-to-one correspondence between lines of C++ and executable assembly instructions in the binary.
It’s not uncommon for classes in C++ that run to a couple hundred lines to compile down to just a dozen ASM instructions, that’s what optimizing compilers do, try to do as much work as possible at compile time, not runtime. The reason you write or generate all that stuff instead of do it in straight C or hand-code assembler is the abstraction provides the advantages of generic programming. That is to say in the ideal case you don’t have to rewrite all your C or assembler for a data structure or algorithm when you want to change something, you just say edit one line in a template parameter and all the rest of the stuff adjusts itself automatically to fit the new design.
A good reference book on these topics is Modern C++ Design by Andrei Alexandrescu.
The program memory/RAM usage overhead of a well-designed XOD sketch to accomplish a certain task currently doesn’t seem that much greater than if you were to write the same functionality in the Arduino environment directly. e.g. a sketch that uses the hardware UART API from the Arduino environment and all the generic overloads/abstractions it offers for integer types, strings, etc. is going to run you a good 4k of program memory usage no way around it.
IMO Flowcode charges an absurd price for what it offers which seems to be not much more than a glorified UML flowchart to C transpiler. There are tools that do that for free (though the GUI is probably not as sexy, or nonexistent.)
cover the question. I’ll try to elaborate a bit: