Pyboard d

[nherriot]

This change is to allow a unix like socket to be created using the simple Socket API when the new Pyboard D is detected as the hardware platform.

I'm open to suggestions on how to do this differently? We could: 1) Detect a socket failure in try catch and then go fro default. But I can't test this on ESP boards as we don't use them. 2) Look at the firmware version. This means that if there is a new version of firmware that supports the API it would be a more 'slick' solution going forward. 3) Change the socket create method for all versions. But I have no ESP boards to test this with.

Or something else?

[jczic]

Hello Nicholas,

Sorry but I'm in hollidays for the moment and I don't really have time, but you can just use the standard declaration in a try/catch and use the limited declaration if an error occures, may be?

Like

try :
    server = socket...(argA, argB, argC)
catch :
    try :
        server = socket...(argA, argB)
    catch :
        error...

Do you thing that's a good idea rather than having the boards declared and looping them?

[nherriot]

Hi Jean-Christophe,

yes that will work to. I was thinking second pythonic rule 'explicit is better than implicit' - so only the simple socket interface is used when I'm sure I'm running those boards. Otherwise it fails as we don't know the outcome on other boards and version of firmware.

The try catch should implicitly work for any board - Let me check and make changes as you suggest. I'm guessing you are thinking that anyone using the software on different board and hardware will be checking anyway! OK that makes sense... :-)

Hope you have a nice holiday! :-)

[nherriot]

Hi Jean-Christophe, i've updated the change using a simple try/except clause. Let me know what you think. I've also updated the readme file to say it now supports all boards D-seriese. I've tested on the SF2W and SF6W (Thanks to Christine Spindler from micropython for providing the SF6W hardware! :-) ) and it all works. I also removed white space on function method calls to stop Pep8 complaining on pycharm! :-) Kind regards, Nicholas.

[nherriot]

Sample output from testing:

srv.AcceptWebSocketCallback = _acceptWebSocketCallback srv.Start() AttributeError warning: 'module' object has no attribute 'IPPROTO_TCP' This board: PYBD-SF6W Does not support 'IPPROTO_TCP'. Creating a default UNIX like socket instead

[jczic]

Hello @nherriot :)

It's ok but you used 2x SOCK_STREAM at line 222 and call a reference to "self._boardType" at line 227. Also, I've checked again socket API and it is possible to create a socket without the third argument (protocol IPPROTO_TCP) because it's ok by default.

As a result, you can just remove the third argument :) Are you ok with that ?

[nherriot]

:-) this is really funny! 1) sorry about the typo on 222! School boy error! 2) if the 3rd parameter can be removed then we can remove all the logic, it will work 'out the box' with Pyboard D-series.

However! You have to be able to check this will work on the ESP boards with this change!!! I've only got STM boards from the Micropython people. Are you OK with this? :-o .......

I think we have gone full circle! :-)

Kind regards, Nicholas.

[nherriot]

I forgot to mention. The call to self._boardType is a member variable which contains the actual board the server is running on. It is populated on the init on line 195 here: self._boardType = uname()[4].split()[0]

I wanted this as I don't want to keep making OS calls to obtain this information. I thought if there were more issues with different board types (e.g. sockets, web-sockets and so on...) it would be nice for the web server to know it's board type.

But from what you say, I guess we don't need any of it if we can remove the 3rd parameter. :-)

Kind regards, Nicholas.

[hoihu]

I have had a similar issue with the pyboard D. My opinion is to get rid of all parameters to socket.socket. See PR #60 . But I have only tested this on my pyboard D serie SF2 and not with ESP32 boards.

Ah I saw your comment just now:

Also, I've checked again socket API and it is possible to create a socket without the third argument (protocol IPPROTO_TCP) because it's ok by default.

That might be an option as well. I'll leave it to you which one is better suited (completely remove all args or only args1+2)