general.rst 15 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385
  1. General information about the WiPy
  2. ==================================
  3. No floating point support
  4. -------------------------
  5. Due to space reasons, there's no floating point support, and no math module. This
  6. means that floating point numbers cannot be used anywhere in the code, and that
  7. all divisions must be performed using '//' instead of '/'. Example::
  8. >>> r = 4 // 2 # this will work
  9. >>> r = 4 / 2 # this WON'T
  10. Before applying power
  11. ---------------------
  12. .. warning::
  13. The GPIO pins of the WiPy are NOT 5V tolerant, connecting them to voltages higher
  14. than 3.6V will cause irreparable damage to the board. ADC pins, when configured
  15. in analog mode cannot withstand voltages above 1.8V. Keep these considerations in
  16. mind when wiring your electronics.
  17. WLAN default behaviour
  18. ----------------------
  19. When the WiPy boots with the default factory configuration starts in Access Point
  20. mode with ``ssid`` that starts with: ``wipy-wlan`` and ``key: www.wipy.io``.
  21. Connect to this network and the WiPy will be reachable at ``192.168.1.1``. In order
  22. to gain access to the interactive prompt, open a telnet session to that IP address on
  23. the default port (23). You will be asked for credentials:
  24. ``login: micro`` and ``password: python``
  25. .. _wipy_telnet:
  26. Telnet REPL
  27. -----------
  28. Linux stock telnet works like a charm (also on OSX), but other tools like putty
  29. work quite well too. The default credentials are: **user:** ``micro``, **password:** ``python``.
  30. See :ref:`network.server <network.server>` for info on how to change the defaults.
  31. For instance, on a linux shell (when connected to the WiPy in AP mode)::
  32. $ telnet 192.168.1.1
  33. .. _wipy_filesystem:
  34. Local file system and FTP access
  35. --------------------------------
  36. There is a small internal file system (a drive) on the WiPy, called ``/flash``,
  37. which is stored within the external serial flash memory. If a micro SD card
  38. is hooked-up and mounted, it will be available as well.
  39. When the WiPy starts up, it always boots from the ``boot.py`` located in the
  40. ``/flash`` file system. On boot up, the current directory is ``/flash``.
  41. The file system is accessible via the native FTP server running in the WiPy.
  42. Open your FTP client of choice and connect to:
  43. **url:** ``ftp://192.168.1.1``, **user:** ``micro``, **password:** ``python``
  44. See :ref:`network.server <network.server>` for info on how to change the defaults.
  45. The recommended clients are: Linux stock FTP (also in OSX), Filezilla and FireFTP.
  46. For example, on a linux shell::
  47. $ ftp 192.168.1.1
  48. The FTP server on the WiPy doesn't support active mode, only passive, therefore,
  49. if using the native unix ftp client, just after logging in do::
  50. ftp> passive
  51. Besides that, the FTP server only supports one data connection at a time. Check out
  52. the Filezilla settings section below for more info.
  53. FileZilla settings
  54. ------------------
  55. Do not use the quick connect button, instead, open the site manager and create a new
  56. configuration. In the ``General`` tab make sure that encryption is set to: ``Only use
  57. plain FTP (insecure)``. In the Transfer Settings tab limit the max number of connections
  58. to one, otherwise FileZilla will try to open a second command connection when retrieving
  59. and saving files, and for simplicity and to reduce code size, only one command and one
  60. data connections are possible. Other FTP clients might behave in a similar way.
  61. .. _wipy_firmware_upgrade:
  62. Upgrading the firmware Over The Air
  63. -----------------------------------
  64. OTA software updates can be performed through the FTP server. Upload the ``mcuimg.bin`` file
  65. to: ``/flash/sys/mcuimg.bin`` it will take around 6s. You won't see the file being stored
  66. inside ``/flash/sys/`` because it's actually saved bypassing the user file system, so it
  67. ends up inside the internal **hidden** file system, but rest assured that it was successfully
  68. transferred, and it has been signed with a MD5 checksum to verify its integrity. Now, reset
  69. the WiPy by pressing the switch on the board, or by typing::
  70. >>> import machine
  71. >>> machine.reset()
  72. Software updates can be found in: https://github.com/wipy/wipy/releases (**Binaries.zip**).
  73. It's always recommended to update to the latest software, but make sure to
  74. read the **release notes** before.
  75. .. note::
  76. The ``bootloader.bin`` found inside ``Binaries.zip`` is there only for reference, it's not
  77. needed for the Over The Air update.
  78. In order to check your software version, do::
  79. >>> import os
  80. >>> os.uname().release
  81. If the version number is lower than the latest release found in
  82. `the releases <https://github.com/wipy/wipy/releases>`_, go ahead and update your WiPy!
  83. .. _wipy_boot_modes:
  84. Boot modes and safe boot
  85. ------------------------
  86. If you power up normally, or press the reset button, the WiPy will boot
  87. into standard mode; the ``boot.py`` file will be executed first, then
  88. ``main.py`` will run.
  89. You can override this boot sequence by pulling ``GP28`` **up** (connect
  90. it to the 3v3 output pin) during reset. This procedure also allows going
  91. back in time to old firmware versions. The WiPy can hold up to 3 different
  92. firmware versions, which are: the factory firmware plus 2 user updates.
  93. After reset, if ``GP28`` is held high, the heartbeat LED will start flashing
  94. slowly, if after 3 seconds the pin is still being held high, the LED will start
  95. blinking a bit faster and the WiPy will select the previous user update to boot.
  96. If the previous user update is the desired firmware image, ``GP28`` must be
  97. released before 3 more seconds elapse. If 3 seconds later the pin is still high,
  98. the factory firmware will be selected, the LED will flash quickly for 1.5 seconds
  99. and the WiPy will proceed to boot. The firmware selection mechanism is as follows:
  100. **Safe Boot Pin** ``GP28`` **released during:**
  101. +-------------------------+-------------------------+----------------------------+
  102. | 1st 3 secs window | 2nd 3 secs window | Final 1.5 secs window |
  103. +=========================+=========================+============================+
  104. | | Safe boot, *latest* | | Safe boot, *previous* | | Safe boot, the *factory* |
  105. | | firmware is selected | | user update selected | | firmware is selected |
  106. +-------------------------+-------------------------+----------------------------+
  107. On all of the above 3 scenarios, safe boot mode is entered, meaning that
  108. the execution of both ``boot.py`` and ``main.py`` is skipped. This is
  109. useful to recover from crash situations caused by the user scripts. The selection
  110. made during safe boot is not persistent, therefore after the next normal reset
  111. the latest firmware will run again.
  112. The heartbeat LED
  113. ------------------
  114. By default the heartbeat LED flashes once every 4s to signal that the system is
  115. alive. This can be overridden through the :mod:`wipy` module::
  116. >>> import wipy
  117. >>> wipy.heartbeat(False)
  118. There are currently 2 kinds of errors that you might see:
  119. 1. If the heartbeat LED flashes quickly, then a Python script (eg ``main.py``)
  120. has an error. Use the REPL to debug it.
  121. 2. If the heartbeat LED stays on, then there was a hard fault, you cannot
  122. recover from this, the only way out is to press the reset switch.
  123. Details on sleep modes
  124. ----------------------
  125. * ``machine.idle()``: Power consumption: ~12mA (in WLAN STA mode). Wake sources:
  126. any hardware interrupt (including systick with period of 1ms), no special
  127. configuration required.
  128. * ``machine.sleep()``: 950uA (in WLAN STA mode). Wake sources are ``Pin``, ``RTC``
  129. and ``WLAN``
  130. * ``machine.deepsleep()``: ~350uA. Wake sources are ``Pin`` and ``RTC``.
  131. Additional details for machine.Pin
  132. ----------------------------------
  133. On the WiPy board the pins are identified by their string id::
  134. from machine import Pin
  135. g = machine.Pin('GP9', mode=Pin.OUT, pull=None, drive=Pin.MED_POWER, alt=-1)
  136. You can also configure the Pin to generate interrupts. For instance::
  137. from machine import Pin
  138. def pincb(pin):
  139. print(pin.id())
  140. pin_int = Pin('GP10', mode=Pin.IN, pull=Pin.PULL_DOWN)
  141. pin_int.irq(trigger=Pin.IRQ_RISING, handler=pincb)
  142. # the callback can be triggered manually
  143. pin_int.irq()()
  144. # to disable the callback
  145. pin_int.irq().disable()
  146. Now every time a falling edge is seen on the gpio pin, the callback will be
  147. executed. Caution: mechanical push buttons have "bounce" and pushing or
  148. releasing a switch will often generate multiple edges.
  149. See: http://www.eng.utah.edu/~cs5780/debouncing.pdf for a detailed
  150. explanation, along with various techniques for debouncing.
  151. All pin objects go through the pin mapper to come up with one of the
  152. gpio pins.
  153. For the ``drive`` parameter the strengths are:
  154. - ``Pin.LOW_POWER`` - 2mA drive capability.
  155. - ``Pin.MED_POWER`` - 4mA drive capability.
  156. - ``Pin.HIGH_POWER`` - 6mA drive capability.
  157. For the ``alt`` parameter please refer to the pinout and alternate functions
  158. table at <https://raw.githubusercontent.com/wipy/wipy/master/docs/PinOUT.png>`_
  159. for the specific alternate functions that each pin supports.
  160. For interrupts, the ``priority`` can take values in the range 1-7. And the
  161. ``wake`` parameter has the following properties:
  162. - If ``wake_from=machine.Sleep.ACTIVE`` any pin can wake the board.
  163. - If ``wake_from=machine.Sleep.SUSPENDED`` pins ``GP2``, ``GP4``, ``GP10``,
  164. ``GP11``, GP17`` or ``GP24`` can wake the board. Note that only 1
  165. of this pins can be enabled as a wake source at the same time, so, only
  166. the last enabled pin as a ``machine.Sleep.SUSPENDED`` wake source will have effect.
  167. - If ``wake_from=machine.Sleep.SUSPENDED`` pins ``GP2``, ``GP4``, ``GP10``,
  168. ``GP11``, ``GP17`` and ``GP24`` can wake the board. In this case all of the
  169. 6 pins can be enabled as a ``machine.Sleep.HIBERNATE`` wake source at the same time.
  170. Additional Pin methods:
  171. .. method:: machine.Pin.alt_list()
  172. Returns a list of the alternate functions supported by the pin. List items are
  173. a tuple of the form: ``('ALT_FUN_NAME', ALT_FUN_INDEX)``
  174. Additional details for machine.I2C
  175. ----------------------------------
  176. On the WiPy there is a single hardware I2C peripheral, identified by "0". By
  177. default this is the peripheral that is used when constructing an I2C instance.
  178. The default pins are GP23 for SCL and GP13 for SDA, and one can create the
  179. default I2C peripheral simply by doing::
  180. i2c = machine.I2C()
  181. The pins and frequency can be specified as::
  182. i2c = machine.I2C(freq=400000, scl='GP23', sda='GP13')
  183. Only certain pins can be used as SCL/SDA. Please refer to the pinout for further
  184. information.
  185. Known issues
  186. ------------
  187. Incompatible way to create SSL sockets
  188. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  189. SSL sockets need to be created the following way before wrapping them with.
  190. ``ssl.wrap_socket``::
  191. import socket
  192. import ssl
  193. s = socket(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_SEC)
  194. ss = ssl.wrap_socket(s)
  195. Certificates must be used in order to validate the other side of the connection, and also to
  196. authenticate ourselves with the other end. Such certificates must be stored as files using the
  197. FTP server, and they must be placed in specific paths with specific names.
  198. - The certificate to validate the other side goes in: **'/flash/cert/ca.pem'**
  199. - The certificate to authenticate ourselves goes in: **'/flash/cert/cert.pem'**
  200. - The key for our own certificate goes in: **'/flash/cert/private.key'**
  201. .. note::
  202. When these files are stored, they are placed inside the internal **hidden** file system
  203. (just like firmware updates), and therefore they are never visible.
  204. For instance to connect to the Blynk servers using certificates, take the file ``ca.pem`` located
  205. in the `blynk examples folder <https://github.com/wipy/wipy/tree/master/examples/blynk>`_.
  206. and put it in '/flash/cert/'. Then do::
  207. import socket
  208. import ssl
  209. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_SEC)
  210. ss = ssl.wrap_socket(s, cert_reqs=ssl.CERT_REQUIRED, ca_certs='/flash/cert/ca.pem')
  211. ss.connect(socket.getaddrinfo('cloud.blynk.cc', 8441)[0][-1])
  212. Incompatibilities in uhashlib module
  213. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  214. Due to hardware implementation details of the WiPy, data must be buffered before being
  215. digested, which would make it impossible to calculate the hash of big blocks of data that
  216. do not fit in RAM. In this case, since most likely the total size of the data is known
  217. in advance, the size can be passed to the constructor and hence the HASH hardware engine
  218. of the WiPy can be properly initialized without needing buffering. If ``block_size`` is
  219. to be given, an initial chunk of ``data`` must be passed as well. **When using this extension,
  220. care must be taken to make sure that the length of all intermediate chunks (including the
  221. initial one) is a multiple of 4 bytes.** The last chunk may be of any length.
  222. Example::
  223. hash = uhashlib.sha1('abcd1234', 1001) # length of the initial piece is multiple of 4 bytes
  224. hash.update('1234') # also multiple of 4 bytes
  225. ...
  226. hash.update('12345') # last chunk may be of any length
  227. hash.digest()
  228. Unrelated function in machine module
  229. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  230. .. function:: main(filename)
  231. Set the filename of the main script to run after boot.py is finished. If
  232. this function is not called then the default file main.py will be executed.
  233. It only makes sense to call this function from within boot.py.
  234. Adhoc way to control telnet/FTP server via network module
  235. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  236. The ``Server`` class controls the behaviour and the configuration of the FTP and telnet
  237. services running on the WiPy. Any changes performed using this class' methods will
  238. affect both.
  239. Example::
  240. import network
  241. server = network.Server()
  242. server.deinit() # disable the server
  243. # enable the server again with new settings
  244. server.init(login=('user', 'password'), timeout=600)
  245. .. class:: network.Server(id, ...)
  246. Create a server instance, see ``init`` for parameters of initialization.
  247. .. method:: server.init(\*, login=('micro', 'python'), timeout=300)
  248. Init (and effectively start the server). Optionally a new ``user``, ``password``
  249. and ``timeout`` (in seconds) can be passed.
  250. .. method:: server.deinit()
  251. Stop the server
  252. .. method:: server.timeout([timeout_in_seconds])
  253. Get or set the server timeout.
  254. .. method:: server.isrunning()
  255. Returns ``True`` if the server is running, ``False`` otherwise.
  256. Adhoc VFS-like support
  257. ~~~~~~~~~~~~~~~~~~~~~~
  258. WiPy doesn't implement full MicroPython VFS support, instead following
  259. functions are defined in ``uos`` module:
  260. .. function:: mount(block_device, mount_point, \*, readonly=False)
  261. Mounts a block device (like an ``SD`` object) in the specified mount
  262. point. Example::
  263. os.mount(sd, '/sd')
  264. .. function:: unmount(path)
  265. Unmounts a previously mounted block device from the given path.
  266. .. function:: mkfs(block_device or path)
  267. Formats the specified path, must be either ``/flash`` or ``/sd``.
  268. A block device can also be passed like an ``SD`` object before
  269. being mounted.