{"push_id":1154686468,"size":235,"distinct_size":34,"ref":"refs/heads/master","head":"3c6e476a996507bed223fab9d3b5dc0b6ddedc5f","before":"4263e7de5300d750d0ed6e2e70c3b692e680c2c3","commits":[{"sha":"bc063a390320336f2da447f9e7d885cb9021469b","author":{"name":"Bogdan Marinescu","email":"c425566f7466ddabfc2ed16361b3008bfda1dae9@arm.com"},"message":"Moved target definitions to JSON format\n\n(long commit message ahead. Sorry about that, it can't be helped.)\n\nThis commit changs targets definition from Python to JSON format, as\npart of the configuration mechanism implementation. There is a new file\nunder workspace_tools/ called \"targets.json\" which contains the target\ndefinitions. \"targets.py\" remains, but becomes a wrapper on top of\n\"targets.json\", with the same interface as before. This has the\nadvantage of not requiring code changes outside \"targets.py\".\n\nMost of the JSON definitions of targets were automatically generated by a\nscript (available upon request since it doesn't make a lot of sense to\ninclude it here), only those targets that had more than one parent in\nthe Python implementation were converted by hand. The target definitions\nshould be pretty self-explanatory. A number of things are different in\nthe JSON implementation (this is just a summary, check docs/mbed_targets.md\n(also part of this PR) for a more complete description):\n\n- \"program_cycle_s\" is now a value (as opposed to a function in the\nPython implementation), since it only returned a number in all the\nPython target implementations. The main definition that actually contains\nsome code (in class \"Target\") remains in target.py\n- array values in \"macros\" and \"extra_labels\" can be modified\ndynamically. Values can be added using \"macros_add\" and\n\"extra_labels_add\" or removed using \"macros_remove\" and\n\"extra_labels_remove\". This mechanism is available for all attributes\nwith a list type, but it's currently enabled only for \"macros\" and\n\"extra_labels\" to keep things simple.\n- \"init_hooks\"/\"binary_hook\" are now implemented in terms of a single\nJSON key valled \"post_binary_hook\". The corresponding code is also in\n\"targets.py\", under the various TargetCode classes (see for example\nLPC4088Code in targets.py).\n\nJust like in the Python implementation, a target can inherit from zero,\none or more targets. The resolution order for the target's attributes\nfollows the one used by the Python code (I used\nhttp://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path\nas a reference for the implementation of resolution order).\n\nThis is obviously a very dangerous commit, since it affects all targets.\nI tested compilation for a number of targets (K64F, LPC1768, NRF51822)\nbut there's definitely a lot more to be done in terms of testing.\n\nI also tried to test in a different way: I wrote a script that imports the\nold (Python) and the new (JSON) implementations and verifies that the\nattributes in the old implementations exist and have the same values\nin the new implementations (it also verifies that the attribute\nresolution order is the same in the two implementations). If you're\ninterested, the script is here:\n\nhttps://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c\n\nAnd the results of running the script are below (note that the script\noutputs only the target names that were found to be problematic):\n\nNRF51_MICROBIT_BOOT:\n    Resolution order is different in old and new\n        old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']\n        new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']\n    'extra_labels' has different values in old and new\n        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT']\n        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT']\n    'macros' has different values in old and new\n        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']\n        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']\nNRF51_MICROBIT:\n    Resolution order is different in old and new\n        old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']\n        new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']\n    'extra_labels' has different values in old and new\n        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110']\n        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K']\n    'macros' has different values in old and new\n        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC']\n        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC']\nNRF51_MICROBIT_OTA:\n    Resolution order is different in old and new\n        old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']\n        new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']\n    'extra_labels' has different values in old and new\n        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT']\n        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT']\n    'macros' has different values in old and new\n        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']\n        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']\nNOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA']\n\nThe reasons for the above output are subtle and related to the\nextremely weird way in which we defined target data in the Python\nimplementation: we used both class attributes and instance attributes.\nThis can complicate resolution order quite a bit and those two levels\ndon't exist in JSON: there's only one attribute type (equivalent to\nPython's instance attributes). To make that work, I had to change the\ninheritance order of the above targets (that use multiple inheritance)\nwhich in turn changed the order of some macros and extra_labels (and of\ncourse the resolution order). No harm done: the values are the same,\nonly their ordering is different. I don't believe this causes any\nproblems for 'extra_labels' and 'macros'.\n\nThis method of testing has its limitations though; in particular, it\ncan't test the hooks. I'm opened to ideas about how to test this better,\nbut I think that we need to remember that this commit might break some\ntargets and keep an eye out for \"weird errors\" in the future.","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/bc063a390320336f2da447f9e7d885cb9021469b"},{"sha":"78767491f72e04070af922110ed6f8a291aec751","author":{"name":"Bartosz Szczepanski","email":"657df79d5bb8f641123e2574ba9b152b5ed3fd04@tieto.com"},"message":"Added CAN API for STM32F3xx family\n\n* STM32F3xx family have only one CAN bus\n\nChange-Id: Icaed8ff8ca4a68ebbf2c124655e7368423fb71cd","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/78767491f72e04070af922110ed6f8a291aec751"},{"sha":"656d1953d9e982c4000aba4ebf45f770c51da132","author":{"name":"Bartosz Szczepanski","email":"657df79d5bb8f641123e2574ba9b152b5ed3fd04@tieto.com"},"message":"[NUCLEO_F334R8] Added CAN support\n\nAdded CAN API support for NUCLEO_F334R8 target.\n\n*stm32f334x8.h* file was changed to avoid compilation errors.\n\nChange-Id: Ic7b3273ffe24940ecdc189d2566a6a7f66825ce6","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/656d1953d9e982c4000aba4ebf45f770c51da132"},{"sha":"9a78b010a0fc51d42a87fa759972e1c27981c3f5","author":{"name":"Bartosz Szczepanski","email":"657df79d5bb8f641123e2574ba9b152b5ed3fd04@tieto.com"},"message":"[NUCLEO_F303RE] Added CAN support\n\nAdded CAN API support for NUCLEO_F303RE target.\n\n*stm32f303xe.h* file was changed to avoid compilation errors.\n\nChange-Id: Ia6519c982261d43165dbce73cab7cfc0617474e2","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/9a78b010a0fc51d42a87fa759972e1c27981c3f5"},{"sha":"347a5e629d5aad20bbff60f5af4a8f8e7186a427","author":{"name":"Bartosz Szczepanski","email":"657df79d5bb8f641123e2574ba9b152b5ed3fd04@tieto.com"},"message":"[NUCLEO_F303K8] Added CAN support\n\nAdded CAN API support for NUCLEO_F303K8 target.\n\n*stm32f303x8.h* file was changed to avoid compilation errors.\n\nChange-Id: If093c84f19c5a5ef68938af4653a25271c1108ba","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/347a5e629d5aad20bbff60f5af4a8f8e7186a427"},{"sha":"f1c42bfc6914bb3a14532279e611a3316ff0a4bc","author":{"name":"Bartosz Szczepanski","email":"657df79d5bb8f641123e2574ba9b152b5ed3fd04@tieto.com"},"message":"[NUCLEO_F302R8] Added CAN support\n\nAdded CAN API support for NUCLEO_F302R8 target.\n\n*stm32f302x8.h* file was changed to avoid compilation errors.\n\nChange-Id: Ia4ee8a90fe3f0ad6955dde21e78ea4a6c05e4fcd","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/f1c42bfc6914bb3a14532279e611a3316ff0a4bc"},{"sha":"b53c7eb128753369f9528f970f67240700073d37","author":{"name":"Bogdan Marinescu","email":"c425566f7466ddabfc2ed16361b3008bfda1dae9@arm.com"},"message":"Fixed description on 'default_toolchain' in the documentation","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/b53c7eb128753369f9528f970f67240700073d37"},{"sha":"54a1e61871807907226f75202f53077b7d2cf75a","author":{"name":"0xc0170","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"mbed lib revision - 121","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/54a1e61871807907226f75202f53077b7d2cf75a"},{"sha":"61e229603765a9103b905ca2ce57ec7eac96a7d9","author":{"name":"Adam Green","email":"0dfa52244c5913a4e7422bcdf253637831388cea@foo.bar"},"message":"Fix NXP LPCxxxx i2c_start() handling of repeated start\n\nIn repeating start scenarios, there was a bug in the I2C driver for\nvarious NXP LPCxxxx parts which could allow an extra I/O from the\nprevious operation to leak through. The scenario I encountered which\ntriggered this bug went like so:\n* The higher level application code would first do an I2C write that\n  doesn't send a stop bit (use repeating start instead.)\n* The higher level application code would then issues an I2C read\n  operation which begin with a call to i2c_start().\n* i2c_start() would clear the SI bit (interrupt flag) at the top of\n  its implementation.\n* i2C_start() would then get interrupted right after clearing the SI\n  bit.\n  * While the CPU is off running the ISR code, the I2C peripheral\n    repeats the last byte written to I2CDAT and then sets the SI bit to\n    indicate that the write has completed.\n  * The ISR returns to allow the i2c_start() to continue execution.\n* i2c_start() would then set the STA bit but it is too late.\n* i2c_start() waits for the SI bit to be set but it is already set\n  because of the completed byte write and not because of the repeated\n  start as expected.\n\nFor me this bug would cause strange interactions between my ISRs and\nthe code using I2C to read from the MPU-6050 IMU. I would be getting\nvalid orientation data and then all of a sudden I would start receiving\nwhat looked like random values but I think it was just reading from the\nincorrect offset in the device's FIFO.\n\nIt appears that atleast one other person has seen this before but it\nwas never root caused since it required specific timing to reproduce:\n  https://developer.mbed.org/forum/bugs-suggestions/topic/4254/\n\nThis bug can be found in most of the NXP I2C drivers and this commit\ncontains a fix for them all. I however only have the LPC1768 and\nLPC11U24 for testing.\n\nMy fix does the following:\n* No longer clears the SI bit in the i2c_conclr() call near the\n  beginning of the i2c_start() function. It was this clear that\n  previously caused the problem as described above.\n* The second part of the fix was to instead clear the SI bit after\n  the STA (start) bit has been set with the i2c_conset() call.\n* The clearing of the SI bit should be skipped if there isn't an\n  active interrupt when first entering i2c_start(). If you clear\n  the SI bit when there isn't an active interrupt then the code\n  is likely to skip over the interrupt for the start bit which was\n  just sent and then allow the I2C peripheral to start sending the\n  slave address before it has even been loaded into the I2CDAT\n  register.","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/61e229603765a9103b905ca2ce57ec7eac96a7d9"},{"sha":"f7b629664d9755efce01254aceeb47220b1c5876","author":{"name":"0xc0170","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"HAL - nordic Lib folder back\n\nIt was removed with hal/rtos rearrangement.","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/f7b629664d9755efce01254aceeb47220b1c5876"},{"sha":"ea72444c968c650561713b0dc6eed607c251a5f3","author":{"name":"0xc0170","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"mbed lib revision - 121","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/ea72444c968c650561713b0dc6eed607c251a5f3"},{"sha":"efe8457036c99b54a23e3ad26eda021e48a800f3","author":{"name":"Jerome COUTANT","email":"8f0b311338950a4a0626b590a9e8b43e782f63e9@st.com"},"message":"Update .gitignore for build directory","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/efe8457036c99b54a23e3ad26eda021e48a800f3"},{"sha":"1ab7d738051bc51b48f1678469797fbd0f415e14","author":{"name":"Christopher Haster","email":"c9dfbd20ba219d94babf08c3d38af60e70dc2c1e@utexas.edu"},"message":"Added Thread::start and Thread::join for managing lifetime of threads\n\n- Allows threads to started separately from when they are declared,\n  avoiding the need to dynamically allocate threads at runtime.\n- Allows multiple threads to join without forceful termination. Allowing\n  threads to synchronize on cleanup.","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/1ab7d738051bc51b48f1678469797fbd0f415e14"},{"sha":"627fe55c21aaf61933fc4603c98ab72c3eb852bd","author":{"name":"0xc0170","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"Synch - fix lwip-eth path\n\nFixes #1786 issue","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/627fe55c21aaf61933fc4603c98ab72c3eb852bd"},{"sha":"745ebbf4557f0f3964f73063c1d88ddbcda0ed22","author":{"name":"Martin Kojtal","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"Merge pull request #1787 from 0xc0170/fix_1786\n\nSynch - fix lwip-eth path","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/745ebbf4557f0f3964f73063c1d88ddbcda0ed22"},{"sha":"db49c1edebc3516ee61197641f7cfbdeaea5482f","author":{"name":"Martin Kojtal","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"Merge pull request #1789 from mbedmicro/release\n\nRelease v121","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/db49c1edebc3516ee61197641f7cfbdeaea5482f"},{"sha":"9328e4a660cf16f7f9371e1fe2ca130698123399","author":{"name":"0xc0170","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"Travis - remove install sh script\n\ntravis.yaml file - add before install, print versions of tools we use","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/9328e4a660cf16f7f9371e1fe2ca130698123399"},{"sha":"a59785888ddf68e0673ff0403dee87846b1d7456","author":{"name":"Martin Kojtal","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"Merge pull request #1790 from 0xc0170/fix_travis\n\nTravis - remove install sh script","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/a59785888ddf68e0673ff0403dee87846b1d7456"},{"sha":"0203b96b5fe58b247ff229549d20ab4c1ccf0d5f","author":{"name":"Martin Kojtal","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"Merge pull request #1780 from jeromecoutant/dev_gitignore\n\nUpdate .gitignore for build directory","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/0203b96b5fe58b247ff229549d20ab4c1ccf0d5f"},{"sha":"d898c11e428f3193eca33c9638efeb377ccd9f60","author":{"name":"0xc0170","email":"1056aef94d1050b634331817f9314612695380a9@rocketmail.com"},"message":"api - doxygen improvements, unused parameters fixes\n\nThis patch is taken from mbed-drivers master.","distinct":false,"url":"https://api.github.com/repos/screamerbg/mbed/commits/d898c11e428f3193eca33c9638efeb377ccd9f60"}]}
{"actor":{"display_login":"screamerbg"}}