Most recent activity
-
The original espruinio only has a total of 2240 variables
>process.memory() ={ "free": 2220, "usage": 20, "total": 2240, "history": 0, "gc": 0, "gctime": 4.05120849609, "stackEndAddress": 536910432, "flash_start": 134217728, "flash_binary_end": 237128, "flash_code_start": 134459392, "flash_length": 262144 }whereas the pico has 5100.
While I own 5 Picos, all except one are in use currently. And the one not in use does not have the right headers (pins vs. sockets) to connect it straight forward. I either have to solder new headers or get new connecting cables. And/or rework the code so that it can live with what it offers.
I also have a ESP32 dev board somewhere, but I do not have much experience with ESP32. There might be other issues.
-
I think the problem is that I need it for development. Quote:
Because this requires preparing the EEPROM in advance, it's utility may be limited to code which does not change often.
As this is work in progress, I currently need to test it often.
To get around the issue for the end-users I think I need to break the developed modules down in the end. This will certainly break the modular in favor of something like a "max3421UsbHostHID" or "max3421UsbHostStorage" or whatever is needed. Then I can remove unused constants and/or us the constant values directly.
The user will have less options to get their hands on the USB protocol, but at least they can use the devices (otherwise they might run out of memory just for connecting the external USB device).
In my case I would also need to have some code on top which takes care of processing the data I retrieved over USB.
-
Today I have advanced the development, but I guess I'm running out of memory. At least if I want to write the library very clearly (that is with meaningful variable names and constants).
In particular the constants seem to eat a lot of memory, but if I do it without, I probably loose track pretty soon as the USB specification isn't really trivial.
It would help if there is a way that the minification could replace constants by its value. So that "C.USB_SETUP_RECIPIENT_INTERFACE" would become "1" (its value).
In the end these names would be necessary as the user would need this as well in order to customize the code for dedicated USB devices.
What I have done so far is to start initializing the device and querying some basic device properties (description). Still very basic, but some constant progress.
I think I can gain some memory, by switching from the original espruino to the pico, but that would only solve it for the moment.
-
I already connected an old keyboard to my test setup, but didn't found the time so far to go further than that. In fact - as you mentioned - some basic module for USB Host handling could be written easily. From there it should be fairly easy to get some keyboard demo working.
There are just a few questions left from my side:
Can I require another module from within a module? I have found something like that in the touchscreen example, but I'm not aware issues with this approach. The touchscreen example implicitly pre-connects the ADS7843.
Rather than this, I'd like to have something like passing an interface to the usb-host module. The code should look something like:
var USBHost = require("USBHost").connect(require("max3421").connect(SPI1, A0, ...));in the end.
Within the module I would need a way to determin what module has been passed. If it is of type max3421 it use this internally.
This would have the advantage to write the code of USBHost as independend and reusable as possible.
Alternatively, I could write a module named USBHostMax3421, which kind of inherits from Max3421. The initialization would look like this then:
var USBHostMax3421 = require("USBHostMax3421").connect(SPI1, A0, ...));This is probably easier in the beginning, but less flexible in the long run.
Also I'm not sure how to handle interupts and gpio querries. The original arduino code uses a loop to check periodically for 'tasks'. With Espruino this translates to watches, doesn't it? If I use them, are there known issues in regards of the use in modules?
And one last question. The original code uses delays at some point to wait that some capacitors are fully loaded. So far I have translated the code directly using some time burning hack. While the time is very little (60ms), I'd like to get rid of this. Now I wonder whether there are better alternatives?
The only alternative that comes to my mind is using callbacks like:
init(onSuccess, onFail)but that bloats the caller code and requires some more handling on that part.
Or should I use promises? While they look very smart, I tend not to use them in my web projects, because they used to be not fully supported by some browsers.
-
A wise decision. While the MAX3421E module is mostly working, it is mostly not just more than this. This means that it doesn't do much USB handling on its own so far. And for this reason it's yet untested (as there isn't much outer code available so far).
The original author and developer of the breakout board has decided to split the code into some files for accessing the MAX3421E chip on the one hand and files for USB handling on the other side. To me, this makes sens as it allows to create independent USB access solutions. As far as I have seen they can range from simple to complex and think it doesn't make sense the add more overhead than necessary.
So in my opinion, it would make sense to have this small MAX3421E module as base and several other libraries (separated by purpose) on top of it.
For the moment, some example code would probably be satisfying. Something that could later be expanded to a module. However, I fear, that even a simple device such as a keyboard, might at least introduce quite some more basic code, as all the USB enumeration and accessing needs to be done.
It's in the range of about 2-3 days of work, but personally, I can not make it this week. So you probably want to keep it open a bit longer, maybe.
-
Luckily, the device wasn't dead an thus I was finally able to make it work now. I have created a pull request to get the basic header translation for the MAX3421 ready. It's not much useful so far, as the USB enumeration and such still has to be done from external code, but at least it is now easier to get started.
-
I guess the board is really dead as there is no change on the MISO pin regardless what I do. It's always HIGH. I'm not sure what the wrong pin did, but maybe the second board I ordered will work. Hopefully it will arrive soon as I'm now into it.
-
A long sleep did help to find out that I did not connected everything correctly. The cheap board from china had one label printed one pin too far to the left. Eventually I even bricket that board, but that needs to be tested.
After some refactoring and with the "direct to flash" option, I do now have enough ram available to keep going. And if not I can still switch to the pico...