not logged in | [Login]
This section to be deleted/reformatted/made politically correct at a later date
Creating a pyb module is a complicated task all by itself and I don't want to try and learn both C -> pyb at the same time as ST's CAN hardware all while struggling to push my compiled code to the board (dfu-util is giving me trouble at the moment). Because of all this complexity, I will start by simply creating a "Hello, world!" pyb module within the Unix implementation. I'm a Saab fan, so my module consists of the 6 different Saabs that I've owned. Originally it was going to be a generic module capable of storing any Saab between 1947 and 1993, but I realized this was more difficult and did not match up my example: the LED module. You see, the LEDs on the micropython board are all hard-coded in as static globals instead of being created on-the-fly as you need them - so I too have hard-coded my six Saabs instead of allowing a user to create any Saab (s)he wants. You will then be able to select which of my Saabs you want via an ID (just like selecting LED 1, 2 or 3).
<root>/
refers to the top level directory of micropython. I am referring to the directory with README.md
in it.<root>/unix/saab.c
and <root>/unix/saab.h
. I can compile these into the module by adding the source file to line 73 of <root>/unix/Makefile
.const mp_obj_type_t pyb_saab_type = {...};
See the line 292 of the LED module for reference. This variable contains lots of metadata about our object: its name, a function that can be used for printing our object, a function to create a new instance as well as a dictionary with each of the name of each public method. Lots more metadata can be filled in - just take a look at the definition of mp_obj_type_t.{&mp_type_type }
. So, at a minimum, we have const mp_obj_type_t pyb_saab_type = { {&mp_type_type } };
. This forum post is requesting an explanation for this line of codeLast edited by David Zemon, 2014-07-01 01:32:19