Integrate with esp8266/Arduino

[probonopd]

Great project - I hope it can be nicely integrated with https://github.com/esp8266/Arduino (e.g., to do the uploading and "serial" monitor using just the ESP and no serial adapter).

I also cross-posted this at esp8266/Arduino#2375

[cnlohr]

This should be able to fit fairly well, but there's a lot I don't know. Only thing I'm kind worried about is the way my reflasher works is it uses a scratchpad, verifies, and then flashes itself. If something goes wrong or you break the USB interrupt, you would have to go back to serial flashing to get the thing recovered.

Another big recommendation is I know people would probably want to turn this into a CDC device, but I really believe using control messages is the best way to stage data back and forth. It sidesteps a lot of problems with endpoints and keeps things really organized.

P.S. Right now my focus is on two other aspects of the project. (1) Demoizing the project and (2) Trying to get USB 1.1 Full Speed working. I still don't know if #2 is possible, but I am going to keep my focus there.

I also can continuously work to shrink my code size.

Who all knows much about how to set up bootloaders, etc?

[bitluni]

Just realized igrr (https://github.com/igrr) the main contributor of esp8266/Arduino is sitting at @espressif. He probably can help you with your Full Speed ambitions (interrupt/dma issues and what not)

[cnlohr]

I just made a post on their forums (though it looks like posts have to be approved) How would I go about requesting this from him? Should I be requesting it of him directly? I know RichardS said he's already on trying to get that info, too.

[bitluni]

Hmm, I don't know how to get the info you need the best. It was just an observation..
Maybe it could be a start to formulate exactly what you need in a separate ticket so we could start to gather what you need. I could take a look the existing code from other projects..

[cnlohr]

Hmm, right now things are a bit stalled before we can COMPLETELY rule out full-speed... at least on my end, but I'm not sure what needs to happen arduino-end to start support of this project.

[probonopd]

Is asking @igrr for information still a bottleneck? In my experience, he is very approachable, helpful and friendly and is online on https://gitter.im/esp8266/Arduino most of the time.

[igrr]

The main thing which needs to happen on Arduino end is making decisions :)
For example, do we want USB stack running only in second stage bootloader (eboot) or in the application as well? If it runs from application code, we probably need to use same USB API which is used by other Arduino boards. We can probably reuse their code, but need to decide what subset we want to support. If it runs in bootloader, do we use some fixed delay there? Or maybe we can detect if USB cable is plugged in and avoid delaying if this isn't the case? Also, do we want espusb code to be updatable over usb? Do we want the update to be fail safe, or can we expect the user to fall back to serial upload if things go wrong? Answers to these questions will determine implementation on our end, which in case of bootloader-only espusb support should be quite straightforward.

Regarding the espusb code itself, I think it would be nice to package all usb-related code into a self-contained module (static library) with a well-defined API. I can understand that some hacking and exploration needs to happen first, but once they are finished some cleanup and refactoring would be much welcome. That would make it easier for others to use this project within other applications/frameworks as is, for example by adding it as a git submodule.

Regarding additional info about hardware features of the 8266, i think Angus has already given a series of replies on the 8266 community forum. If there's anything else you want to know, please ask.

[probonopd]

Thanks @igrr for chiming in. I am by no means an expert so in the end it is @cnlohr and @igrr making the decisions, but since I started this thread, I would like to offer my perspective from an user's point of view.

Why do people love Arduino? Because it gets us producive extremely fast, without having to worry too much about the low-level infrastructure. Hence, I see 2 main use cases for espusb in esp8266/Arduino:

1. As a user writing a sketch, I want to be able to attach an ESP8266 to my PC for flashing without the need for a USB-to-Serial bridge (just like I can attach and flash an Arduino Leonardo). It is desirable for this to be as robust as possible, meaning that whatever bad sketches I flash, I can always be sure that USB flashing will still work. Ideally I install the code that does this only once (via another flashing mechansim such as serial or a flash chip programmer) and from thereon can always only use USB for flashing sketches. I don't have the desire to flash the flashing code itself over USB (as I assume once it works I will never have to worry about it again - 99,9% of Arduino Leonardo users will never have looked at the code that does the USB flashing). I do not want to "pollute" my .ino sketches with this functionality (like with Arduino Leonardo, where I don't have to change the sketch specifically to make USB flashing work).
2. As a user, I want to be able to use USB functionality inside my sketch (e.g., to make it act as a CDC device, USB HID device, or whatever). For this, I want the code that sets the USB device IDs and all the rest of the functionality in my .ino sketches (possibly using functions that look like https://github.com/gloob/vusb-for-arduino).

Whereas it would be elegant to have the code for 1 and 2 combined in just one place, I wouldn't worry to much about having 2 separate copies of the USB code (one in the core/bootloader, one included into the sketch), since with 4 MB of flash, who cares.

[cnlohr]

@igrr I wish I had an opinion on the subject. I really don't know what's best, either, regarding where the bootloader should be, and the timeout, etc. I would be concerned to let it boot too quickly, since it may take a bit for the device to enumerate and a PC task to catch it if you want it to stick around in the bootloader.

I tried finding some spec for usb bootloading and didn't find one. I still much prefer use of control messages over just about anything else.

I am going to continue refining the main espusb project, now that I am putting the full-speed stuff on hold, indefinitely (unless espressif comes back with something). I have some updates just committed in 90e8a22. I will be splitting the code apart so the per-device stuff is separate from usb.c. Right now, endpoints are handled externally, but descriptors and custom control messages are in there. Most of this can be done in parallel - both work on Arduino and my work. Especially if it results in specific requests for changes to my code.

P.S. It's currently ~8.1 seconds to flash to the scratchpad via usb and another 2 seconds to copy it over and reboot.

All that said... I am not a fan of CDC devices. And, I don't even know if they're supported on all OSes in low-speed mode.

One other thing that is convenient. I do have code now that causes the bus to re-enumerate.

[cnlohr]

I am getting very close to what I want for the "library"

Right now, usb.h, usb.c, usb_asm_1bit.S and usb_table_1bit.h are all librariezed. All of the descriptors, custom behavior, etc. is located elsewhere. Current usage:

Total SRAM: 232 bytes + Descriptors, 317 bytes (Could be stored elsewhere)
Total Flash/IRAM (Only iram, tables and usb_init can be stuck in slow flash): 1422 bytes

If only a bare minimum USB device is needed, could be smaller yet, but not by too much.

[probonopd]

Ping @igrr your input is appreciated.

[igrr]

For the bootloader mode, this amount of RAM is not an issue, while for the application the amount of iram required may be a problem. We don't have many options for stuff to move from IRAM to flash to free up some space.

Next step would be to integrate espusb files into bootloader.

[cnlohr]

Would we do it where I have some code that just all lives in IRAM - then somehow, when it decides to boot, it loads the program off a different place on FLASH into IRAM and boots it?

Right now, I do use library calls for a few things like memcpy, and setting up the inputs to be GPIO instead of special functs.

[igrr]

I can add esp-usb to our eboot bootloader. It would be nice if there was a way to tell whether USB isn't connected at all (no cable) — and avoid loading espusb from flash in this case.

Memcpy is in rom, gpio_xxx functions are also in rom if I'm not mistaken. If there are any dependencies, I'm sure we will figure this out.

[cnlohr]

We could avoid use of interrupts and just poll for USB and/or serial? Do you use interrupts in eboot?
You can determine if you're connected by looking at D-. D+ will only change when the host decides to talk to you, which does seem to happen very quickly.

One of the biggest questions would be how long to wait if you are connected to a host. May take a while to know if the user wants their code to run and pretend to be a mouse vs they just haven't gotten their flasher running yet.

[probonopd]

This is how it is done in the Arduino Leonardo board:

Rather than requiring a physical press of the reset button before an upload, the Leonardo is designed in a way that allows it to be reset by software running on a connected computer. The reset is triggered when the Leonardo's virtual (CDC) serial / COM port is opened at 1200 baud and then closed. When this happens, the processor will reset, breaking the USB connection to the computer (meaning that the virtual serial / COM port will disappear). After the processor resets, the bootloader starts, remaining active for about 8 seconds. The bootloader can also be initiated by pressing the reset button on the Leonardo. Note that when the board first powers up, it will jump straight to the user sketch, if present, rather than initiating the bootloader.

Is it possible to use something similar to this existing Arduino behavior as a starting point? That is, by default boot into the sketch directly without a delay unless the reason for the reboot is known to have been triggered by the Arduino flashing procedure.

Here is the source code of Caterina, the bootloader used in Arduino Leonardo: https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/bootloaders/caterina/Caterina.c

[igrr]

As mentioned above, because of IRAM usage it is likely that we integrate esp-idf into bootloader only, but not in the app. In this case we can assume that if the device is plugged in, it should wait for upload. If it isn't plugged in, it skips esp-idf completely and starts up as usual.
What should we check for at D- line? Iff the device is not connected to the hub, it will be in some particular state?
Re Leonardo approach: probably not relevant because low-speed CDC device isn't really a thing which is supported on all OSes.

[cnlohr]

https://github.com/cnlohr/espusb/blob/master/user/usb.c#L224

I think this may be helpful!

So google can find this: This is a picture of a powered-off ESP8266 being plugged into USB. It takes a moment, but the host does talk to it and enumerates

Re: CDC, etc. Even a bulk endpoint, I'm OK with, but the problem I want to avoid is I just hate it when things are COM ports, so many driver issues and the like!

[probonopd]

Is there still some hope that this might happen some day?

[cnlohr]

I keep kicking the idea around, but, there's just SOOO much. I don't even know how to do the remapping of the IRAM stuff, so I'm pretty stuck at this point. Given a framework, I can totally write the USB code.

[probonopd]

Thanks @cnlohr, what exactly do you mean with a "framework"?

[cnlohr]

I can get messages to/from the host via USB, and detect when it's plugged in or not, but I don't know how writing to flash works realistically, where different things would live in flash, and how to actually boot into flash.

[probonopd]

@igrr can you help on the above? I think this would be a tremendous benefit for the whole platform.

[blackketter]

FWIW, I'd love to see support for the Arduino Serial, Mouse & Keyboard libraries on ESP8266 with this also. Not sure if that's harder or easier to implement.

[cnlohr]

No way to do serial, but things like mouse/keyboard/joystick shouldn't be hard. Really, though, I think a bootloader is the critical point!

[blackketter]

I agree, the bootloader and firmware updates are more important, but having USB support for Arduino applications would be very useful as well.

(I do realize that the native ESP8266 serial console wouldn't be possible but an application-level serial port should be, no?)

BTW: THANK YOU for this awesome work.

[cnlohr]

If you're using application-level stuff, you really really really should be using control messages rather than treating something like serial. Control messages allow you to say "Function 5, length 50, here's my payload" which is much better than handling framing, etc. yourself.

Back to discussion at hand: @igrr any ideas on how we could make this happen? Should I just make a super minimal make-usb-link thing that lives in IRAM? Or, is IRAM a bad thing when dealing with bootloaders?

[igrr]

From bootloader point of view, the following functions are needed:

• is_usb_plugged_in() should check if cable is connected
• usb_enumerate(void (*cb)(size_t size, const uint8_t* data)) should return when enumeration is successful. Callback function cb should be called whenever host performs a transfer.
• usb_transfer(size_t size, const uint8_t* data) should perform transfer to the host.
  I think this should be enough to implement firmware update.

All functions should live in IRAM, as we have plenty of it in bootloader, and we don't use flash cache there at the moment.

[cnlohr]

I'll work on this shortly. I am gonna see if I can do all this with as little of the SDK as possible.

I am thinking the transfer thing might be a little easier to use via global messages, since, data going in and out has to be done asynchronously. I.e. "I got this data last transaction" and "when you get around to it, please send this back to the host" unless I can just have loop continuously on my side...

[me-no-dev]

I looked a few times through the code, but I guess I'm used to different style USB programming (let's say v-usb, libusb and such) and could not at all understand where to hook and how to listen for packets or send any (same for bulk). I have libs and definitions for many devices and have written lots of USB code, but I guess it was not enough :(

[cnlohr]

@me-no-dev : The fastest way to talk to this thing is via libusb, using specifically control packets. I will admit it is a little weird, but I have a demo that runs on the USB side as well as topside to test data transfer speeds.

[me-no-dev]

@cnlohr I know what to do on the host side :) I want to be able to create different devices on the ESP, maybe even selectable which to start.
For example I have code for driverless HID devices, CDC devices, all standard input devices and so on, but have no idea how to convert it to this library and run it on the ESP.
I was expecting to have a callback of some sort to give the configuration blocks, callback for when a control packet is received, or bulk data (and bulk endpoint can be more than one) and also to be able to queue packets and bulk data for the host.

[me-no-dev]

@cnlohr maybe we can chat on gitter or something, where I can share some code with you and better explain :)

[probonopd]

@me-no-dev let's separate the discussion between the bootloader (i.e., flash the ESP over emulated USB) vs. "userland" (e.g., create different devices on the ESP from sketches, I have openend #24 for that).

[me-no-dev]

@probonopd it's the same exact thing ;)

[probonopd]

/me would like to see a YT live stream with @cnlohr @igrr and @me-no-dev :-)

[me-no-dev]

@probonopd if I am able to do what I wrote above, neither the Host side, nor the ESP side would be a problem for bootloader uploading. Maybe even exactly emulate Arduino (with resetting to bootloader and uart) as I have done it before on AVR and STM32

[cnlohr]

@me-no-dev Unless you know how to get CDC to run over low-speed USB, it's going to be difficult. Do you? Because that would totes be rad!

Callbacks aren't quite what you'd expect, but they are close. This has to do with needing to reply on the USB bus IMMEDIATELY. It is similar to V-USB that way... The facility is sort of there, though. For example...

In bootloader/main.c, line 34... it does handle control messages kind of like what you're after.

void usb_handle_custom_control( int bmRequestType, int bRequest, int wLength, struct usb_internal_state_struct * ist )
{
	struct usb_urb * s = (struct usb_urb *)ist->usb_buffer;
	struct usb_endpoint * e = ist->ce;
	struct USBControlStruct * cc = &cctrl;

	if( bmRequestType == 0x80 )
	{
		if( bRequest == 0xa0) //US TO HOST "in"
		{
			if( cc->length_ret )
			{
				e->ptr_in = cc->ret;
				e->size_in = cc->length_ret;
				e->transfer_in_done_ptr == &cc->ret_done;
				if( wLength < e->size_in ) e->size_in = wLength;
				cc->length_ret = 0;
			}
		}
	}

	if( bmRequestType == 0x00 )
	{
		if( bRequest >= 0xa0 && bRequest < 0xc0 && cc->length_acc == 0 ) //HOST TO US "out" Only permit if we've already cleared out the message.
		{
			cc->acc_request = bRequest;
			cc->acc_value = s->wValue;
			cc->acc_index = s->wIndex;
			e->ptr_out = cc->acc;
			e->max_size_out = CUSTOM_BUFFERSIZE;
			if( e->max_size_out > wLength ) e->max_size_out = wLength;
			e->got_size_out = 0;
			e->transfer_done_ptr = &cc->length_acc;
		}
		else
		{
			e->ptr_out = 0;
			e->max_size_out = 0;
		}
	}
}

BUT!!! Keep in mind, this code has to execute /very/ fast! Code a little further on in main() is what actually handles the transaction.

		if( cc->length_acc && cc->ret_done ) //XXX Todo: Make sure our response was received.
		{
			switch( cc->acc_request )
			{
			case 0xa0: //Echo
				ets_memcpy( cc->ret, cc->acc, cc->length_acc );
				cc->ret = usb_custom_ret;
				cc->length_ret = cc->length_acc;
				cc->length_acc = 0; //Clear out the incoming data once done processing.
				printf( "/%d MSG:%s %d %02x:%04x:%04x\n", cc->length_acc, cc->acc, usb_internal_state.there_is_a_host,cc->acc_request,cc->acc_value,cc->acc_index );
				break;
			case 0xa1: //Read RAM.
				cc->ret = (uint8_t*)((cc->acc_value<<16) | cc->acc_index);
				cc->length_ret = cc->length_acc;
				cc->length_acc = 0;
				break;
			case 0xa2: //Read FLASH
			{
				int toread = (cc->acc_value>>8)*16;
				int addy = (((cc->acc_value & 0x0f)<<16) | cc->acc_index)*4;
				cc->ret = usb_custom_ret;
				SPIRead( addy, (uint32_t*)cc->ret, toread );
				cc->length_ret = toread;
				cc->length_acc = 0;
				break;

I won't be free until Wednesday, late or maybe Thursday :-/

[SpiraMirabilis]

Most OSes will be fine with a low speed USB CDC device, even though it technically breaks standard since bulk endpoints are forbidden. I'd be more worried that you can't guarantee any real time compliance since the esp steals cycles for its wifi functions.

[me-no-dev]

bulk endpoints are not forbidden, but are rather limited in amount of data and frequency of polling, which in reality makes only bauds below 57600 or so work (do not remember what I had calculated). Bulk endpoints are used in many/most low speed usb devices :) Please correct me if I'm wrong

[cnlohr]

It would not enumerate my serial CDC device at all. Something about "insufficient bandwidth" even when I wasn't even using the bulk endpoint. Anyone know if there's any "trick" around this?

EDIT Anyway, sounds like control messages make much more efficient use of the bandwidth!

[me-no-dev]

@cnlohr what OS did you try that on? BTW did you get my email?

[cnlohr]

@me-no-dev - Yes, I got it. Things have been insane recently, and until MAGFest is over I don't think I'll get a chance to try it. I was running on either linux 3.x or 4.4. I did notice your descriptors were different than mine. When you tested it, did it work in Windows. Is it okay for you to post the zip here so @leopck can give it a crack?

[leopck]

Would be great if I could get more leads to this, since I've been stuck at this issue for a while.

EDIT: I got it to enumerate, but it shows these errors.

I've been getting this issue and I can't go over it. Any ideas?

[ 1331.845052] ------------[ cut here ]------------
[ 1331.845068] WARNING: CPU: 7 PID: 862 at /build/linux-a2WvEb/linux-4.4.0/drivers/usb/core/urb.c:449 usb_submit_urb.part.6+0x142/0x560()
[ 1331.845072] usb 2-1.2: BOGUS urb xfer, pipe 3 != type 1
[ 1331.845075] Modules linked in: cdc_acm cp210x usbserial rfcomm drbg ansi_cprng ctr ccm bbswitch(OE) bnep nvidia_uvm(POE) nvidia_modeset(POE) nvidia(POE) arc4 snd_hda_codec_hdmi snd_hda_codec_realtek ath9k snd_hda_codec_generic intel_rapl ath9k_common x86_pkg_temp_thermal uvcvideo ath9k_hw snd_hda_intel snd_usb_audio intel_powerclamp videobuf2_vmalloc coretemp videobuf2_memops snd_usbmidi_lib kvm_intel snd_hda_codec ath videobuf2_v4l2 snd_hda_core mac80211 videobuf2_core snd_hwdep btusb kvm v4l2_common snd_pcm btrtl snd_seq_midi videodev btbcm snd_seq_midi_event btintel snd_rawmidi media bluetooth cfg80211 snd_seq irqbypass crct10dif_pclmul snd_seq_device crc32_pclmul snd_timer jmb38x_ms memstick mei_me snd joydev input_leds mei soundcore shpchp lpc_ich serio_raw cryptd binfmt_misc ideapad_laptop
[ 1331.845172]  sparse_keymap mxm_wmi wmi mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid hid i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops psmouse sdhci_pci ahci drm sdhci tg3 libahci ptp pps_core video fjes
[ 1331.845215] CPU: 7 PID: 862 Comm: ModemManager Tainted: P           OE   4.4.0-36-generic #55-Ubuntu
[ 1331.845220] Hardware name: LENOVO 20090                           /Base Board Product Name, BIOS 47CN28WW(V2.06) 06/14/2011
[ 1331.845224]  0000000000000286 00000000aa160979 ffff8802097fba08 ffffffff813f13b3
[ 1331.845231]  ffff8802097fba50 ffffffff81d486b8 ffff8802097fba40 ffffffff810810f2
[ 1331.845236]  ffff88010c30c0c0 0000000000000003 ffff88017a991800 0000000000000000
[ 1331.845242] Call Trace:
[ 1331.845255]  [<ffffffff813f13b3>] dump_stack+0x63/0x90
[ 1331.845263]  [<ffffffff810810f2>] warn_slowpath_common+0x82/0xc0
[ 1331.845269]  [<ffffffff8108118c>] warn_slowpath_fmt+0x5c/0x80
[ 1331.845284]  [<ffffffff81618802>] usb_submit_urb.part.6+0x142/0x560
[ 1331.845289]  [<ffffffff81618c82>] usb_submit_urb+0x62/0x70
[ 1331.845297]  [<ffffffffc073020b>] acm_submit_read_urb+0x3b/0x80 [cdc_acm]
[ 1331.845304]  [<ffffffffc07330b6>] acm_port_activate+0x186/0x1e8 [cdc_acm]
[ 1331.845310]  [<ffffffff814f3a7e>] tty_port_open+0x8e/0xe0
[ 1331.845317]  [<ffffffffc0730d03>] acm_tty_open+0x33/0x60 [cdc_acm]
[ 1331.845324]  [<ffffffff814ebfff>] tty_open+0x11f/0x6b0
[ 1331.845331]  [<ffffffff81211b8f>] chrdev_open+0xbf/0x1b0
[ 1331.845337]  [<ffffffff8120acef>] do_dentry_open+0x1ff/0x310
[ 1331.845341]  [<ffffffff81211ad0>] ? cdev_put+0x30/0x30
[ 1331.845346]  [<ffffffff8120be84>] vfs_open+0x54/0x80
[ 1331.845352]  [<ffffffff81217aeb>] ? may_open+0x5b/0xf0
[ 1331.845358]  [<ffffffff8121b667>] path_openat+0x1b7/0x1330
[ 1331.845365]  [<ffffffff8121d9d1>] do_filp_open+0x91/0x100
[ 1331.845371]  [<ffffffff8122b266>] ? __alloc_fd+0x46/0x190
[ 1331.845377]  [<ffffffff8120c258>] do_sys_open+0x138/0x2a0
[ 1331.845383]  [<ffffffff8106b544>] ? __do_page_fault+0x1b4/0x400
[ 1331.845389]  [<ffffffff8120c3de>] SyS_open+0x1e/0x20
[ 1331.845395]  [<ffffffff8182dfb2>] entry_SYSCALL_64_fastpath+0x16/0x71
[ 1331.845400] ---[ end trace 53721cd36948f595 ]---

[me-no-dev]

@cnlohr please feel free to forward the zip to @leopck. Since we are talking about devices that actually break specs, it could be that the kernel is patched, though I doubt it on linux.

[me-no-dev]

@cnlohr about "code has to execute /very/ fast!": you should be able to NACK a couple of times and then give the answer. Maybe you can use a queue for responses and send those or NACK if none.

[cnlohr]

Actually, Micah in a different thread on Twitter pointed out you can pre-emptively ACK as well, but, based on my traces that might not be the best move. At low-speed I think we'll have time, just not to go and do a ton of stuff. EDIT: zip was forwarded to @leopck

[atc1441]

I know it's a dead thread but i would be very nice if you guys still working on this. I tried to port it myself but it's too hard for the first time of doing this

[devyte]

@cnlohr your README says that SDK >= 2.0 are incompatible. We (Arduino) are currently at SDK 2.2+.
What is the reason for the incompatibility?

[cnlohr]

The reason originally was because the new SDKs use up precious IRAM. Espressif indicated this was something they would consider reducing in the future. I have not tried a new SDK to see if they have reduced their IRAM footprint. If they reduced it, then it will work A-ok!

[SpiraMirabilis]

The newest SDK still uses too much RAM. Emulating USB via software is right on the edge of the capabilities of this device. I've switched to ESP32 for some projects, although the disparity in cost is a bit of a pain. ESP8285 is my favorite price point/size/speed microcontroller of all time, though.

…

On Wed, Feb 28, 2018 at 12:44 PM, CNLohr ***@***.***> wrote: The reason originally was because the new SDKs use up precious IRAM. Espressif indicated this was something they would consider reducing in the future. I have not tried a new SDK to see if they have reduced their IRAM footprint. If they reduced it, then it will work A-ok! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABf2gLnj0OdxOHHGS0ghDFAiD1V5y_mLks5tZayogaJpZM4Jewxs> .

[cnlohr]

It's so frustrating cause it would be so easy for them to move more stuff out of IRAM... Even an extra 250 bytes would make it so much easier.

@SpiraMirabilis How much is it overflowing for you?

[devyte]

@cnlohr I took a look at the code in this repo, and it looks rather alien to me. Can we discuss directly? I'm on gitter.

[cnlohr]

I'm not really gonna have a ton of time to dig into this for a bit :(

[devyte]

@cnlohr have you gotten back to this at all? A lot has changed since I last looked, including:

• an effort to free up IRAM (maybe sdk2.x is now viable?)
• a precache tool which preloads a function into the cache so that during its execution there is no fetching from flash. In certain cases, this allows not using IRAM for that function.

[cnlohr]

I have not examined this at all. Would be cool if someone else could take this and run.

[devyte]

@cnlohr well, I've been looking for a while now for someone to do that, but I haven't found anyone who understands both usb and asm, and also has the interest and availability to pursue.
I'd love to see your work here be wrapped into a library in our Arduino core and have e.g. flashing over this usb interface and allow boards that don't have the serial2usb chip at all.
I'll continue looking for someone if you can't continue this work at this time.

[cnlohr]

@devyte honestly, you shouldn't need to touch any of the ASM... You WILL need to know some basic USB, especially to make apps on the host side to talk to the things. Maybe there's something I can help with. You can contact me directly if you'd like an easier back-forth support.