wildernesslabs / meadow.core Goto Github PK

Currently, it returns an ObservableCollection, which is a leftover from the old API.

It should just return a plan IList<Network>.

It should also be async, so it can be awaited.

testing checklist:

• one
• two

Summary

Created cell network scanner method on Meadow.Core

should be Device.WiFiAdapterInitialized

The Value property in DigitalInputPortEventArgs reported by the Changed event on a DigitalInputPort is always false regardless of pin state.

Problem

If you add an empty (or all comments) configuration file to your Meadow app, it will throw an exception when the app loads.

Meadow StdOut: ERROR: System.IO.InvalidDataException: Failed to load configuration from file '/meadow0/app.config.json'.

In this case, I am seeing the error with the new application settings configuration. It would likely do the same for any other configuration systems: meadow.config.yaml and wifi.config.yaml.

Expected

• If it can't load the empty file properly, I'd expect the defaults to be used.
• If it fails because of bad configuration data, I'd expect an error message or warning.

Details

Here's the stack trace from the original exception.

  at Microsoft.Extensions.Configuration.FileConfigurationProvider.HandleException (System.Runtime.ExceptionServices.ExceptionDispatchInfo info) <0xc1508a38 + 0x00096> in <3cfa5edff95b45d581cfb833a66bda1f>:0 
  at Microsoft.Extensions.Configuration.FileConfigurationProvider.Load (System.Boolean reload) <0xc0f65a00 + 0x001ae> in <3cfa5edff95b45d581cfb833a66bda1f>:0 
  at Microsoft.Extensions.Configuration.FileConfigurationProvider.Load () <0xc0f65028 + 0x00004> in <3cfa5edff95b45d581cfb833a66bda1f>:0 
  at Microsoft.Extensions.Configuration.ConfigurationRoot..ctor (System.Collections.Generic.IList`1[T] providers) <0xc0f5c850 + 0x00098> in <966d96afb2e5474d83e450f592b61f25>:0 
  at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build () <0xc0f3bd48 + 0x00098> in <966d96afb2e5474d83e450f592b61f25>:0 
  at Meadow.ConfigurableObject.SetConfigRoot () [0x00030] in C:\dev\_WildernessLabs\Meadow.Core\source\Meadow.Core\Configuration\ConfigurableObject.cs:75 
  at Meadow.ConfigurableObject..ctor () [0x0002f] in C:\dev\_WildernessLabs\Meadow.Core\source\Meadow.Core\Configuration\ConfigurableObject.cs:18 
  at Meadow.LoggingSettings..ctor () [0x00000] in C:\dev\_WildernessLabs\Meadow.Core\source\Meadow.Core\Configuration\LoggingSettings.cs:5 
  at Meadow.MeadowOS.LoadSettings () [0x00003] in C:\dev\_WildernessLabs\Meadow.Core\source\Meadow.Core\MeadowOS.cs:100 

I've been testing DigitalInputPorts and typically the Changed event is being raised 1-5 seconds after the button is pressed

Meadow hangs/crashes when connecting to update service over MQTT

Setup
Featherv2
OS 0.6.7.31+
VS2022
Windows 11

Branches
Core feature/update-service
Contracts feature/cancellation-token
Meadow.Core.Samples feature/update-sample

Repro

• Set the Update Server in app.config.yaml. By default it's Meadow cloud's IP - only change if you want. Issue reproduces with the existing IP. To push an update, I recommend using Workbench
• Make sure LogLevel is set to Trace
• Run the Update Sample via Deploy
• App will start up
• LED will start blinking
• UpdateService will begin and you will get this output:

TRACE: Running App
INFORMATION: Connecting to the network...
TRACE: Interface: wlan0: wlan0 Wireless80211 Up
INFORMATION: Network connected!
TRACE: Updater State -> Disconnected
TRACE: Updater State -> Connecting

• LED will stop blinking

Last line of code executed:

Device.WiFiAdapterInitialized isn't being invoked

https://wildernesslabs.slack.com/archives/CEP6S618D/p1639858576151400

PeterM 12:16 PM
@adrian @bryan Here's a summary of the things I found in ...\Meadow.Core\source\Meadow.F7\Devices\Definitions\F7MicroV2.Pinout.cs on the develop branch of Meadow.Core.
First, the line new PwmChannelInfo("TIM5_CH1", 8, 1) the '8' should be '5'.
// D02
// TIM5_CH1, I2C4_SMBA, FMC_D18, DCMI_D1, LCD_R4, EVENTOUT
public IPin D02 => new Pin(
"D02", "PH10",
new List {
new DigitalChannelInfo("PH10", interruptGroup: 10),
new PwmChannelInfo("TIM5_CH1", 8, 1)
}
);
Second, D05 and D09 both use Timer 3 Channel 1. I've checked and because of our GPIO choices there's no alternate timer/channel available for D05 or D09 so they can both be PWM. So, one of these should not be allowed to use PWM.
public IPin D05 => new Pin(
"D05", "PB4",
new List {
new DigitalChannelInfo("PB4", interruptGroup: 4),
new PwmChannelInfo("TIM3_CH1", 3, 1),
//new UartChannelInfo("UART7_TX", SerialDirectionType.Transmit)
}
);
...
// D09
// TIM3_CH1, TIM8_CH1, I2S2_MCK, DFSDM_CKIN3, USART6_TX, FMC_NWAIT, SDMMC2_D6, SDMMC1_D6, DCMI_D0, LCD_HSYNC, EVENTOUT
public IPin D09 => new Pin(
"D09", "PC6",
new List {
new DigitalChannelInfo("PC6", interruptGroup: 6),
new PwmChannelInfo("TIM3_CH1", 3, 1), // or TIM8_CH1
}
);

bryan 12:18 PM
good catches
12:18
D09 can’t be Tim 8, channel 1?

Adrian 12:44 PM
Oh excellent - I vote we fix, test, and get it in for the next release

PeterM 1:43 PM
@bryan Your right. Best catch! D09 (PC6) should be switched to Timer 8, Channel 1. My mistake.
1:44
Glad your awake and keeping me honest. 💪:skin-tone-4:

1st - since it's kHz could this just be an int?

2nd - should we have an overload that takes an enum that aligns to the SPI speed buckets?

I may not correctly understand what the two settings are supposed to do, but I can't seem to get the available settings in app.settings.yaml (and app.settings.json) to alter the way my Meadow app runs.

With the following configuration, and a File>New color cycle app with a throw new Exception() line after all the colors, it doesn't take any longer to restart than when the setting isn't configured. And the output from meadow listen doesn't change at all between log level Trace and log level None.

Lifecycle:
  ResetOnAppFailure: true
  AppFailureRestartDelaySeconds: 150
Logging:
  LogLevel:
    Default: "None"

Just so things look tidy when searching nuget - users should rarely add these packages themselves

MeadowV2

Create an interrupt port on D12
Create a PWM port on D13

Unhandled Exception: Meadow.Hardware.InterruptGroupInUseException: Interrupt group 14 is already in use

It's not implemented

During testing, creating a digital input port for pin 15 started crashing or blocking. It was working and reporting Changed events, after several deploys it stopped working. Resetting the device and redeploying the application didn't fix the problem.

@jorgedevs and I saw similar behavior yesterday for pin 4.

Using Meadow 0.7.0 and Nuttx build from beta release 3.1.

https://github.com/WildernessLabs/Meadow.Core/blob/develop/source/Meadow.Contracts/Hardware/Contracts/PortsAndBuses/IPwmPort.cs

On the Device class -

We have a Coprocessor property and a
InitCoProcessor method ... we should standardize the casing of CoProcessor

It appears that, regardless of the value in app.settings.json (presumably app.settings.yaml as well), that the information log entry when Meadow crashes is hard-coded to five seconds.

Meadow StdOut: INFORMATION: CRASH: Meadow will restart in 5 seconds.

I'm not sure if that is related to the app settings, but this was still the message even when app.settings.json contained the following, setting the restart delay to 30 seconds.

{
  "Lifecycle": {
    "ResetOnAppFailure": true,
    "AppFailureRestartDelaySeconds": 30
  }
}

This seems to be confirmed here, if this is the value the configuration is setting.

https://github.com/WildernessLabs/Meadow.Core/blob/develop/source/Meadow.Core/MeadowOS.cs#L312

Resolver.Log.Info("CRASH: Meadow will restart in 5 seconds.");

https://github.com/WildernessLabs/Meadow.Core/blob/develop/source/Meadow.Core/Bases/App.cs#L35

One of the last remaining API weirdnesses - the lifecycle of the device

Triggered a by a crash in one of the serial port samples:

SerialPortName serialPortName = Device.SerialPortNames.Com1; as a class level field will throw an exception - moving the instantiation to the constructor is the workaround.

When I want to upload data to the F7FeatherV2 with ISerialMessagePort, only a part of it arrives. Tested with 1024 bytes of data, with:
serialPort = Device.CreateSerialMessagePort( new SerialPortName("COM4", "ttyS1", Resolver.Device), prefixDelimiter: new byte[] {0x01, 0x10, 0x02, 0x20, 0x04, 0x40, 0x08, 0x80}, preserveDelimiter: false, messageLength: 1032, baudRate: 9600, parity: Parity.None, readBufferSize: 2048 );

Played around with the baudrate, prefix and suffix delimiter, parity and readBufferSize. Somtimes there are ~200, ~100 or ~400 correct, the the rest are zeros. Tested with an uploaded file via HTerm as well as with a console application.

ISerialPort produces the same results.

The data is also transferred correctly(Tested with a sequence of 0x00 and 0xFF):
data.csv