Oh yes! I have been working on the next demo (motto: “I don’t build demos; I demo builds”). There was a lot of not-visually-interesting heavy lifting to get through, but I am nearly ready to do a brief demo video of the latest goodies. I should be able to get that out before Wednesday.
Wednesday my time a
or my time
Why did I not see that coming… No, those of you on the disreputable side of the international date line are destined to be disappointed until Thursday.
Oh my, oh my. I am rapidly running out of working day. My goal was to eliminate a little more hand-waving so that the concepts are clear and the code has been fighting me tooth and nail. There’s so much non-visual stuff required to make this ‘real’, and I don’t want to demo smoke and mirrors, so stand by … demo teasing coming shortly.
Happy Thanksgiving everyone!
Thank you very much, that looks very promising.
Unfortunately the text of the video appears not sharp on my screen, so it is hard to read.
You really have ported TinyCLR on the BeagleBone? That means running C# on the Beaglebone without Linux and Mono? Is this going to become open source?
Btw: I am just beginning to make a project for the BeagleBone using Mono and Remote Debugging. Doing this I found that the links to your tutorial ‘http://kb.pervasive.digital/Home/Categories/octavo-beaglebone-black’ seem to be broken. Is there another working link?
Thanks. And no, there’s no TinyCLR for the BeagleBone. Dragging the BBB onto the diagram was a confusing choice on my part, driven by the fact that I do not have any visual models for any TinyCLR-compatible mainboards. If GHI wants to send me some STL files, I will create some, but I haven’t so far.
By the way, if anyone has STLs or Fritzing libraries that contain mainboards that they care about, feel free to send them on to me (mcalsyn at pervasive dot digital) and I can create Sagitta Designer models from those inputs. Those documents must be available under a Creative Commons, BSD, MIT or Apache license.
The way the system works is that each ‘part’ (e.g., a mainboard) contains a list of platforms (TinyCLR, netmf, nanomf, Mono, Windows IoT UWP, etc.) and the nuget packages that support that part on that platform. Not all parts will have drivers for all platforms. So, a BBB won’t have TinyCLR, netmf or nanomf drivers, but will have Mono-based drivers.
Unfortunately, for demoing the user experience, I created a project and dragged on a part that would not work in that project. Because the package-mapping system isn’t fully in place, there were no warnings displayed to tell me that I was creating a non-working design.
The current status of the project is that I am working toward a “minimally viable product”, which probably means TinyCLR and netmf 4.4 only, with C# and Vb support and only a few accessory drivers (basic LEDs and sensors). Once I reach that point, then anybody can create additional parts and drivers because the part editor is built in, so you can create your own parts and map those to driver, agent, and middleware software.
The roadmap from today to MVP is:
- Add wire routing to the breadboard and schematic editors (this is a significant work item)
- Develop the nuget package mapper and publish some test drivers for a couple mainboards and simple peripherals to the point where a simple program compiles and runs against those devices
- Bring the Schematic editors up to parity with the breadboard editor (drag, drop, position, orient, load, and save) ignoring the PCB editor for the moment.
- Finish enough of the part editor to allow the creation of a part (which I currently do manually by editing json)
Once a user can create basic TinyCLR and netmf programs with a couple sample parts, then I make the first public release. Realistically, that’s probably sometime next March, unless at some point I deem it cool enough as is and release it early.
In any case, the early releases before v1.0 come with no guarantee that I won’t make breaking changes that render your designs unreadable. I won’t make backward/forward-compatibility guarantees until v1.0 is out in, say, six months or so.
EDIT: Additional note: Parts libraries are just GIT repositories which you can host on Github or anywhere else convenient, so anyone can create a new parts library. For example: https://github.com/PervasiveDigital/sagitta-parts-adafruit and and the code packages are just nuget packages.
I should have answered your other questions:
Yes, the video is awful. A 4K screen encoded at 720p was a bad choice, but this was a one-take video literally made 30 minutes before leaving for Thanksgiving dinner. I will replace it in a couple weeks with a new video and put more care into production value
I took down kb.pervasive.digital as part of trying to economize on web hosting slots and the overhead of keeping the articles accurate and up to date. It will be back in a different form, but probably not for months. Probably not a very satisfying answer, but it’s what I got.
Thanks, I’m happy that I always save valuable stuff on my own PC, so I still have access
A Big thank’s for your work.
Looks really promising!
Gadgeteer without the wiring limitations!! Yahoo!
Here’s the sort-of-weekly update. Firstly, given the earlier discussion of detecting design errors (dropping a device into a project type that has no driver code for that device), I thought through the Design Rules interfaces quite a bit and decided to create an extensible framework. That is, you can add new design rules (software validations and hardware design validations) by creating new VSIX extensions. Sagitta exposes it’s entire object model as VS services, and allows for extensibility using the Visual Studio extensibility model.
Design Rule violations show up in a tool window resembling the Error window in VS. One difference is that for a given rule validation failure, there can be multiple ways to mitigate that error. Expanding the error notice gives you suggested Corrective Actions, and double-clicking on any of these will take you to that diagram or code location. This is an example of a test rule’s output:
The second change was to add support for pagination on Schematic, Breadboard, and PCB diagrams (see “Page 1, Page 2, New Page” at the bottom of the editor window). That forced a bunch of breaking changes to the data model and was a bit of a soul-sucking exercise in refactoring, but it’s an essential feature that I should have thought of earlier:
You can also see the “Design Rules” output tab at the bottom left. Work continues, and I’m still on track for a first public pre-release around February.
This is really looking great and promising so far!
Kudos for the extensibility. I’m curious to see how it will work out in the long run. Does the VS extensibility model handle API versioning well?
Thanks. I’m investing a lot in the architecture so that this thing has long-term potential, but whether and how it catches on is yet to be seen.
Yes, the moniker used for requesting an interface is versioned, and interface polymorphism is supported. Microsoft has leveraged this versioning for some of their internal VS services over the years.