[Oberon] WiFi module survey

[D EMARD]

If I can jump in after long inactivity, for example we have
ulx3s to which oberon can work somehow with verilog sdram driver
https://www.crowdsupply.com/radiona/ulx3s
and on stock at Mouser part number

392-CS-ULX3S-03 (board with 85k LUT)
392-CS-ULX3S-01 (board with 12k LUT)

The boards have esp32 wifi and it board is wired so
that a PPP serial link about 1Mbit can be provided from
ESP32 to FPGA core (oberon). But currently this is router-only
without NAT so to reach outside, a tunnel should be used what
is at linux relatively easy to setup.

If you are designing a new board, ESP32 can be connected
with many more lines to FPGA to make it complete RMII interface so
ESP32 will present itself as ethernet PHY RMII connection, same as if
you had a real ethernet RMII wired, but It won't be 100Mbit speed
but about 1-2Mbit in my tests.


On 9/25/20, Joerg <joerg.straube at iaeth.ch> wrote:
> Wojtek
>
> I did not have a look at your collected info yet, but my general remark on
> driver SW:
> The task of an OS is to provide a rather universal API of the Wifi
> functionality to the upper client layers. So, the API of the Oberon System
> to provide WiFi should be carefully crafted. „reduce it to the max to be
> useful“
>
> Then the task of the driver SW is to map this general, universal, OS
> specific Wifi API to the chip‘s specifics.
>
> You can not assume that the different chips offer the same low layer
> interface.
>
> As an example: For the TCP/IP functionality in the Unix OS the „sockets“ API
> seems to be a common ground. Whenever there is a new Ethernet/IP chip, the
> chip manufacturer often provides his „sockets“ implementation to ease the OS
> integration.
>
> As the Oberon system is NOT Unix, we have two tasks:
> 1) invent a Wifi API for the upper layers
> 2) map this API to the chosen chip’s lower layer
>
> For 1), we obviously can look at other OSes (Linux, Unix, Windiws) how they
> do it. But we are rather free here.
> For 2) make your choice based on HW preferences (cost, bus structure,
> memory...) and then write the driver.
>
> For a good, performant Wifi, antenna design is as important as the chip...
>
> br
> Jörg
>
>> Am 25.09.2020 um 01:33 schrieb Skulski, Wojciech
>> <skulski at pas.rochester.edu>:
>>
>> Dear All:
>>
>> I am sending this e-mail to a long list of names off-list because the list
>> server is not happy with attachments. Please feel free to post it to the
>> list if you can push the attachment through.
>>
>> I was not able to do much real work because it is now grant reporting
>> season. But I did some research on WiFi. The results are presented in
>> several attached pages, starting on page 4. The other pages present my
>> thought and investigations on the Nordic radio module and Oberon software,
>> and some general remarks. All these pages are part of the RiskZero Rev 1
>> schematic. Since I am in no hurry, I keep pursuing information and adding
>> notes to the schematic package to be eventually released "really soon
>> now".
>>
>> This investigation was triggered by Joerg remark that he could add WiFi to
>> the System, using Wiznet WiFi module. So I started digging in. The
>> findings were different from expectations. I found that the Wiznet WiFi
>> modules are rather poorly documented. A better choice could be the
>> Sparkfun module WRL-13678 with Espressif ESP8266 because there is more
>> information and code examples, although of mixed quality. The Espressif
>> tools seem good. Some of the Arduino community contributions seem sketchy.
>> The largest reservation against WRL-13678 is low speed.
>>
>> The landscape of the WiFi modules is very mixed. There seems to be no
>> common denominator. Low performance application can be done with AT
>> commands. Both WRL-13678 and Wiznet modules support these commands. It is
>> not clear whether these two use an identical set of AT commands, or two
>> slightly different sets. Silicon Labs provides its own script BGScript.
>> Lantronix provides yet another command interface named LANCIS. If one
>> develops with one of those, one will be out of luck with the others.
>>
>> Perhaps the most reasonable approach would be using the ATWINC15x0 module
>> from Microchip and define a common API with Wiznet W5500 because both
>> chips use a similar architecture. But even this is not clear because WiFi
>> is different from the wired Ethernet after all. It may not be warranted to
>> use the same driver if the details do not closely match.
>>
>> All of these thought are expressed in the attached pages. I also collected
>> all the data sheets and app notes which I am referring to. The zipped
>> archive is 50 MB. I can send it to anyone who tells me how to share such a
>> large file. Having all these documents handy can spare quite a bit of
>> investigative work. If you want to receive these files, please send me a
>> dropbox link or something of this sort.
>>
>> Thank you,
>> Wojtek
>>
>>
>> <WiFi_Modules_Overview-merged.pdf>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>