The power of Raspberry Pi in the computing factor of an Arduino, and the manageability of a mobile app.
Latest Updates from Our Project:
Solder Kits Shipped, Final Boards Ordered, Interrupts Unblocked, New API, and more.
almost 6 years ago
– Thu, Mar 14, 2019 at 02:28:47 AM
Howdy!
Hey folks, got some awesome updates today. :)
Hardware Validated, Final?? Boards Ordered!!
We finished hardware validation! The last thing remaining was CAN, and we knocked that out and ordered our production PCBs last week. Assuming we got the last few changes right, those should be the final PCBs, so cross your fingers. 🤞🏽We should get them back in about two weeks. When we get them, we’ll assemble a small number to validate the final changes. If all goes well, we’ll put the rest of the boards in to assembly and they’ll be the final reward boards!
Solder Kits Shipped
That’s right, if you ordered a soldering kit, it’s on its way! They’re really nice kits, enjoy.
Interrupt/Threading Issue Unblocked 💃🏽🕺🏽
In addition to the hardware changes, we’ve been hard at work on the Meadow internals. First, we’ve unblocked the threading issue! It’s not fully fixed, we have some deeper internals to fiddle with for the final solution, but we’ve unblocked with a workaround. This unblocks a bunch of managed IO features including eventing/notifications and all of the protocols such as I2C, SPI, Serial, etc., so it’s pretty exciting. 🙃
More IO, New API
One of the big things we’ve been working on is a major rewrite of how IO is handled between the underlying OS and Mono (the managed runtime) where we’ve been able to simplify a lot of the underpinning there. In the process we’ve got Analog inputs up, and we’re in the process or wiring up the Digital Input Events, as well as our new `IObservable`/Reactive pattern.
Along the way, we’ve also done a lot of thinking and reworking of the API. Specifically, we’ve added two new features. The first, is that the IO Devices are self describing with a mapping of Device > Pins > Channels. For instance, the following Meadow code enumerates all the pins and what type of IO is possible for each pin:
foreach(var pin in Device.Pins.AllPins) {
Console.WriteLine("Found pin: " + pin.Name);
foreach (var channel in pin.SupportedChannels) {
Console.WriteLine("Contains a " + channel.GetType()
+ "channel called: " + channel.Name + ".");
}
}
Here’s an excerpt from the output the above code returns:
Found pin: A05
Contains a Meadow.Hardware.DigitalChannelInfochannel called: PC1.
Contains a Meadow.Hardware.AnalogChannelInfochannel called: ADC1_IN11.
Found pin: D00
Contains a Meadow.Hardware.DigitalChannelInfochannel called: PI9.
Contains a Meadow.Hardware.UartChannelInfochannel called: UART4_RX.
Found pin: D01
Contains a Meadow.Hardware.DigitalChannelInfochannel called: PH13.
Contains a Meadow.Hardware.PwmChannelInfochannel called: TIM8_CH1N.
Contains a Meadow.Hardware.UartChannelInfochannel called: UART4_TX.
Found pin: D02
Contains a Meadow.Hardware.DigitalChannelInfochannel called: PC6.
Contains a Meadow.Hardware.PwmChannelInfochannel called: TIM3_CH1.
Found pin: D03
Contains a Meadow.Hardware.DigitalChannelInfochannel called: PB8.
Contains a Meadow.Hardware.PwmChannelInfochannel called: TIM4_CH3.
Contains a Meadow.Hardware.CanChannelInfochannel called: CAN1_RX.
An astute observer familiar with the STM32F7 might notice that the analog port in the excerpt also exposes digital IO. We’re now much more flexible in what types of IOs are exposed on which pins; which provides more options for you. With these `ChannelInfo` objects, the IO is self-documenting, and you can see what kind of ports are available from each pin without having to refer to the IO pinout diagram.
Additionally, we made the API more device-centric. So instead of instantiating ports out of thin air (which was always just a little off); ports our now created via a device:
The great thing about this, is that it doesn’t matter whether the ports are on the Meadow, or on external IO expanders, the API is the same. So we could also create a Digital Output Port from an MCP230xx IO expander, the same way:
var ledPort = mcp.CreateDigitalOutputPort(mcp.Pins.D04);
This provides a more intuitive mental map of the hardware and also simplifies the IO control under the hood.
Beta Folks
Beta folks, you’re going to get these new bits shortly; we’re getting everything packaged up right now.
Thanks everyone for keeping up to date with us, things are really moving! Stay tuned for the next update.
Workbenches shipped, hardware validated, and more.
almost 6 years ago
– Thu, Feb 28, 2019 at 04:30:40 PM
Hey, all right! Things are continuing to move forward over here at Wilderness Labs. We shipped the workbench rewards and we’re gearing up to ship the solder kits as well as the Mug/SWAG rewards. We’ve also made good progress on both the hardware and the software portions of the Meadow platform.
We’re Shipping More Rewards!
The Hardware Hacker’s Workbenches went out this week, and we even snuck a few extra goodies in there for those awesome backers! Next up, we’ll be shipping the Solder Kits, we’re just waiting on some shipping boxes. 💪🏽
Tech Debt Payback
We’ve made great progress on the Meadow OS stack in the last couple weeks. We got our Reactive pattern integrated with `IObservable`, which should delight you Reactive fans. Additionally, we spent a bunch of time paying down some technical debt as part of debugging our interrupt issue. Specifically, we got debugging into shape. We’ve got a lot of interesting things happening under the Meadow hood, and we were unable to unwind stack traces at the native level, which made debugging an adventure in the dark without a flashlight. We spent some time to get that into shape, and now we have a good idea of where the issue is happening, so next up is to fix it.
We also reworked a lot of how the subsystem handles GPIO; the default architecture in NuttX (the µRTOS under the hood) was designed for a different set of use cases than ours; given the managed nature of our runtime. As such, we’ve had to re-think the patterns there and re-do a lot of that. The upside is that all GPIO stuff going forward will be a lot easier (including a portion of the interrupt issue). That includes digital, analog, and protocols such as I2C, SPI, CAN, Serial, etc.
We also updated the external flash memory driver, so we have full use of the flash on the board again; which will allow us to massively streamline our deployment process. Right now, deployment is onerous, so our beta users will rejoice on this advancement, as it’s one step closer to beautiful, easy, one step, OS/App deployments.
Hardware Validation
Also… we’re nearly complete on hardware validation! Yusss (that’s the new “yaaas,” which was the new “yes,” according to the cool kids; English is an interesting language).
Because some of the GPIO access was blocked by our interrupt marshaling issue, we went ahead and validated with C++ apps, and thus far, everything is passing with flying colors. We’ve got Analog, Digital, PWM, I2C, SPI, and Serial all validated, and we’re working on CAN right now, but it’s pretty low risk.
We also had a productive session with our antenna vendors, and were able to change out the values a couple components on the board and got a 6db (about 2x improvement; decibels are log-scale) antenna efficiency increase. There are a couple more fixes that we made to the actual physical board design in that regards that we expect will turn that knob even more.
Golden Board??
Speaking of which, we made a few other very minor changes to the board; we changed the analog pin that was reading the battery voltage, and also fixed an issue where the board could be minorly powered even when the EN(ABLE) pin was pulled low (the EN pin acts like a digital ON/OFF switch).
With these last changes, unless something new crops up, or we made a mistake in these fixes, we think that the next revision will be the golden board! As such, we’ve decided to order the product quantity of Printed Circuit Boards (PCBs) manufactured (assuming CAN checks out). 😄This is an interesting balance of time and cost risk; it’ll cost us about $3,200 and ~2 weeks to get 2,000 PCBs, vs. $1,500 and a week to get 100 PCBs built. We’re going to assemble 100 or so of these, and if the board is good, we’ll be ready to pull the trigger on the full assembly run, and we’ll save $1,700. If there’s a bug in the board, we’ll lose $1,700, and an extra week. Luckily, the changes are pretty low risk, but we’ll know in a few weeks if we made the right bet! 🙀
That’s it for now, chat soon!
Shipping Stuff, Network OTAs, and Reactive
almost 6 years ago
– Fri, Feb 15, 2019 at 11:47:15 PM
Hey hey all you lovely backers! Some fun updates:
We’re gearing up to ship Workbench, Solder Kit rewards, and mugs.
Network updates are a go!
Reactive is coming to Meadow. 😮
It’s a Geek Christmas in the Garage
First, nearly everything has come in for our rewards. It looks like a geek Christmas in one of team’s garage. Check out these Hardware Hacker’s Workbench kits getting ready for shipping:
These should go out next week. We’ve also got the mugs in, and they look oh-so-nice:
Looking forward to getting these things on the road and in your hands. 🥰
Network Co-processor Updates are a Go
On the hardware front, we’ve made good progress on a number of items. First of all, we’ve validated our network co-processors (ESP32) over-the-air updates from a hardware perspective. We’re confident now that we can update its firmware either from itself, or by flashing it from the main STM32 chip. Having options are good.
Additionally, we’ve got a tuning session scheduled on Monday with Pulse, the makers of our antenna chip, to tune our antenna circuit for even better reception. They’re just across the river from us in Vancouver, Washington. The antenna has a tuning circuit known as a Pi-network, that consists of a couple of capacitors and an inductor. They’re going to measure the circuit and tell us exactly what capacitor values we need to make it hum in tune. This will ensure that we have rock solid WiFi and Bluetooth comms.
Meadow’s Getting Reactive!
Meadow is an opportunity for a fresh start in hardware. It’s a chance to take our collective hardware and software framework/platform experience and really, truly make a massive leap forward in the state of the art.
As such, as we’ve been building, we’ve been rethinking and reevaluating everything. The Meadow APIs are designed to simple yet powerful. Prescriptive, yet flexible. Lightweight, yet modern. One of the places that we’ve been doing some heavy and innovative work is in the Reactive pattern of event handling. The connected nature of circuit behaviors lend themselves well to being modeled and composed in a reactive way, enabling various components to be wired together in a simple way while also providing advanced filtering.
However, the existing reactive frameworks generally bring in too much code (15+ MB) to be practical, so we’ve spun a lightweight API based on the Observer pattern. For example, consider the case of an TMP35DZ analog temperature sensor which outputs 0V at 0ºC, and 3.3V at 100ºC. An application may have several different uses cases of what it wants to know and when, regarding the temperature. For example, it may want to be notified when the temperature reaches a particular read. Or it might want to be notified only when the temperature moves an absolute amount, say 1º in either direction. Or might want to know when the change hits a particular percentage.
The following code samples are still a work in progress, but let’s first consider the use case of wanting to be notified when the temp hit 75ºC:
// absolute: notify me when the temperature hits 75º
float seventyFiveDegrees = (3.3f / 100f) * 75;
_absoluteObserver = _analog01.Subscribe(
filter: result => (result.New > seventyFiveDegrees),
handler: avgValue => {
Debug.WriteLine("We’ve hit 75º!");
// unsubscribe when we hit it
if (_absoluteObserver != null) {
_absoluteObserver.Dispose();
}
});
Or, let’s say we wanted to be notified whenever the temp changed by 1º:
// relative, static comparison; e.g if change is > 1º
As you can imagine, this filtering pattern could be used in other scenarios as well. Consider a digital accelerometer; an app may only want to be notified when the accelerometer noted a particular amount of change in only one axis, or even just in one direction along an axis. This reactive and filter pattern allows your app to only get events in a very precise and flexible way.
Of course, we also support classic events, so you’ll still be able to do something like the following without issue:
analogPort.Changed += (s, e) => { /* do something*/ };
There’s also a lot of other magic in there, such as automatic oversampling, that we can’t wait for you to see. Stay tuned for more!
Network, Docs, and a Delay
almost 6 years ago
– Sat, Feb 02, 2019 at 01:45:13 PM
Hello folks! Bryan here, got some great news, and an update on progress for you.
Networking is Up!
First, we have great news on the network front. We were able to validate the network hardware on the Meadow F7 Micro board, and it’s running smoothly. Per the last update, we had to do another revision of the board because we were unable to program the ESP32 co-processor on the last revision. We got the new boards back a little over a week ago and we were able to not only load the network app on there, but it also successfully; enumerated WiFi networks, connected to one, and performed a successful web request! What’s more, we were able to enumerate as many WiFi networks using the onboard antenna as we could from the same location using an iPhone. That speaks well to the tuning of the network hardware. And when we plugged in an external antenna, we saw even more networks, so we’re pretty happy with that. Now we’re working on validating that we can update the ESP32 firmware from the main STM32, to ensure we can drive over-the-air (OTA) updates.
Beta Docs Site
Second, we launched a beta documentation site. This is primarily so our beta users can get up and running, but for those interested, you can follow along with our progress there as well. We’re also proud to be able say that we have nearly all public members documented to at least a summary level! Please note that these docs, along with the API is still a work in progress.
Production Delay
We’ve run into a little hurtle deep in the Linux kernel around process scheduling, and it’s currently blocking our progress on complex GPIO. We have basic digital output, digital input, and we’re progressing on analog input, but interrupts are not being passed from the POSIX OS subsystem to Mono land, which means that there we can’t raise any events on change. We hope to resolve soon, we’ve got some additional resources looking at the issue, but it also blocks us on PWM, and the various communications protocols such as I2C, and Serial. However, we’ve been working on software-driven Serial and SPI so we can still move forward on peripheral porting.
This also blocks us on validating the ESP32 updates, so we can’t order the boards into production until we get through this and finish our last hardware validations.
Board production is slated to take ~3 weeks; we’re hoping this will only be a short delay, and we may be able to accelerate the first 100 or so boards, so this may wind up being a wash. But in the interest of transparency and clarity, I want you to know that this is outstanding.
Beta and Scott Hanselman
If you happened to be at NDC-London today, I hope you caught Scott Hanselman’s talk; he demoed Meadow running a cool little app! Last week we got the beta up and running on his machine and building some fun little demos. I think he’s got some more talks coming up, so if you’re in London or Brussels?, you might be able to catch him and see Meadow in action, live!
