No DeviceScript Managers found about devicescript HOT 28 CLOSED

Also, If you need help with "undusting" let me know. I'll have some spare time on the weekend, so I can take a look at it (just not sure if ppl outside of Microsoft are allowed to contribute - big tech often has some specific rules even when it comes to open source 😅 )

from devicescript.

from devicescript.

Oopsies, the rp2040 uses serial so try adding "--serial" which will require to npm install serialport (another native package)

from devicescript.

Ok this change will start a dashboard with a connection string for devtools --> a4b905d . It also adds a link to the "connection helper" page that solely there to connect to a device.

from devicescript.

@thegecko that being said, most of our current devicescript board are using serial (and serialport) so we haven't been try to test node-usb so much.

from devicescript.

I think you want to first deploy the DeviceScript firmware to the pico so that the CLI will find it. You can find instructions at https://microsoft.github.io/devicescript/devices/rp2040/pico-w#firmware-update

(In general, the vscode experience is more polished than the CLI wich will have some abrupt error messages).

from devicescript.

Yeah, sure, I forgot to mention I already did that 😅 devicescript flash rp2040 --board pico but results are just the same. Is there any way to list configured devices, like devs device ls? Or plans to implement it in future?

I'm familiar with VSC extension but on daily basis I use different IDE, so I thought that I can make use of cli instead. Also, because I tried extension already I had expectations that npm run start should somehow copy the behavior of extension's connect, and will allow me to code and see changes live, but maybe I'm wrong?

I achieved what I initially wanted to do by manually running the below commands

devs bundle --board pico src/main.ts
// and later
devs flash --board pico --file .devicescript/bin/bundle-devicescript-rp2040-pico.uf2

is it something what devicescript devtools src/main.ts should do? I mean, maybe in different way under the hood, but similar from user perspective - watch, compile and upload. Because on each change I'm still getting this set of messages:

Deploy error: No DeviceScript Managers found.
build src/main.ts OK
deploy status: No DeviceScript Managers found.

from devicescript.

Yes we need to undust the cli a bit. I suspect it doesn't even try to connect to the board but still expects to be able to flash the device. Is there a --usb flag by any chance on the devs build command? I'll need a bit of time to look at this.

from devicescript.

There is --usb flag, but when enabled there is also an error (Tested on Node 18 and 20):

services: error adding potentiometer, classIdentifier already in use
adding USB transport (requires "usb" package)
node:internal/modules/cjs/loader:1077
  const err = new Error(message);
              ^

Error: Cannot find module 'usb'
Require stack:
- /some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs
- /some/user/projectX/node_modules/@devicescript/cli/devicescript
    at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
    at Module._load (node:internal/modules/cjs/loader:922:27)
    at Module.require (node:internal/modules/cjs/loader:1143:19)
    at require (node:internal/modules/cjs/helpers:119:18)
    at tryRequire (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:488880:10)
    at createUSB (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:488890:15)
    at createTransports (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:488977:21)
    at Command3.devtools (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:490514:22)
    at Command3.listener [as _actionHandler] (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:1367:21)
    at /some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:2044:69
    at Command3._chainOrCall (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:1955:16)
    at Command3._parseCommand (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:2044:31)
    at /some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:1874:31
    at Command3._chainOrCall (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:1955:16)
    at Command3._dispatchSubcommand (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:1870:27)
    at Command3._parseCommand (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:2015:23)
    at Command3.parse (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:1738:14)
    at Object.mainCli (/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs:491407:11) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/some/user/projectX/node_modules/@devicescript/cli/built/devicescript-cli.cjs',
    '/some/user/projectX/node_modules/@devicescript/cli/devicescript'
  ]
}

from devicescript.

We'll take the help!

from devicescript.

Just installed usb package and it runs without throwing error, but still logs the same error as in my initial message.

Now I'm curious, what do you mean by this

Otherwise we’ll have to go through the devtools -> webusb route which is surprisingly more reliable.

can we upload code to the board via browser? I know the WebUSB standard, but wasn't aware that DS somehow supports it

from devicescript.

Check out https://microsoft.github.io/devicescript/api/cli#build-watch

essentially devtools can act as a bridge between browser + webusb/webserial and the cli.

We use this to flash a device locally while deving in a container

from devicescript.

Oopsies, the rp2040 uses serial so try adding "--serial" which will require to npm install serialport (another native package)

hah, you right! Now it works as intended! devicescript devtools -s src/main.ts

from devicescript.

keeping this bug open to track updating the docs / cli error messages

from devicescript.

I started digging in code, wanted to fix messages but I don't get this flow, maybe you can help me understand:

in cli devtools we have something like this:

const transports = createTransports(options)
const bus = new JDBus(transports, {
    client: false,
    disableRoleManager: true,
    proxy: true,
})

nevertheless, all transports are optional and configured from cli options, this is the content of the above function:

export function createTransports(options: TransportsOptions) {
    const transports: Transport[] = []
    if (options.usb) transports.push(createUSB())
    if (options.serial) transports.push(createSerial())
    if (options.spi) transports.push(createSPI())
    return transports
}

but without transport selected cli will throw No DeviceScript Managers found error. So, my question is: should we force user to choose transport method or set some by default (or detect it somehow)?

from devicescript.

these are the "native" transports, assuming your OS is physically connected to the hardware. devtools also opens up a websocket server, and add websocket transport that allows to connect to the device via webusb/webserial and marshal the jacdac packets through the web socket.

So the message "no devicescript managers found" really means: we could not find any devicescript device (e.g. has the DeviceScriptManager service) to flash the devicescript bytecode to.

from devicescript.

okay, so let's assume that I'm leaving it as it is, without any native os transport defined - what should happened next? Because now, when I run devicescript devtools src/main.ts I'll see my error, later I can enter the http://127.0.0.1:8081, which looks a bit empty, like on the below screenshot and I have no option to connect to my device via WebUSB.

devtools also opens up a websocket server, and add websocket transport

So, shouldn't it be added in initial phase to transports array as fallback option in devtools mode?

from devicescript.

Looks like the simulator thinks it is inside of vscode (where we hide the connect button). This should only happen when --vscode is added to the CLI so something is going on there too.

from devicescript.

So you need to run devs devtools cli with a device connect; then do a deploy from another terminal.

$ node ../../cli/built/devicescript-cli.cjs deploy src/main.ts 
using devs: v2.15.15, runtime: v2.15.15, node: v18.14.0 from D:\gh\devicescript\cli\built
connected to ws://127.0.0.1:8081
remote-deployed src/main.ts

from devicescript.

here is where the websocket is opened

from devicescript.

Thanks for the changes! Indeed, now I can see connection dashboard. Nevertheless, it started behaving unpredictable. I leave the below description of bugs I found while trying to make it work.
Now it looks like everything works fine via WebUSB and dashboard. After running devicescript devtools src/main.ts, when pico is connected, it runs dashboard, reacts to changes in code and uploads changes to the board.

--- bugs before it started working ---

Sadly, on attempt to connect to a physical device it hangs and freeze whole Chrome 😢

after a few minutes it will unfreeze and prompt again "connect to device" modal, another attempt to connect ends with the same results.

UPDATE: okay, while describing the above behavior I reconnected pico and it appeared as connected, but with some errors

30331ms: crc mismatch; sz=228 got:499, exp:36624, f301e443e66038b7139d702fe03e8046446576530a6e29f110000f02050003000000000000000000000000000000000070000000c000000030010000b4040000e405000000000000e405000000000000e40500004000000024060000000000002406000000000000240600008c010000b0070000ec0000009c080000e8000000300100001c00000000000000504000004c0100002000000000000000344000006c0100002c000000030000006d400000980100002c0000000600020080400000c4010000980100000d000201614000005c030000600000000100000002800000bc0300006c0000000600020003800000
30352ms: crc mismatch; sz=228 got:499, exp:36624, f301e443e66038b7139d702fe03e8046446576530a6e29f110000f02050003000000000000000000000000000000000070000000c000000030010000b4040000e405000000000000e405000000000000e40500004000000024060000000000002406000000000000240600008c010000b0070000ec0000009c080000e8000000300100001c00000000000000504000004c0100002000000000000000344000006c0100002c000000030000006d400000980100002c0000000600020080400000c4010000980100000d000201614000005c030000600000000100000002800000bc0300006c0000000600020003800000
client: disconnected (1 clients)
deploy to FE87
Deploy error: no ACK for FE87/62[3]: 0x2c09 sz=224: 5d40010015800100000000006240010016800100...
build src/main.ts OK
deploy status: no ACK for FE87/62[3]: 0x2c09 sz=224: 5d40010015800100000000006240010016800100...
deploy to FE87
Deploy error: timeout (3000ms) waiting for response to FE87/2[1]: 0x80 sz=4: a0090000
build src/main.ts OK
deploy status: timeout (3000ms) waiting for response to FE87/2[1]: 0x80 sz=4: a0090000

later it all started blinking, reconnecting and behaving unpredictable, but in the end pico disconnected itself and only simulator stayed.

from devicescript.

Also, another thing with transports - when any of native transports is enabled then it looks like it causes errors on dashboard side and you are unable to connect both from native and WebUSB side. So, maybe there should be some kind of switch in cli which tells which transport user wants to use, and by default it can be websocket. When websocket is enabled we leave configuration and connection to the dashboard via WebUSB, and when any native transport is enabled we disable connection in dashboard and use native one. WDYT?

from devicescript.

@pelikhan I just opened small pr to improve flow with native transports #653

from devicescript.

I've simplified the devtools page as a lot of the content was quite outdated (it was built pre-vscode).

from devicescript.

I've rephrased the "no devicemanager found" messages and added an entry in errors.mdx.

53b3d2d

from devicescript.

More docs about the flags at 207858a

from devicescript.

essentially devtools can act as a bridge between browser + webusb/webserial and the cli.

Now that is interesting :)

the devtools -> webusb route which is surprisingly more reliable.

This is a shame and probably due to the winusb support in chrome versus only libusb in node-usb.

from devicescript.

@dawiidio closing, please reopen if we still need to improve this.

from devicescript.