Search results for:

BTW, would there be anything gained from using something like MOD-WIFI-ESP8266-DEV ?

Just as a comment, as much as I am a big fan of the interactive console on Espruino, basically making me using screen instead of the Web IDE very often, I could imagine living without it for this application/implementation if that's needed to make the whole idea work on the ESP.

I could imagine the chip getting more memory in the future anyway, as other projects might have similar demands.

Great project, that I wondered if it might be possible, when playing with the ESP and hating at the serial comms between pico and Espruino. After all, those three letters also being the first three of Espruino can't just be a coincidence...

Today I managed to kill the com port with a single save(), so...
I flashed the older firmware again and don't use the pico on a mac for the time being.

Tried again with a single save() after pushing the code via the IDE (instead of another/second save()), which seems to work.

So the multiple HID config might be the culprit, as you suggested.

Hm, missed a whole page of discussion before posting... Sorry.

Same here when working with the linked firmware. I had the com port disappearing several times after a save() and only a firmware re-flash would bring the Pico back. (which is the only thing I came up with, at least)

Don't know if this is only for dual saves (one for the basic HID code, on after actually setting up app data on the device).

Creates a bit of dev cycle overhead thru firmware flashing ... :)

I already was holding still :) When I read over the HID pdfs and found the config descriptor with its mouse and keyboard entries after our last chat, I didn't ask since setUSBHID already has that keyed list as a parameter that allows for more than the reportDescriptor entry...

I am personally looking forward to 1v80 and anything USB related (an "intelligent" mass storage device?). I just wanted to voice that opinion again, like others, that your idea of adding USB was cool and fits the product well and should no be seen as a annoying step child just because it comes with all those funny new demands from the implementation and from the forum once you opened that box.

I see the forum's interest as a good sign for the Pico and Espruino, actually.

And what did you expect when adding that USB connector right to the board :)

-Stev

We definitively need another graph for good advice, opinion and complains. It's just a question of pushing the right values...

Other than that, the None config descriptor works well on my mac, eliminating the probs with ghost mousing while typing (Edit: I also assumed the scaling prob for tablet mode being gone, but I was testing on the wrong machine...).

Very cool.
Stev

As always I'll add my vote for better general USB support.
BTW, I am still having problems with the Keyboard HID implementation on all of our macs, which triggers some mouse events in addition to the keystrokes (unfortunately also mouse button events, which trigger the context menu, which in return keeps the keystrokes from being handled...). I don't have that problem on windows.

As far as I understand there might be more descriptors needed than the report descriptor.

Concerning MIDI, I would think that it's another thing beyond getting HID right, as it seems to need an even more general implementation. I also see that this feels like a huge amount of study and implementation.

Still, I would like to encourage any work on the USB client implementation as it seems a pretty obvious application area for the pico to me. I would have gone Teensy (LC) if I hadn't that stubborn believe in Espruino's programming model (combined with that low footprint of this projects HW implementation). I'd really like to see USB being a No. 1 citizen on this project.

-Stev

Hm, well, same problem here. USB is just too much to do in between other work.
But thanks for the links, that might save some time at some point.

so I can't spend days implementing stuff just because it might save you a bit of time.

Well's it's a forum, so it's just my need posted. If that's something others are interested,too... the attractiveness of a tool is always measured by the amount of time and energy it saves. If it's just mine, you're right, of course.

Hm, I had a CDC matching warning under OS X 10.8 which seems to be gone with 10.9, but I wondered if the needed USB drivers for Windows are needed since the matching of the composite device doesn't work and whether this would improve by having more control about what's visible and what's not or how it will present itself.

Just exploring the different approaches of (USB) driver architectures as I have problems with another (Odroid C1) device that won't be matched correctly.

Frankly I'm a bit annoyed by the vast amount of information on a problem space that I would rather skip in favor of the application, so I was curious if there's any way cheat a bit on the device side to get there.

Hey,

any progress/plans in hiding the STM serial port or making the composite device look more like known ones?

-Stev

Hey,

I re-compiled everything. Fortunately the makefile quality just had improved back then... The main issue was to get the tool chain set up on my mac and to flash the HY32 which had some timing issues with the mac drivers.

I can look up the files if you need anything. Should have them somewhere.

Ok, I'll update the module. Very interesting that a plug in device can
crash the UI! :o

Yes, indeed. OTH, it could do all kind of weird things. Have to look at the logs to see if someone complained.

As you say, I doubt the clipping/offset is anything Pico-related - the
data sent from the Pico obviously doesn't have anything done to it (it
works fine on Linux), so I wonder whether your Macs have some kind of
'calibration' that's applied?

Probably. The irritating thing is, that I have no idea what and where. The other Macs work fine. The "less offset" things was due to a param change. I have just one strange Mac in the group :)

Very strange about the keyboard example and the context menu - I
actually tried that on a Mac and it worked great.

Low sample count issue :)

Hm, lost my prepared comment in the editor ;/ Again...

I changed the report descriptor in the USBTablet module to signed values (0xFF, 0x7f) for the logical maximum and changed the send function accordingly. Which seems to work.

However I see some offset of my monitors origin (about 2500..2600 logical units) for top and left, resulting in a clipped circle. This only occurs on one of our Macs, on another with less clipping, on another without (just the vertical values are clipped due to the difference in height vs width in pixels). Just to make clear that this might not be the fault of the Pico when it occurs. Might be some kind of touch pad or multi monitor setup that triggers that. Can't say.

However, the physical minimum/maximum value only seem to be information on the theoretical input device behind it. They don't seem to have any effect (like a movable and scalable value window, as one might expect). At least on the mac without any tablet driver they seem not to be taken into account.

The tablet example keeps logging me out of my Mac :) Probably kills's the UI.
From a quick search it seems that the values in the HID setup should be signed numbers while the module uses unsigned ones for the physical and logical limits. Those might just not be looked at in the relative mouse example (which works fine :).

The kb example triggers the context menu. Haven't looked at that module, though, yet.

Ah, so good. Especially with the module and tablet. This build still needs external Battery or just the save()?

Nice link at the end. Lots of tinkering options :)

As a backchannel, eg for a software on the host, reporting certain state values, can one grab and use the console's serial port on the Espruino side for that so that data sent to the USB modem dev on the host would end up in some serial buffer on the Pico? I remember switching console from back then, but I don't know if that's still possible. I could of course set vars via the console via JS, but it would nice to define limited protocol on the board side.

Hoped it would be more work :)

To make up for that:

What's b (or first array param) in sendUSBHID() in the mouse example (or the general content of that data stream array for certain HID modes)? Or just: can this be zero for the absolute pointing device as well?

Ok, that would be cool. Though the hick-ups seem to get closer to "on every char" :)

"While you're at it"(TM), is there a way to have an absolute pointer device, too. Don't know if that's a mode/param of the mouse mode or a separate one.

Cheers
Stev

That's pretty neat.

Since I am missing the critical USB know-how: we have to enter some kind of HID mode which then will be reset when plugged in without power from the battery, or is this just another USB channel in parallel to the serial port?

Can this already be revoked in software or is the current way to toggle it by having it started up before plugging (HID settings active) or not (pure console mode)?

As I said, no idea on the "mode" model right now, but eager to try out.

Great addition to the Pico's dongle form factor.

I tried that throttle switch, but actually it works fine without that at the moment.

v80 and the current github builds should have USB HID, albeit in a
really basic form.

Ah, Just reflashed to 79 :)
Any docs on how to use the HID parts/what's there?

Hm, I had the same probs when I plugged the Pico directly into the Macbook. With the breadboard ... Shortbread...

Anyhow, I think it's the cumulation of little issues that bug me to death at the moment. Though that buffer thing is really ugly and uncotrollable (by hand, at least). I tried to upload the Modules by pasting and had to cut everything into such short pieces that even for those small modules it felt kinda stupid. Switched to the WebIDE in the end to upload the modules and save them, to then code in Screen again.

But if Gordon says "HID Support" and I won't need a Teensy for that, I am happy to wait. Tapping fingers...

Yes, soldering will be today's try to solve the issues. The fact that it sometimes worked and sometimes not at least points to doing so.

I have a 100uF capacitor somewhere in between which also should get a better position that way, as one of my ESP boards even managed to reset the Pico on Wifi connect. What is the typical capacity that should work with direct wiring? The shims are not yet available directly/from stock somewhere, are they?

For the console output, I have to connect/disconnect via the WebIDE's top left button (or re-connect screen) to get the output.

Also, I have the impression that the board does not continue to process if it can't get rid of it's output or has a "special mode" if powered by a computer with a potential serial connection in contrast to just being powered by a power source. It doesn't seem to do onInit or load() or might just be blocked by some filled buffer. This is of course just wild black box perspective. At least the buffers seem to get filled and dumped on connect/re-connect.

Ok. Seem's I ran into every re-noob issues that were available...

However, at the moment, I'm totally frustrated by the USB-Console breaking even in the WebIDE and comms to the ESP8266 working once, failing twice (that's just a metaphor, I'm afraid), despite delays and what not. Usually I don't reach the point where I could debug the actual app protocol since something already failed on the way to the AP connect. Now an then it works, but I will not be able to change and test something on the app's HTTP protocol level since I won't have a working connect for a long time and meanwhile I have to disconnect and reconnect the Pico's serial to get the output in the WebIDE. Don't know if it's me or the chip, but's costing hours right now.

I guess I will wait a few weeks and see how that evolves. Right now I wonder, if there's something generally broken with the serial comms, Console switching or something, not only on the USB side.

Maybe, I'll try with the original Espruino and the voltage regulator in the meantime. Will see...

I think so. I used the line from the Download page, which has a -k in it. If you didn't add that just today...

Back then I had huge problems with flashing the Hi-Mini from OS X until I wrote some code to control the timing/delays better and shorten the binary chunks. Maybe the IDE also uses some delays that help here? I tried flashing the Pico three times using the Python script (which all failed on verify) and then had the WebIDE succeed on first try. Unless it just ignores the result of the verification step :)