Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 32

Thread: When will Teensy marry ESP32?

  1. #1

    When will Teensy marry ESP32?

    It would be good to have the power, compilation speed, code base, support, community and fantastic design of the teensy ecosystem with the built in wifi capabilities and dynamic pin configuration of the ESP32.

    We spent 3 years developing our products on teensys, then we briefly switched to Particle and rapidly adopted ESP32, now, circling back to Teensy for ocasional use, makes one appreciate the quality of the teensy ecosystem, but the networking capabilities of the ESP32 means dont need to run any wires between our 15 sensor boards (apart from power), and wifi functions are right at our fingertips with no huge effort.

    We use the teensy on special occasions where we need the grunt or extra pins or the built in SD card reader, but built in wifi just trumps everything.

    I think it would be awesome to have a new teensy with builtin wifi. If others can do it so can we!
    I know there are lots of hurdles to adopting wifi, but it is becoming more ubiquitous now so in theory should get easier and easier to do.

    Just saying!

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,679
    Quote Originally Posted by jasper View Post
    I think it would be awesome to have a new teensy with builtin wifi. If others can do it so can we!
    I keep hoping NXP will incorporate bluetooth (or wifi, but BT seems really compelling) into these chips. But so far, nada. Who knows, maybe they will someday?

  3. #3
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,923
    Would be very nice if NXP did that - been hoping. They have some radio chips - other than one good enough to host the PJRC bootloader and Radio tied to MCU wasn't sure where the room/justification for it would be.

    Found Teensy and then tried pairing with ESP8266 - but that gets big and high power for a small battery device.

    ESP32 evolved to a dual-core 240MHz smaller chip PICO solution - just got some ESP32 TinyPICO units that show promiseto let me do what I considered years back … a Fall project at this point. That runs Arduino on both cores with RTOS features - where one core also does radio services. TinyPico is 1.3" long with radio and 10 pins per side and 0.7" wide. Quick tests look good - 1 core perf in neighborhood of K66. And it has LiPo charger and battery connect on board.

    One interesting thing on next version will be one LDO for ESP and then a second switchable LDO for 'external' device power {can be switched on/off programmatically when the FLASH is powered, i.e. ESP awake}. But that will be a single core variant with more I/O.

  4. #4
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    677
    In the past I used JeeNode and Moteino devices, for very low power, low baud rate communications. They worked pretty well, although not as standard (or power-hungry) as BT or wifi.
    For very sensitive measurements, it's often best to have the RF transmitters somewhere else, though.

  5. #5
    Senior Member
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    175
    I've been thinking the same thing, jasper. The Adafruit Airlift products https://learn.adafruit.com/adafruit-airlift-breakout look like a reasonable solution.

    I'm currently designing a board with a Teensy 4.0 that has a ESP32 module as a coprocessor, using the same wiring as the Airlift. I plan to to reprogram the ESP32 through the Teensy (or over the air via wifi). I'm mostly interested in the bluetooth functionality (for keyboard/mouse emulation), so I'll probably roll my own rather than using the Airlift's WiFiNINA-based firmware, which AFAIK doesn't do bluetooth. But if WiFi is what you are interested in, then WiFiNINA might be just what you need.

    If anybody's interested, I'll be putting the design up on GitHub and would love any kind of collaboration.

  6. #6
    Senior Member
    Join Date
    Apr 2017
    Posts
    189
    I use the heck out of these units. http://www.ebyte.com/en/product-class.aspx?cid=1&pid=1

    I find them low power, great range, and reliable. The company has a wide variety of types. I use the UART units and I wrote a library to simplify using and programming them.

  7. #7
    Paul, cant you squish a tiny wifi module onto the end of the Teensy 3.5 (drop the SD card reader) and give us an easy to use library?

  8. #8
    It would be useless without the SD card reader

  9. #9
    I hear you Elf but we have found the SD card reader is not as useful as we initially thought. Mostly it just sits there not being used.
    Customers dont really like fiddling with SD cards and removing them and re-inserting them on our boards underneath their equipment (drones, forklifts etc.). They want to see the data in Excel on their PC's emailed to them! (Darn customers, so demanding. )

    We find we only use the SD card reader in rare occasions when disconnected from the world , e.g. we use a teensy3.5 in a navigation system for an unattended solar powered boat. The SD card is really useful for logging info gathered on the boat: temperature, battery levels, status of the GPS modules, Iridium messages received etc, but in a world of wifi (which is where 90% of devices live), we don't need onboard logging, we log directly to a server.

    I know defragster likes low power, but , by inference, every single wifi router/access point in the world is within 20m of a decent power source, so low power is not a requirement, at least for us, we just run short power cables,

    Our needs are the speed, pins, capabilities and supporting ecosystem of the teensy with built in wireless, in an easy to use reliable package that we can just plug in or solder on if needed.

    Price isn't an issue either, we would rather pay $50 for a Teensy product and be able to trust it, than pay $10 for a no-name and continually be having to replace them in far flung places around the world , every time we have tried to save on initial purchase price we have paid 10 times over in courier fees and stress.

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,923
    Quote Originally Posted by jasper View Post
    I hear you Elf but we have found the SD card reader is not as useful as we initially thought.

    I know defragster likes low power, but , by inference, every single wifi router/access point in the world is within 20m of a decent power source, so low power is not a requirement, at least for us, we just run short power cables,
    ...
    Since the SD isn't part of what needed - that being optional is okay with me - needs a radio too.

    The ESP32 was really power hungry with WiFi ( and adding the Teensy ) - the ESP32 PICO looks better with Bluetooth and maybe even WiFi. Not having it built in and adding ESP8266 got too power hungry and large to fit a battery as needed to make it work with LiPo charger and other added together.

    Low power alone isn't worth anything - onehorse built a nice STM32 unit and the tiny 'spec' of space needed to add the LiPo charger made that cool in the couple I got - it was lower power but spec's closer to a T_3.2 - and still needed a radio.

    A Teensy with 'Bluetooth PJRC bootloader MCU' as noted would be nice if NXP made a suitable chip - and with that mystical PJRC MCU having a Bt stack running on it might even extend to PJRC Bt OTA programming of a Teensy. And if that fit displacing the SD socket it would be a real IOT winner.

    A Teensy 4 throttled down under 300 and maybe even under 200 MHZ beats the specs of an OC'd T_3.6 - that could drop enough power to run that Bt or BLE MCU - especially if some of the low power features of the T4 could be used and a ~300 mAh 'AAA' LiPo might last a couple of active hours.

  11. #11
    Member
    Join Date
    Mar 2017
    Location
    Oakland, CA, USA
    Posts
    90
    Now if we could just get a WiFi module onto an SD card... no idea how it would work (Eg. power requirements, API access, etc.), but Eye-Fi has a product with this.

  12. #12
    Senior Member
    Join Date
    May 2015
    Location
    San Francisco
    Posts
    175
    Quote Originally Posted by shawn View Post
    Now if we could just get a WiFi module onto an SD card... no idea how it would work (Eg. power requirements, API access, etc.), but Eye-Fi has a product with this.
    Funny, I was thinking the same thng.

    There are a number of wifi modules that use a SDIO standard as the interface to a host, but I think these are largely not used anymore. The EyeFi product was interesting but very proprietary.

    A better solution might be putting a SPI WiFi module on a PCB shaped like a uSD card and use the SD pins as an SPI port.

    A good candidate would be uBlox WiFiNINA modules that some Arduino boards (like the https://www.u-blox.com/en/product/nina-w10-series on the https://store.arduino.cc/usa/nano-33-iot board).

    Maximum power consumption is 500mA at 3.3v for that module, but I suspect you could dial that down in software by reducing transmit power or adding a wire to an external, higher-capacity power supply.

  13. #13
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,538
    Or Maybe just plug a WIFI dongle into a USB port?

  14. #14
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    379
    Using the USB port for Ethernet was something I wanted to look into, theoretically the Hi Speed usb host would be the fastest way to interface with an Ethernet controller wether wireless or wired.

  15. #15
    Senior Member
    Join Date
    Aug 2017
    Posts
    138
    Quote Originally Posted by KurtE View Post
    Or Maybe just plug a WIFI dongle into a USB port?
    I agree. Something I have been scoping out for for a while now
    Been playing with Ralink RT2870 wireless adapter.

  16. #16
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    I'm not sure if this exists but if there where an "SDIO - WIFI/ethernet adapter" then IMO the sdio port would be better than HS USB (4 time lower clock rate does mean less electrical problems)

  17. #17
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,538
    Quote Originally Posted by wwatson View Post
    I agree. Something I have been scoping out for for a while now
    Been playing with Ralink RT2870 wireless adapter.
    Let me know if you have something to play with. This is another area I thought would be good to have support for in the usb host code....

    @WMXZ - maybe, again not sure if they exist, and which board(s) you would hook up to? T3.6 through SDCard adapter, maybe easier/better with T4 as you have the pins available...

  18. #18
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by KurtE View Post
    @WMXZ - maybe, again not sure if they exist, and which board(s) you would hook up to? T3.6 through SDCard adapter, maybe easier/better with T4 as you have the pins available...
    a did a search and found

    Realtek RTL8723BS SDIO schnittstelle, WIFI + BT Bluetooth + WIFI modul
    https://de.aliexpress.com/item/32325303587.html

    so maybe it is worth to look harder
    obviously, T3.6 would need SDCard adapter

  19. #19
    Senior Member
    Join Date
    Aug 2017
    Posts
    138
    Quote Originally Posted by KurtE View Post
    Let me know if you have something to play with. This is another area I thought would be good to have support for in the usb host code....
    @KurtE:

    Spent this Sunday checking out three USB WIFI dongles and USB2LAN Ethernet dongle. YIKES! as Paul would say.

    Using Linux lsusb:
    The one Realtech WLAN adapter showed 4 endpoints. Three BULK endpoints and one Interrupt endpoint.
    The Ralink WLAN adapter showed 7 endpoints! All 7 endpoints are BULK type.
    The CISCO WLAN adapter showed 4 endpoints. Again three BULK endpoints and one Interrupt endpoint.

    The USB2LAN dongle showed 2 BULK endpoints and 1 Interrupt endpoint. This where I have started (Only 3 endpoints to deal with).
    I have been reading the 'usbcdc11.pdf' reference manual and I am thinking that the Interrupt endpoint could be a notification endpoint.

    I modified the MSC claim function to adapt to two BULK type endpoints and one Interrupt type endpoint.

    Here is what I have so far:
    Code:
    /* USBEthernet Teensy36 USB Host Ethernet library
     * Copyright (c) 2019 Warren Watson.
     *
     * Permission is hereby granted, free of charge, to any person obtaining
     * a copy of this software and associated documentation files (the
     * "Software"), to deal in the Software without restriction, including
     * without limitation the rights to use, copy, modify, merge, publish,
     * distribute, sublicense, and/or sell copies of the Software, and to
     * permit persons to whom the Software is furnished to do so, subject to
     * the following conditions:
     *
     * The above copyright notice and this permission notice shall be
     * included in all copies or substantial portions of the Software.
     *
     * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
     * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
     * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
     * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
     * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
     * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
     * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
     * SOFTWARE.
     */
    
    //ethernetDriver.cpp
    
    #include <Arduino.h>
    #include "usbEther.h"
    
    #define print   USBHost::print_
    #define println USBHost::println_
    
    // Big Endian/Little Endian
    #define swap32(x) ((x >> 24) & 0xff) | \
    				  ((x << 8) & 0xff0000) | \
    				  ((x >> 8) & 0xff00) |  \
                      ((x << 24) & 0xff000000)
    
    void ethernetController::init()
    {
    	contribute_Pipes(mypipes, sizeof(mypipes)/sizeof(Pipe_t));
    	contribute_Transfers(mytransfers, sizeof(mytransfers)/sizeof(Transfer_t));
    	contribute_String_Buffers(mystring_bufs, sizeof(mystring_bufs)/sizeof(strbuf_t));
    	driver_ready_for_device(this);
    }
    bool ethernetController::claim(Device_t *dev, int type, const uint8_t *descriptors, uint32_t len)
    {
    	println("ethernetController claim this=", (uint32_t)this, HEX);
    	// only claim at interface level
    
    	if (type != 1) return false;
    	if (len < 9+7+7+7) return false; // Interface descriptor + 3 endpoint decriptors 
    
    	print_hexbytes(descriptors, len);
    
    	uint32_t numendpoint = descriptors[4];
    	if (numendpoint < 1) return false; 
    	if (descriptors[5] != 255) return false; // bInterfaceClass, Vendor Specific
    	if (descriptors[6] != 255) return false; // bInterfaceSubClass, Vendor Specific
    	if (descriptors[7] != 0) return false; // bInterfaceProtocol, 0 = No class specific protocol required
    
    	uint8_t desc_index = 9;
    	uint8_t in_index = 0xff, out_index = 0xff, notify_index = 0xff;
    
    	println("numendpoint=", numendpoint, HEX);
    	while (numendpoint--) {
    		if ((descriptors[desc_index] != 7) || (descriptors[desc_index+1] != 5)) return false; // not an end point
    		if (descriptors[desc_index+3] == 2) {  // Bulk end point
    			if (descriptors[desc_index+2] & 0x80)
    				in_index = desc_index;
    			else
    				out_index = desc_index;
    		} else {
    			if (descriptors[desc_index+3] == 3) {  // Interrupt end point
    			if (descriptors[desc_index+2] & 0x80)
    				notify_index = desc_index;
    			}
    		}	
    		desc_index += 7;	// point to next one...
    	}
    	if ((in_index == 0xff) || (out_index == 0xff) || (notify_index == 0xff)) return false;	// did not find end point
    	endpointIn = descriptors[in_index+2]; // bulk-in descriptor 1 81h
    	endpointOut = descriptors[out_index+2]; // bulk-out descriptor 2 02h
    	endpointNotifyIn = descriptors[notify_index+2]; // Notification descriptor 3 81h
    	println("endpointIn=", endpointIn, HEX);
    	println("endpointOut=", endpointOut, HEX);
    	println("endpointNotificationIn=", endpointNotifyIn, HEX);
    
    	uint32_t sizeIn = descriptors[in_index+4] | (descriptors[in_index+5] << 8);
    	println("packet size in (ethernetController) = ", sizeIn);
    
    	uint32_t sizeOut = descriptors[out_index+4] | (descriptors[out_index+5] << 8);
    	println("packet size out (ethernetController) = ", sizeOut);
    
    	uint32_t notifySizeIn = descriptors[notify_index+4] | (descriptors[notify_index+5] << 8);
    	println("packet notify in (ethernetController) = ", notifySizeIn);
    	packetSizeIn = sizeIn;	
    	packetSizeOut = sizeOut;	
    	packetSizeNotifyIn = notifySizeIn;
    	uint32_t intervalIn = descriptors[in_index+6];
    	uint32_t intervalOut = descriptors[out_index+6];
    	uint32_t notifyIntervalIn = descriptors[notify_index+6];
    
    	println("polling intervalIn = ", intervalIn);
    	println("polling intervalOut = ", intervalOut);
    	println("polling notifyIntervalIn = ", notifyIntervalIn);
    
    	datapipeIn = new_Pipe(dev, 2, endpointIn, 1, packetSizeIn, intervalIn);
    	datapipeOut = new_Pipe(dev, 2, endpointOut, 0, packetSizeOut, intervalOut);
    	notifypipeIn = new_Pipe(dev, 3, endpointNotifyIn, 1, packetSizeNotifyIn, notifyIntervalIn);
    
    	datapipeIn->callback_function = callbackIn;
    	datapipeOut->callback_function = callbackOut;
    	notifypipeIn->callback_function = callbackNotifyIn;
    
    //	mk_setup(setup, 0x21, 10, 0, 0, 0); // 10=SET_IDLE
    //	queue_Control_Transfer(dev, &setup, NULL, this);
    
    	ethernetOutCompleted = false;
    	ethernetInCompleted = false;
    	ethernetControlCompleted = false;
    	deviceAvailable = true;
    	return true;
    }
    
    void ethernetController::control(const Transfer_t *transfer)
    {
    	println("control CallbackIn (ethernetController)");
    	print_hexbytes(report, 8);
    	ethernetControlCompleted = true;
    
    }
    
    void ethernetController::callbackIn(const Transfer_t *transfer)
    {
    	println("ethernetController CallbackIn (static)");
    	if (transfer->driver) {
    		print("transfer->qtd.token = ");
    		println(transfer->qtd.token & 255);
    		((ethernetController *)(transfer->driver))->new_dataIn(transfer);
    	}
    }
    
    void ethernetController::callbackOut(const Transfer_t *transfer)
    {
    	println("ethernetController CallbackOut (static)");
    	if (transfer->driver) {
    		print("transfer->qtd.token = ");
    		println(transfer->qtd.token & 255);
    		((ethernetController *)(transfer->driver))->new_dataOut(transfer);
    	}
    }
    
    void ethernetController::callbackNotifyIn(const Transfer_t *transfer)
    {
    	println("ethernetController CallbackNotifyIn (static)");
    	if (transfer->driver) {
    		print("transfer->qtd.token = ");
    		println(transfer->qtd.token & 255);
    		((ethernetController *)(transfer->driver))->new_dataNotifyIn(transfer);
    	}
    }
    
    void ethernetController::disconnect()
    {
    	deviceAvailable = false;
    	deviceInitialized = false;
    	println("Device Disconnected...");
    }
    
    void ethernetController::new_dataOut(const Transfer_t *transfer)
    {
    	uint32_t len = transfer->length - ((transfer->qtd.token >> 16) & 0x7FFF);
    	println("ethernetController dataOut (static)", len, DEC);
    	print_hexbytes((uint8_t*)transfer->buffer, (len < 32)? len : 32 );
    	ethernetOutCompleted = true; // Last out transaction is completed.
    }
    
    void ethernetController::new_dataIn(const Transfer_t *transfer)
    {
    	uint32_t len = transfer->length - ((transfer->qtd.token >> 16) & 0x7FFF);
    	println("ethernetController dataIn (static): ", len, DEC);
    	print_hexbytes((uint8_t*)transfer->buffer, (len < 32)? len : 32 );
    	ethernetInCompleted = true; // Last in transaction is completed.
    }
    
    void ethernetController::new_dataNotifyIn(const Transfer_t *transfer)
    {
    	uint32_t len = transfer->length - ((transfer->qtd.token >> 16) & 0x7FFF);
    	println("ethernetController dataNotifyIn (static): ", len, DEC);
    	print_hexbytes((uint8_t*)transfer->buffer, (len < 32)? len : 32 );
    }
    And:
    Code:
    /*
     * USBEthernet Teensy36 USB Host Mass Storage library
     * Copyright (c) 2019 Warren Watson.
     *
     * Permission is hereby granted, free of charge, to any person obtaining
     * a copy of this software and associated documentation files (the
     * "Software"), to deal in the Software without restriction, including
     * without limitation the rights to use, copy, modify, merge, publish,
     * distribute, sublicense, and/or sell copies of the Software, and to
     * permit persons to whom the Software is furnished to do so, subject to
     * the following conditions:
     *
     * The above copyright notice and this permission notice shall be
     * included in all copies or substantial portions of the Software.
     *
     * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
     * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
     * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
     * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
     * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
     * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
     * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
     * SOFTWARE.
     */
     
     // USBEther.h
    
    #ifndef _USBETHER_H_
    #define _USBETHER_H_
    
    #include "USBHost_t36.h"
    
    //--------------------------------------------------------------------------
    class ethernetController : public USBDriver {
    public:
    	ethernetController(USBHost &host) { init(); }
    	ethernetController(USBHost *host) { init(); }
    protected:
    	virtual bool claim(Device_t *device, int type, const uint8_t *descriptors, uint32_t len);
    	virtual void control(const Transfer_t *transfer);
    	virtual void disconnect();
    	static void callbackIn(const Transfer_t *transfer);
    	static void callbackOut(const Transfer_t *transfer);
    	static void callbackNotifyIn(const Transfer_t *transfer);
    	void new_dataIn(const Transfer_t *transfer);
    	void new_dataOut(const Transfer_t *transfer);
    	void new_dataNotifyIn(const Transfer_t *transfer);
    	void init();
    private:
    	Pipe_t mypipes[3] __attribute__ ((aligned(32)));
    	Transfer_t mytransfers[7] __attribute__ ((aligned(32)));
    	strbuf_t mystring_bufs[1];
    	uint32_t packetSizeIn;
    	uint32_t packetSizeOut;
    	uint32_t packetSizeNotifyIn;
    	Pipe_t *datapipeIn;
    	Pipe_t *datapipeOut;
    	Pipe_t *notifypipeIn;
    	uint32_t endpointIn = 0;
    	uint32_t endpointOut = 0;
    	uint32_t endpointNotifyIn = 0;
    	setup_t setup;
    	uint8_t report[8];
    	volatile bool ethernetOutCompleted = false;
    	volatile bool ethernetInCompleted = false;
    	volatile bool ethernetControlCompleted = false;
    	bool deviceAvailable = false;
    	bool deviceInitialized = false;
    };
    
    #endif
    The results of this sketch:
    Code:
    // Simple test of USB Host Ethernet Driver
    // test.ino
    // This example is in the public domain
    
    #include "USBHost_t36.h"
    #include "usbEther.h"
    
    USBHost myusb;
    //USBHub hub1(myusb);
    //USBHub hub2(myusb);
    //USBHub hub3(myusb);
    
    ethernetController ethernet1(myusb);
    
    void setup()
    {
    	while (!Serial) ; // wait for Arduino Serial Monitor
    	Serial.println("USB Host Ethernet Testing");
    	myusb.begin();
    
    }
    
    
    void loop()
    {
    	myusb.Task();
    }
    Is this:
    Code:
    USB Host Ethernet Testing
    sizeof Device = 36
    sizeof Pipe = 96
    sizeof Transfer = 64
    power up USBHS PHY
     reset waited 4
    USBHS_ASYNCLISTADDR = 0
    USBHS_PERIODICLISTBASE = 1FFF3000
    periodictable = 1FFF3000
    port change: 10001803
        connect
      begin reset
    port change: 18001205
      port enabled
      end recovery
    new_Device: 480 Mbit/sec
    new_Pipe
    enumeration:
    enumeration:
    enumeration:
    Device Descriptor:
      12 01 00 02 FF FF 00 40 A6 07 15 85 01 01 01 02 03 01 
        VendorID = 07A6, ProductID = 8515, Version = 0101
        Class/Subclass/Protocol = 255 / 255 / 0
        Number of Configurations = 1
    enumeration:
    enumeration:
    Manufacturer: ADMtek
    enumeration:
    Product: USB To LAN Converter
    enumeration:
    Serial Number: 0001
    enumeration:
    Config data length = 39
    enumeration:
    Configuration Descriptor:
      09 02 27 00 01 01 00 80 70 
        NumInterfaces = 1
        ConfigurationValue = 1
      09 04 00 00 03 FF FF 00 00 
        Interface = 0
        Number of endpoints = 3
        Class/Subclass/Protocol = 255 / 255 / 0
      07 05 81 02 00 02 00 
        Endpoint = 1 IN
        Type = Bulk
        Max Size = 512
        Polling Interval = 0
      07 05 02 02 00 02 00 
        Endpoint = 2 OUT
        Type = Bulk
        Max Size = 512
        Polling Interval = 0
      07 05 83 03 08 00 01 
        Endpoint = 3 IN
        Type = Interrupt
        Max Size = 8
        Polling Interval = 1
    enumeration:
    ethernetController claim this=1FFF2020
    Descriptor 4 = INTERFACE
    ethernetController claim this=1FFF2020
    09 04 00 00 03 FF FF 00 00 07 05 81 02 00 02 00 07 05 02 02 00 02 00 07 05 83 03 08 00 01 
    numendpoint=3
    endpointIn=81
    endpointOut=2
    endpointNotificationIn=83
    packet size in (ethernetController) = 512
    packet size out (ethernetController) = 512
    packet notify in (ethernetController) = 8
    polling intervalIn = 0
    polling intervalOut = 0
    polling notifyIntervalIn = 1
    new_Pipe
    new_Pipe
    new_Pipe
    allocate_interrupt_pipe_bandwidth
      ep interval = 1
      interval = 1
     best_bandwidth = 3, at offset = 0
    Descriptor 5 = ENDPOINT
    Descriptor 5 = ENDPOINT
    Descriptor 5 = ENDPOINT
    Things I observed were endpoint type 3 (interrupt) can be 8 byte or up to 64 bytes.
    Finding driver examples for the AMDTek AN8515 Is hard. Probably my search skills.

    Any thoughts or clues?

  20. #20
    Senior Member
    Join Date
    Aug 2017
    Posts
    138
    Quote Originally Posted by KurtE View Post
    Let me know if you have something to play with. This is another area I thought would be good to have support for in the usb host code....

    @WMXZ - maybe, again not sure if they exist, and which board(s) you would hook up to? T3.6 through SDCard adapter, maybe easier/better with T4 as you have the pins available...
    @KurtE - I have made a little bit of progress with the AMDTek AN8515 USB to LAN adapter. I spent a lot of time trying to find a datasheet on this controller. Found it an Alldatasheet.com. This thing is really old but was used a lot by several USB to LAN adapters. Linux drivers call it Pegasus II. From the information from the Linux driver and the datasheet I was able to read and write the Pegasus registers. I have no experience with Ethernet drivers but at least it's a start. Going to keep working with this to get to USB Wireless LAN controllers. Another thing I am looking at is USB Request Block (URB) in Linux. Maybe a way to allocate multiple endpoints dynamically based on the USB device and latter on doing isochronous (ISO) transfers after USBHost_t36 update.

    Lot's to learn and play with

    Here is the link to the AN8515 datasheet:
    http://cit.odessa.ua/media/pdf/ADM8515.pdf

  21. #21
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    379
    I'm also making progress with a USB to Ethernet adapter, I believe I have everything working except the bulk endpoints that send the ethernet frames. I'm not sure how universal the driver is, it's for a ASIX AX88772B chipset which is used in the Amazon Basic usb 2.0 model, it may work for other ASIX chips as well since I'm not testing for a specific chip and just the manufacturer. Hopefully I can get the bulk endpoints figured out and I'll try to do a speed test with what I have working.

  22. #22
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,923
    Very good and promising @wwatson and @vjmuzik!

  23. #23
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,538
    Cool stuff.. I ordered an amazon basic.... Will be more interesting with Wifi... But still will be fun to play

  24. #24
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    379
    So I've got all the endpoints working, and it is sending and receiving ethernet packets. I haven't setup a way to change the mac address from what's already stored in the chip, but it is possible and I will work out a way to do that later on. But so far this is certainly promising, as long as it's faster than using a SPI ethernet device I'll be happy and it'll be worth it. Besides from anything complicated because of the lack of a tcp/ip stack it at least sends and receives raw frames. Most of what you see in the serial monitor is from broadcast messages because I have the filter set on the ASIX to allow them through and I believe multicast messages are not currently allowed through besides the one specified for all since the filter on the ASIX is not currently setup for any specific ones to flow through.
    Click image for larger version. 

Name:	Screen Shot 2019-09-20 at 5.28.13 PM.jpg 
Views:	26 
Size:	173.7 KB 
ID:	17655

  25. #25
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,923
    Good signs. I put one in my cart for $10.50.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •