When will Teensy marry ESP32?

Status
Not open for further replies.

jasper

Active member
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!:eek:
 
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?
 
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.
 
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.
 
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.
 
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?
 
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.
 
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.
 
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.
 
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.
 
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.
 
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)
 
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...
 
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?:)
 
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
 
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.
 
Cool stuff.. I ordered an amazon basic.... Will be more interesting with Wifi... But still will be fun to play
 
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.
Screen Shot 2019-09-20 at 5.28.13 PM.jpg
 
Status
Not open for further replies.
Back
Top