ports/w60x: Add ports for W60X module based boards. #4679
Conversation
add w60x port
|
Thanks for the submission. Since there is not much of a description here in the PR it's unclear what the intention is for this code, but I assume you want to add it to this repository. For a new port to be added there are some things that must be considered. See eg #4557 for a previous discussion about another port. What is the W60X? Is it popular and easily avaliable? Does it use an open-source toolchain? Will the chip be available in the long term? Will this port be maintained in the long term? |
|
Hi @dpgeorge , thank you for your interest. I modified the description of PR. |
|
Air602 WiFi Module - https://www.seeedstudio.com/Air602-WiFi-Module.html Seeed W600 Module - https://www.seeedstudio.com/W600-Module-p-4020.html Wemos W600-PICO - https://www.aliexpress.com/item/4000314757449.html Winner Micro product page - http://www.winnermicro.com/en/html/1/156/158/497.html |
|
A new development board was added: https://www.seeedstudio.com/W600-Arduino-IoT-Wi-Fi-Board-p-2926.html |
|
Is this port supported by Winner Micro, or is it a private contribution? What is the bug status of the W60x? ESP8266 and ESP32 have some issues like non linear analog that don't look like being fixed. Espressif seem to just delete broken features from the data sheet instead of fixing them. Having a better alternative for commercial and industrial use would be great. What is the status of the 68 pin W601 and modules for it? The W600 doesn't have ADC so I think the W601 would be of interest to MicroPython users. It's only on the Chinese website. Do you know if there is an English data sheet for the W601? It's good to see the WMIOT601 reference module has FCC approval. |
|
Hi @chrismas9 , thank you for your interest.
|
|
Thanks @wdyichen for the information. I didn't look at this PR in detail yet, because there is a lot to go through. But from what I did see so far I have the following questions:
|
|
Thanks @dpgeorge . Yes, w600sdk integrates FreeRTOS. At present, both LwIP stack and WiFi stack are. MBEDTLS applications have not been ported in W600 SDK, but SSL modules will be added in the future. This migration code compiles 321KB firmware, This 45K heap is only allocated to MPY applications, and WiFi and TCP / IP stacks do not use this part of heap memory. |
It would be easy to just enable axtls or mbedtls within MicroPython, there is no need to have it come from the W600 SDK. But it requires a fair amount of flash space.
This was my concern, that there would not be enough flash space for a useful set of features (eg TLS included). Indeed the 2Mbyte flash version sounds like a better choice.
So, can more of this 160k be allocated to MicroPython applications, or is 45k the maximum? |
|
|
I've got some of these modules somewhere around so I'll have a go at building and see if I can provide some feedback. |
|
w600 currently only supports gcc 4.x version, please refer to the url in README. |
Initialize & reset the file offset for the RETR command to 0. It was not initialized before, causing sometimes faulty downloads. Other fixes: - avoid double slash in filenames - some changes to response message texts
The actual implementations missed root pointers in the registers. That caused gc_free() to raise am Assert sometimes during automatic garbage collection, which stopped execution. Thanks to Dave Hylands and @stinos for their execllent support. The fix was suggested by Dave. Note: The change to Makefile could be better. There must be existing measures to call the proper assembler.
gccollect: Add registers to the root pointer scan
ftpserver.c: Initialize file offset (+ other minor changes)
- when calling uos.stat() on a file in a subdirectory with a relative path,
the directory /flash was searched for that file. So with "testfile" in
a directory "testdir", uos.stat("testfile") failed, when the current
dir was "/flash/testdir". Fixed now.
- when calling rename with an absolute path for the second file, this
path was appended to the current dir name, instead of taking that
absolute path name. So with "testfile" in a directory "testdir",
uos.rename("testfile", "/flash/newfile") failed, when the current
dir was "/flash/testdir". Fixed now.
- when given a relative path, chdir appended that new path to the
actual current dir and did not normlize the path name. So when the
current dir was /flash/testdir, uos.chdir("..") caused to current dir
to get /flash/testdir/.. With that change, current dir will then be
/flash.
The test file for coverage tests are changed too.
Normalize path names Path names supplied with ftp commands will be normalized, causing: excess slash characters to be removed . path elements to be removed .. path elements backing up the path one level Removed: commented out code code for WIN32 Optimize LIST and NLIST: Both commands use the same function now, which is told by a parameter which format to use. This function do_list() now also receives a buffer for temporary strings, reducing it's stack usage. Checks: Check, that the resulting path created by build_full_path() does not exceed the buffer size. Test, that the target given with CWD exists and is a dir Bug fixes: - do not call chdir(). Just change the session->current_dir variable - use the full path name as target for rename
extmod/vfs_lfsx.c: Fix a few minor error in vfs_lfsx
tools/ftpserver.c: Refactoring of ftpserver.c
That was missing and caused import to fail sometimes if the module was located in a subdirectory. Fixed by Damien George. Also: Some reformatting done by uncrustify.
parenthesis-typo caused tls_reg_read() to hang on invalid register
Added to w600, a port specific module, similar to the other ports. dht_readinto(). For a DHT module to work properly, the OPEN_DRAIN mode of UART has to be added to (is already coded by @e-tobi).
Changes made in cooperation with @e-tobi. mp_hal_tick_us() and mp_hal_ticks_cpu() The values are now derived from the watchdoc timer, resulting in a 1µs resultion of mp_hal_tick_us and 40MHz ticks of mp_hal_ticks_cpu. However, there are drawbacks: - the watchdog cannot be used any more - the largest span for ticks_diff in combination with tick_us is about 107 seconds (precise: 2**32 / 40 microseconds). - the ticks counter is reset on every task switch, call to sleep(), sleep_ms(), or sleep_us(x) with x >= 4000 and every line entered in REPL. There may be more cases in which that happens. But at least some functions do work, which required determining short time spans. Like the DHTxx module. mp_hal_delay_us() The delay is based on the ticks_cpu timer. For times < 4000µs this is done by busy waiting, beyond that time mp_hal_delay_ms() is used, which has en error of +/- 2 ms.
With that change, ticks_us() will have the full range of +/- 2**30 microseconds. That requires a change to the SDK too, because of a bug in the SDK, not allowing to register an alternative IRQ handler to the watchdog interrupt. Therefore the file wm_watchdog.c is moved into the local repository and changes accordingly.
- call vTaskSuspend() instead of vTaskDelete() vTaskDelete() assumes, that the stack buffer was allocated within tasks.c. But the stack buffer is allocated form the MP heap. Freeing it the wrong way causes memory corruption. - have all threads the same priority. Otherwise the following threads will execute with much slower pace. - Remove usage of thread_cnt. It was only used to give threads different priorities, which seemed to be a bad decision anyhow. - Do a hard reset with Ctrl-D if threads had been started. That will close all tasks and free the heap. - call tls_os_time_delay(1) in the MICROPY_EVENT_POLL_HOOK macro giving time for a task switch. Note: This variant provides the stack for the threads (= RTOS tasks) from the micropython heap. That prohibits using xTaskDelete(), because that assumes, that the stack is provided by the RTOS heap, an xTaskDelete() frees that using RTOS methods, causing the both heaps to get corrupted. When using xTaskSuspend is is unclear, whether the thread stack buffer can be released. At the moment, it is kept. I can provide another variant, which is taking the task stack buffer from the RTOS heap. Since that is very limited, only one thread can be started at 4k stack size, or two threads at 2k stack size. The RTOS heap can be increased by changing the setting in FreeRTOSConfig.h. But that is a change to the SDK I want to avoid.
extmod/vfs_lfsx.c: Setting the full path in import_stat()
mphalport.c et al: fix us-timing support
mpthreadport.c: Refactor threading to a working state
The path strings have to be added to qstrdefsport.h such that get properly expanded.
qstrdefsport.h, main.c: Fix adding paths to sys.path
Add DAC* and RTL_* pin assignments to Wio Terminal board.
|
Hi @wdyichen what is the status of this port? Is there a stable version of it? |
|
There has not been much interest in this MCU/port in the past 2 years. Also, it is a lot of work to add a new port to MicroPython due to the ongoing maintenance effort. So I will close this pull request. Feel free to maintain this port in a separate repository and keep it up to date with MicroPython. If there is enough interest in it, the issues with gcc version can be resolved, and someone is willing and able to maintain it, then we can reconsider getting it into this repository. Thanks for your efforts! |
|
There is a recent port for the W60X device kept recent here: https://github.com/robert-hh/micropython/tree/w60x and some pre-built images here: https://github.com/robert-hh/Shared-Stuff. The work of extending this PR's version was done by @e-tobi and me, with support and feedback by @wdyichen . |
|
Thanks @robert-hh for pointing out your fork/branch (at least I didn't know of it). It's good to hear that something has come of this work. |
|
Thanks @dpgeorge @robert-hh for attention. I am no longer supporting this project due to job changes. We may port mpy to new chips in the future. |
@wdyichen, is the situation that you (personally) are not supporting the W600/W601 or is the situation that Winner Micro is no longer supporting and/or manufacturing the W600/W601? I've recently come across these devices and I am in agreement with others such as @robert-hh that W600/W601 at current cost levels or below very much has a place in the market. I apologize if this is obvious, but the reason it has not had a significant pick up seems almost entirely due to this shallow and intermittent software support. Myself, @robert-hh, and others would be happy to take over and continue the support at this stage based on @robert-hh's work, but we need to know whether that's a waste of effort because Winner Micro has abandoned this chip entirely. If you cannot answer this, @wdyichen, perhaps you can motivate someone at Winner Micro to do so promptly. Perhaps as further motivation for Winner Micro to be communicative and transparent is that such approach will maintain credibility for the company within the developer community for other and future devices (whereas lack of it may well not). |
It's just that I personally don't support it. winnermicro still makes and supports the chip. |
W600 is an embedded Wi-Fi SoC chip which is complying with IEEE802.11b/g/n international standard and which supports multi interface, multi protocol. It can be easily applied to smart appliances, smart home, health care, smart toy, wireless audio & video, industrial and other IoT fields. This SoC integrates Cortex-M3 CPU, Flash, RF Transceiver, CMOS PA, BaseBand. It applies multi interfaces such as SPI, UART, GPIO, I2C, PWM, I2S, 7816. It applies multi encryption and decryption protocol such as PRNG/SHA1/MD5/RC4/DES/3DES/AES/CRC/RSA.
Currently only port modules with WiFi,GPIO, UART, software SPI, I2C, PWM, WDT and Timer，more module ports will be added in the future.
These chips are widely available and can be purchased from various major distributors like Seeed, Taobao, etc, or directly from WinnerMicro.
W600 uses standard arm-none-eabi-gcc and openocd to compile and debug firmware.
W600 is available in the long term, and code are licensed under Apache license.
We will update the migration code frequently, especially when the SDK updates or fixes bugs.