Re: Multiple IP addresses with a single GMAC (RMII PHY)
> On Thu, Oct 26, 2023 at 3:10 PM Gregory Nutt wrote: > > > > > On 10/25/2023 10:41 PM, Zhe Weng 翁�� wrote: > > > But I do have another idea: > > > Maybe you can try to register two network devices even if you only have > > a single GMAC, just dup all the rx packets to both interfaces, and let all > > tx packets go out. Since the IP addresses are different on each interface, > > the stack may drop packets on the incorrect interface and accept the > > correct one. It may have some problems in some situations like broadcast I > > guess, but I think it may have a chance to work. > > > > I think there might be a couple of minor issues with that. First, the > > MAC should not know anything about IP address. The OSI Seven Layer > > Model prescribes that architecture and we really should make some effort > > to conform to it: https://en.wikipedia.org/wiki/OSI_model > > > > Without getting involved with IP routing, a single MAC driver could not > > handle multiple IP address. It would have to parse the incoming > > packets, look up the IP address in the packet, match it with a device > > driver, then forward the the correct driver structure with the packet. > > > > Replies to the IP message could be awkward as well. We could not reply > > using the same device. The network would always have to notify the > > driver of data availability using that IP address to identify the > > correct device structure to use. > > > > What about non-IP packets, they would probably have to use the same > > device structure? > > > > This would not be a systematic solution; it would apply to only a single > > MCU type. A better solution would be generalized to the MAC of all > > current and future MCUs. The solution should be generalized and common. > > > > I think the lack of architectural modularity, generality, and overall > > complexity would make this approach undesirable. > > > > I wonder if this hasn't been solved already in some industry-accepted > manner. For example (not saying this is the solution, just thinking out > loud) there is a redundancy mechanism that makes two network interfaces > look like one, with automatic failover. What the OP wants looks like the > reverse of that: make one network interface look like two. It just feels > like a problem that might have been solved already. > > Nathan On Linux, a bridge or a bonded interface may do the former, and macvlan for the latter. Macvlan adds additional interfaces by adding additional MAC addresses on a single NIC. But macvlan normally depends on promiscuous mode, which tells the NIC to receive packets not targeting the NIC's MAC address instead of ignoring them. Zhe #/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!**/#
Re: Multiple IP addresses with a single GMAC (RMII PHY)
On 10/26/2023 4:48 PM, Nathan Hartman wrote: I wonder if this hasn't been solved already in some industry-accepted manner. For example (not saying this is the solution, just thinking out loud) there is a redundancy mechanism that makes two network interfaces look like one, with automatic failover. What the OP wants looks like the reverse of that: make one network interface look like two. It just feels like a problem that might have been solved already. As the OP mentioned in the first email, Linux already provides an ifconfig interface to do this. I don't know how Linux implements that,but I am pretty certain that it would not involve the MAC layer. https://www.garron.me/en/linux/add-secondary-ip-linux.html Perhaps this is implemented via an IOCTL command or maybe via something like a netlink socket. A network interface connects only to a single network so I don't think that the objective is to make it look like two networks. At least that doesn't make any sense to me. I don't even know what that would mean. The objective is, I think, to support two IP addresses on that one network. IP is not in the MAC layer. The MAC driver is part of OSI Layer 2, the "Data Link" layer. NuttX supports a very modular interface between the network and the MAC driver. We don't want to violate that modularity. https://en.wikipedia.org/wiki/OSI_model IP is part of Layer 3, the network layer (or, in another conception, the TCP/IP layer). Within the network, the additional layers are not well modularized.
Re: Multiple IP addresses with a single GMAC (RMII PHY)
On Thu, Oct 26, 2023 at 3:10 PM Gregory Nutt wrote: > > On 10/25/2023 10:41 PM, Zhe Weng 翁喆 wrote: > > But I do have another idea: > > Maybe you can try to register two network devices even if you only have > a single GMAC, just dup all the rx packets to both interfaces, and let all > tx packets go out. Since the IP addresses are different on each interface, > the stack may drop packets on the incorrect interface and accept the > correct one. It may have some problems in some situations like broadcast I > guess, but I think it may have a chance to work. > > I think there might be a couple of minor issues with that. First, the > MAC should not know anything about IP address. The OSI Seven Layer > Model prescribes that architecture and we really should make some effort > to conform to it: https://en.wikipedia.org/wiki/OSI_model > > Without getting involved with IP routing, a single MAC driver could not > handle multiple IP address. It would have to parse the incoming > packets, look up the IP address in the packet, match it with a device > driver, then forward the the correct driver structure with the packet. > > Replies to the IP message could be awkward as well. We could not reply > using the same device. The network would always have to notify the > driver of data availability using that IP address to identify the > correct device structure to use. > > What about non-IP packets, they would probably have to use the same > device structure? > > This would not be a systematic solution; it would apply to only a single > MCU type. A better solution would be generalized to the MAC of all > current and future MCUs. The solution should be generalized and common. > > I think the lack of architectural modularity, generality, and overall > complexity would make this approach undesirable. I wonder if this hasn't been solved already in some industry-accepted manner. For example (not saying this is the solution, just thinking out loud) there is a redundancy mechanism that makes two network interfaces look like one, with automatic failover. What the OP wants looks like the reverse of that: make one network interface look like two. It just feels like a problem that might have been solved already. Nathan
Re: Multiple IP addresses with a single GMAC (RMII PHY)
On 10/25/2023 10:41 PM, Zhe Weng 翁喆 wrote: But I do have another idea: Maybe you can try to register two network devices even if you only have a single GMAC, just dup all the rx packets to both interfaces, and let all tx packets go out. Since the IP addresses are different on each interface, the stack may drop packets on the incorrect interface and accept the correct one. It may have some problems in some situations like broadcast I guess, but I think it may have a chance to work. I think there might be a couple of minor issues with that. First, the MAC should not know anything about IP address. The OSI Seven Layer Model prescribes that architecture and we really should make some effort to conform to it: https://en.wikipedia.org/wiki/OSI_model Without getting involved with IP routing, a single MAC driver could not handle multiple IP address. It would have to parse the incoming packets, look up the IP address in the packet, match it with a device driver, then forward the the correct driver structure with the packet. Replies to the IP message could be awkward as well. We could not reply using the same device. The network would always have to notify the driver of data availability using that IP address to identify the correct device structure to use. What about non-IP packets, they would probably have to use the same device structure? This would not be a systematic solution; it would apply to only a single MCU type. A better solution would be generalized to the MAC of all current and future MCUs. The solution should be generalized and common. I think the lack of architectural modularity, generality, and overall complexity would make this approach undesirable.
Re: ESP32 I2S audio recording is incomplete
There should be something wrong on our config! I tested here (using esp32-devkitc:psram) and it worked like a charm! nsh> ? help usage: help [-v] [] . cp exitmkfatfs rmdir umount [ cmp false mkrdset unset ? dirname fdinfo mount sleep uptime alias dd freemv source usleep unalias df helppidof testxd basenamedmesg hexdump printf time break echokillps true cat env ls pwd truncate cd execmkdir rm uname Builtin Apps: mm nshsh nsh> free total used freelargest nused nfree esp32-imem: 98304 4504 93800 93800 4 1 Umem:4415120 691244082084194288 48 4 nsh> mkrd 2048 nsh> free total used freelargest nused nfree esp32-imem: 98304 4504 93800 93800 4 1 Umem:441512010233595683145704 51 4 nsh> ls /dev /dev: console null ram0 ttyS0 urandom zero nsh> mkfatfs /dev/ram0 nsh> mount -t vfat /dev/ram0 /mnt nsh> df BlockNumber Size Blocks Used Available Mounted on 1024 1004 21002 /mnt 0 0 0 0 /proc nsh> dd if=/dev/urandom of=/mnt/random.bin bs=1024 count=512 nsh> ls -l /mnt /mnt: -rw-rw-rw- 524288 random.bin nsh> uname -a NuttX 12.3.0 ef1ad691c3-dirty Oct 26 2023 14:43:56 xtensa esp32-devkitc Please let me know what was your mistake, it could help to improve NuttX. BR, Alan On 10/26/23, Simona Toaca wrote: > Yes, ESP32_PSRAM_8M is enabled. > > Regards, > Simona > > În joi, 26 oct. 2023 la 16:55, Alan C. Assis a scris: > >> Hi Simona, >> >> On 10/26/23, Simona Toaca wrote: >> > Hello, >> > >> > I want to make sure that I understood this correctly, you're saying >> > that >> > the I2S audio saved to an SDCard (via SPI) on Lyra T is working ok? >> > >> >> I think that is true. Maybe Lucas can confirm if he was saving in the >> SDCard. >> >> > Also, I tried creating a ramdisk of 1mb+ for testing, but I did not >> > find >> a >> > way do to so. >> > For example, >> > mkrd 1024 lends the error: mkrd: boardctl(BOARDIOC_MKRD) failed: 1 >> > but >> > mkrd -s 1024 128 or mkrd 64 work fine >> > >> > The max I succeeded in allocating is 128kb. >> > >> >> Hmm, did you enable PSRAM to get more available RAM? >> >> BR, >> >> Alan >> >
Re: ESP32 I2S audio recording is incomplete
Yes, ESP32_PSRAM_8M is enabled. Regards, Simona În joi, 26 oct. 2023 la 16:55, Alan C. Assis a scris: > Hi Simona, > > On 10/26/23, Simona Toaca wrote: > > Hello, > > > > I want to make sure that I understood this correctly, you're saying that > > the I2S audio saved to an SDCard (via SPI) on Lyra T is working ok? > > > > I think that is true. Maybe Lucas can confirm if he was saving in the > SDCard. > > > Also, I tried creating a ramdisk of 1mb+ for testing, but I did not find > a > > way do to so. > > For example, > > mkrd 1024 lends the error: mkrd: boardctl(BOARDIOC_MKRD) failed: 1 > > but > > mkrd -s 1024 128 or mkrd 64 work fine > > > > The max I succeeded in allocating is 128kb. > > > > Hmm, did you enable PSRAM to get more available RAM? > > BR, > > Alan >
Re: ESP32 I2S audio recording is incomplete
Hi Simona, On 10/26/23, Simona Toaca wrote: > Hello, > > I want to make sure that I understood this correctly, you're saying that > the I2S audio saved to an SDCard (via SPI) on Lyra T is working ok? > I think that is true. Maybe Lucas can confirm if he was saving in the SDCard. > Also, I tried creating a ramdisk of 1mb+ for testing, but I did not find a > way do to so. > For example, > mkrd 1024 lends the error: mkrd: boardctl(BOARDIOC_MKRD) failed: 1 > but > mkrd -s 1024 128 or mkrd 64 work fine > > The max I succeeded in allocating is 128kb. > Hmm, did you enable PSRAM to get more available RAM? BR, Alan
Re: ESP32 I2S audio recording is incomplete
Hello, I want to make sure that I understood this correctly, you're saying that the I2S audio saved to an SDCard (via SPI) on Lyra T is working ok? Also, I tried creating a ramdisk of 1mb+ for testing, but I did not find a way do to so. For example, mkrd 1024 lends the error: mkrd: boardctl(BOARDIOC_MKRD) failed: 1 but mkrd -s 1024 128 or mkrd 64 work fine The max I succeeded in allocating is 128kb. Regards, Simona În vin., 20 oct. 2023 la 16:35, Alan C. Assis a scris: > Hi Simon, > > Lucas just confirmed that it was working fine on Lyra T with ES8388 Audio > Codec. > > I think she is using SDCard over SPI (even slower). > > There is not SDCard interface support for ESP32 on NuttX yet (the > SDCard uses/shares I2S interface). > > The ESP32 MCU has 2 I2S interfaces, so in theory one can be used for > Audio and other for SDCard. > > The ESP32-S2 has only 1 I2S interface, so I don't know if it will work > well. > > Hopefully ESP32-S3 has 2 I2S as ESP32. > > BR, > > Alan > > On 10/20/23, Simon Filgis wrote: > > Hi Simona, > > > > SD Cards have busy time times of 500ms max (per spec) for saving data > > internally. I saw SD Cards taking over a second of busy time. > > > > You can check with the Oszilloskop. I think data0 is the pin that > signalize > > busy... > > > > Per design, you need a stream buffer that can handle your audio stream up > > to 500ms... > > > > Regards, > > > > Simon > > > > -- > > Ingenieurbüro-Filgis > > USt-IdNr.: DE305343278 > > -- > > sent by mobile phone > > > > Alan C. Assis schrieb am Do., 19. Okt. 2023, 23:36: > > > >> Hi Simona, > >> > >> On 10/19/23, Simona Toaca wrote: > >> > Hello, > >> > I am trying to record audio using a MEMS microphone, but the final > >> > recording is missing parts periodically (for example, with a sample > >> > rate > >> of > >> > 8kHz, there are parts ~1s long missing once every ~10-11s. Using a > >> > sample > >> > rate of 48kHz, the period is ~1s long). This is my first time working > >> with > >> > I2S and I can't figure out what causes this behaviour. > >> > > >> > My setup is as follows: > >> > - the microphone has 24-bit depth in a 32-bit word (MSB first) when > >> > transmitting data > >> > - i am using nxrecorder to record the pcm audio onto an SD card > (device > >> > pcm_in0) > >> > - to listen to the recording i import the file into Audacity (24-bit, > >> > Big > >> > Endian) > >> > > >> > Defconfig regarding audio: > >> > CONFIG_AUDIO=y > >> > CONFIG_AUDIO_BUFFER_NUMBYTES=6144 (from the i2s buffer which is 8192 > >> bytes, > >> > 3/4 of it is "useful" info, 6144 bytes in total) > >> > CONFIG_AUDIO_DMA=y > >> > CONFIG_AUDIO_FORMAT_RAW=y > >> > CONFIG_AUDIO_I2S=y > >> > CONFIG_DMA=y > >> > CONFIG_DMA_LINK=y > >> > CONFIG_DRIVERS_AUDIO=y > >> > CONFIG_ESP32_I2S0=y > >> > CONFIG_ESP32_I2S0_BCLKPIN=25 > >> > CONFIG_ESP32_I2S0_DATA_BIT_WIDTH_24BIT=y > >> > CONFIG_ESP32_I2S0_DINPIN=26 > >> > CONFIG_ESP32_I2S0_SAMPLE_RATE=8000 > >> > CONFIG_ESP32_I2S0_WSPIN=27 > >> > CONFIG_ESP32_I2S=y > >> > CONFIG_I2S_DMADESC_NUM=4 > >> > > >> > I tried modifying the number of audio buffers and also making them > >> bigger, > >> > but that did not solve the problem. > >> > Any ideas on what could cause this? > >> > > >> > >> Could it be something related to SDCard storage? Maybe it needs some > >> optimization! > >> > >> Please try using a RAMDISK of 1MB+ and save the file to it. > >> > >> If it works we will know the SDCard could be the limitation of this > >> configuration. > >> > >> BR, > >> > >> Alan > >> > > >
