10-19-2020 10:46 AM - edited 10-19-2020 11:07 AM
A professional-grade compiler turning LabVIEW™ programs into sketches for Arduino™ compatibles, super-fast Teensy™ boards in particular.
The Kickstarter campaign is now LIVE. Help us make it happen / see more about it here:
https://www.kickstarter.com/projects/540055482/labviewtm-teensytm-arduinotm-sketch-compiler
10-19-2020 04:07 PM
Sounds interesting and I will probably donate a little to see this get released...
But...
As I found using TSXpert's Arduino™ Compatible Compiler for LabVIEW is since the Arduino (Atmel) is a single threaded single tasking microprocessor. The power of LabVIEW is pretty much waisted on such devices.
So you are forced to write very linear LabVIEW code that goes against all of the "best practices" and everything you know about programming good LabVIEW code.
10-20-2020 11:57 AM
Sure, these targets admittely require a slightly different approach than "regular" LabVIEW™ programming on a multi-thread computer, although considering interrupts and events, it's a bit rosier - yes, events exist even with these tiny, cheap targets, although not quite in the same, nice, versatile, and familiar LabVIEW™ way). More linear code, true, but (almost) the same modularity, productivity, versatility, maintainability, and even scalability, can still apply.
The Teensy™ boards we merely suggest, are also a very different kind of animal to those old Arduinos. The Teensy 4.0 is sporting a 600MHz+ (overclockable) ARM microcontroller, and the 4.1 can be extended up to 17MB of RAM, and up to 24MB of flash. Very capable, for the cca. $25 price tag is has on. This is why we chose them to conduct all our testing on & officially support them. Of course an output sketch (which we fully expose to the user with full access allowing for modification, hybrid programming, unlike any other tool so far, ever) can be compiled to any Arduino™ compatible target, with a suitable IDE of your choice.
Let me drop some features of our tool:
Again, slightly different coding considerations apply for these simple & cheap targets, indeed, but in our experience & opinion, LabVIEW™ is still so overwhelmingly more productive, flexible, and just more effective to work with compared to oldschool text coding, that for many like us, and perhaps also not like us, hours, days, months can be saved on a project with our tool - and it's a LOT more satisfying to work with, too. Okay, we're CLAs, so obviously in a bit of love with LabVIEW™ and the whole graphical dataflow-oriented programming paradigm itself, and satisfying is subjective anyway. Productivity however, is measurable.
Right, I guess I should stop before we start to sound sweaty. Just enthusiastic about bringing our originally in-house development & prototype tool to the market as a full-blown product, hoping others will join us in wanting.
10-20-2020 01:46 PM
Could you throw up some sample LabVIEW code that you've converted to Arduino? It would be interesting to see some example use cases a little more advanced than "Hello World".
Also, what's the current status versus the target status? Your video makes it look like it works already, but you're asking for a big chunk of change so you've clearly got a lot more development in mind for future expansion.
10-22-2020 09:00 AM
Hi again,
current status I would term as a fully functional prototype: narrow, not yet in a proper architecture, but fully working. What you see in the video, is a real demo recorded (just sped up), it does actually work, including generating the exact code you see in the video, as is, but indeed, it's a very simple one.
We have the auto-commenting, manual commenting (with bookmarks, just the standard LabVIEW way), direct code injection (3 distinct types, actually), full-scan constant mapping (it doesn't matter where you put constants, they're only delcared once & are fully reused even inside loops, also omitted if unconnected so you can just leave temporary dev constants around) done, among many others. We also have the framework figured (and revised, and revised again!), including extensive VI scripting and corresponding mapping. This last one, is very important, as scripting is slow, so we do it quite strategically - working from constructed object maps in memory is a lot faster... we strive to make it flexible, easily extensible, but also efficient, even for larger projects.
We're currently working on several items, one of the most crucial is "traverse backtracing", this will enable us to make the output code a lot more efficient (we don't just do a sledgehammer node job across multiple structure tunnels). Another one, is a separate tool actually, that will come with our software: cross-tracing of variables & functions, back & forth between VIs and output sketch. Yet another, is something I am just changing actually, structure folding with open-close codeblocks injected based on UID chains, rather than targeted line injections (which were of temporary purpose anyway). We've got headers in mind (from subVIs), with automated version checks, to only recompiled if actually changed. Then there are the usual items, generic things such as serial, i2c, spi, this is easy, actually, but requires a fair bit of time to develop & test.
We also just revised the whole code generation part, mainly to be able to support the oen-source area (where users can integrate or develop their own palette VIs and libraries, even) much better: one "ToolVI", one corresponding code generator VI where you define your own i/o & functions. With a template, of course, dead easy now, create ToolVI, populate corresponding code generator VI from template, copy both resultant VIs (with merely a naming constraint between the two) in to a designated folder (any subfolder or even library packaging is fine, it doesn't matter), restart LabVIEW, bang, it's there to use & good to go.
The most important part for us, beyond forging a fully featured product out of this of course, is to provide the best open-source area we can, so ppl can develop, integrate, exchange their own extensions / libraries with as much as ease & flexibility as possible. A good software product, in our corresponding concept at least, is one that is actually taken on & developed further by a community / ecosystem, and we're not only fine with, but proactively working towards that.
Eh, carried away again...
02-23-2021 05:37 PM
So... how does one get his hands on this jewel?
Will it support microROS2 on a Teensy 3.6?
Are you aware of Paul Stoffregen's work on real time scheduling on Teensydurino?
02-24-2021 09:41 AM
@DelWilson wrote:
So... how does one get his hands on this jewel?
Well Kickstarters are generally for things that don't exist yet. This team appears to have asked for $300k+ to make this toolkit and make it open source. I've never developed a toolkit like this, but that that sounds like a large amount of money. Since the funding period has ended, and they only got $15k I would think this isn't going to become available any time soon.
If you are looking for embedded alternatives for LabVIEW deployment, there is the Pi and Beagle bone platforms that NI supports through LINX, and the 3rd party solution through TSXperts but I don't see it on their site so maybe they got rid of it. And the already linked to Arduino compiler also from TSXperts.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
02-24-2021 09:49 AM
Anyone know what the differences are, if any, between the Home & Standard editions of the TSXperts compiler? Only thing I found was that the Home edition is NOT to be used for commercial projects.
Thanks,
George