Re: [riot-devel] Release 2019.07 - dates and feature requests
Hi all, #11077 and #11085 could be in the incoming release but it will require to have #11075 and #10916 merged first. Hopefully, #11075 should be pretty straightforward and #10916 (which introduces the stack) is in the final review state. Any help with the review and/or test process will be highly appreciated ! Cheers, Le sam. 1 juin 2019 à 01:40, Hauke Petersen a écrit : > Hej, > > big +1! Getting the USB+Ethernet slave mode to work would be a major > milestone towards simple to deploy border routers and such. > > So ~4 more weeks seems doable, right?! > > Cheers, > Hauke > > > On 5/31/19 10:11 PM, Mario Gómez wrote: > > Hi all! > > My grain of salt: > > For high impact features: > > PR #11085 (Serial console over USB) & PR #11077 (USB CDC ECM support) > > Those two combined with something like the SAM-BA bootloader (Arduino SAMD > bootloader compatible with BOSSA) would allow us to make easy-upgradeable > one-chip border-router USB dongles based on the ATSAMR21. USB CDC ECM > essentially could remove the need for ethos. > > Regards, > Mario. > > On Fri, May 31, 2019 at 6:51 AM Kevin Weiss > wrote: > >> Dear RIOTers, >> >> >> The release dates for the upcoming release cycle are fixed as follows: >> >> - 28.06.2019 - soft feature freeze, for high impact features >> >> - 08.07.2019 - hard feature freeze, for all features >> >> - 31.07.2019 - Release date >> >> Could you please send your suggestions for features which you would like >> to see merged during this release cycle. >> >> >> Best regards, and happy hacking! >> >> Kevin Weiss >> ___ >> devel mailing list >> devel@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/devel >> > > ___ > devel mailing > listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel > > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] USB PID number
Hi all, Le mar. 26 févr. 2019 à 09:51, Koen Zandberg a écrit : > Hi Juan, > > On 2/25/19 3:19 PM, Juan Ignacio Carrano wrote: > > Hi all, > > > > First of all, great work. Now to the VID, PID matter: I don't think we > > should get any VID. A single PID may be ok. > > > > Product numbers are for products. RIOT is not a product. Rather, it is > > used to build product (or at least that's wath we hope for). Even if > > we obtained an ID it would be irrelevant for everyone except > > developers: if you develop a device, you should get your OWN ids, you > > cannot reuse your OS vendor's. > > > > > > > > I think that having a single PID for "Generic RIOT-powered device" (or > > something of the sort) is valuable, especially for development, and > > for the CI, and we only really need one, not a whole block. That, and > > the fact that we have a more or less large project should be enough > > justification to get a PID from pid.codes. Of course, the docs should > > clearly state that the PID is for use in RIOT development and should > > be changed for actual devices. > > > > A whole VID would not be useful: what would you do with so many PIDs? > > I agree with you here. First of all, I also don't see any use for a VID > for RIOT-os, but hey maybe somebody else has a use case for a full VID. > > For me, a hypothetical RIOT-os PID would be used only for development > and testing. CI jobs, people wanting to test USB or develop USB devices. > As soon as the USB device leaves the building it must have a different > VID/PID owned by the developer/company. Having a PID for this is mostly > for ease of development, so we don't have to use a random VID/PID with > all the consequences. A lot of USB functionality doesn't require a > specific VID/PID, but is purely recognized based on the descriptor > information. > > A second PID could be required if we have our own DFU enabled RIOT > bootloader. For this I wouldn't mind if it was used for actual products > as long as the RIOT bootloader is unmodified. This as in if it claims to > be the RIOT-os DFU bootloader, it should behave like the RIOT-os > bootloader and be able to flash RIOT-os on the mcu with the RIOT-os DFU > tooling. > > I think Koen perfectly sums up the situation and I agree with him. VID is pointless for RIOT, but having two PIDs (one for development, one for DFU) would be great. Of course, it should be clearly state that the devel PID must not be used outside of its original scope. BTW, If people want to be involve. We must port the lowlevel driver and test the stack against several MCUs (EFM32, STM32, Kinetis,etc...). Any help is welcome ! Cheers, > Cheers, > Koen > > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] SAM Flash Read-While-Write
Hello Federico, IIRC, this flash can be use as a virtual EEPROM. Maybe It would be better to write a eeprom driver (like STM32 [1]) rather than add it to the flashpage driver ? I also think this memory is 8KB for SAML21J18 (not 8Kb), which is a lot :) As a side note: SAML21 also have 8KB of Low Power SRAM in addition to its 32 KB of SRAM I've never played with these additional memories but I'll be happy to help. Cheers, Dylan [1] https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common/periph/eeprom.c Le mer. 23 janv. 2019 à 14:27, Federico Pellegrin a écrit : > Hi, > Working on SAML21 based project it came to my attention also the > presence of an 8Kb additional flash that is called "Read-While-Write" > (or RWWEE in the datasheet) that, as far as I understood, can be > programmed and read in a very similar way to the normal flash. This is > currently not supported anyhow in RIOT as far as I see. This is also > present in other SAM chips (a grep on the RIOT sam0 common includes > tells me saml21, samd21 and samr30). > > Well it's just 8Kb (in saml21 case) but a customer is asking about it ;) > > Before starting to fiddle with code I was wondering if any of you > already saw this or had intention to work on or had problems with this > or any information would be great :) > > On the other side I would also be interested in an opinion if the > access to this facility should eventually be kept totally separate > from the current (with some possible code redundancy, but with the > possibility no to include it into a project) or could be integrated > into the current flashpage driver (bringing some complication of the > logic of the current code) > > Thanks! > > Cheers, > Federico > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Module MPU_STACK_GUARD on Cortex-M0+
Hi all, While playing with MPU on Cortex-M23, I encountered a weird thing. The module MPU_STACK_GUARD defines a 32-bytes area at the end of a stack to detect stack overflow and generate a MEM_FAULT (HARDFAULT for Cortex-m0+). [1] I guess the 32-bytes size was chosen because it is the minimal permitted value according to ARM doc [2]. Unfortunately, Cortex-m0+ has a minimal permitted value of 256 bytes [3]. Alexandre ran some tests on nucleo-l053re (using tests/mpu_stack_guard) and they were successful. But I really like to understand why this test is working with wrong parameters... Do we have some MPU experts among us ? :) Note: If you're willing to run tests/mpu_stack_guard on cortex-m0+, don't try on SAM0 based board, they don't have MPU (but they are whitelisted in this test... I'll change that soon). [1] https://github.com/RIOT-OS/RIOT/pull/5564 [2] http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/Cihegaib.html#BABHCHBH [3] http://infocenter.arm.com/help/topic/com.arm.doc.dui0662b/Cihegaib.html#BABHCHBH -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Cortex M33 support
FYI, Microchip sent me a SAML10 and a SAML11 (Cortex-M23) Xplained boards so I can port them to RIOT. Yesterday I was able to run tests/leds on SAML10, but it is still too early to share my ugly hacked code. As I saw we can reuse cortexm_common stuff because armv8-M baseline and mainline instructions set are 100% compatible with armv6-M instructions set. But I found out some bits disappeared from some registers like SCB_CCR_STKALIGN bit. I also think it would be great to support brand new ARM MCU out-of-box ! Le mer. 17 oct. 2018 à 19:44, Thomas C. Schmidt a écrit : > Hi Juan, > > thanks for pointing out: I'll try and check with our contacts to NXP. > > Best, > Thomas > On 17/10/2018 14:17, Juan Ignacio Carrano wrote: > > Hi everyone, > > > > Is anybody working / wanting to work on Cortex M33 support? Currently > > there are no chips available for the general public. AFAICT Nordic and > > NXP are the only ones with pre-production parts. > > > > I'm trying to get samples from both. It would be great if we could have > > at least some basic support for when the devices reach the market. > > > > Also, if somebody has closer contact with either Nordic or NXP, it would > > be great. > > > > Regards, > > > > Juan Ignacio Carrano > > > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > > > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] End of I2C embargo
Dear RIOTers, The I2C rework is now merged into RIOT's master branch, then I am really happy to announce you the end of the I2C embargo ! Don't hesitate to ping pending PRs that were blocked by this embargo so maintainers can have a look at it. This rework will not be present in the 2018.07 release as we lack of time to get things merged, but you can use the master branch if you want to use it. We also create a wiki page [1] to summarize the changes introduced by this rework. We will keep working to improve this documentation. Of course, we cannot guarantee that the new I2C interface is completely bug-free. So if you encounter any errors, weird behaviour or if you have any questions, don't hesitate to send an email to the mailing list or create an issue on Github. We will continue to improve our work. Finally, I would like to deeply thanks every people involved in this huge rework, thank you for your time and your hard will. I'm really proud of what we have done here ! You guys are amazing :) Keep RIOTing ! [1] https://github.com/RIOT-OS/RIOT/wiki/I2C-rework -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] I2C refactoring status
Dear community, The ongoing I2C refactoring effort has been on track for more than a month now. Most of the job has been done but it is now time for testing ! Currently, CC2538, SAM0, STM32 and NRF52 driver has been merged, Kinetis is waiting for tests and atmega/efm32 need some changes to be usable. We have almost 30 opened PRs waiting for tests and reviewing. If you own one of the mentionned platform with an I2C sensor, do not hesitate to test the dedicated PR and share your results as we really really need your help. You can find all the mentionned informations here [1] I hope we will be able to end this effort before the next release which is coming super fast. Keep RIOTing ! [1] https://github.com/RIOT-OS/RIOT/issues/6577 2018-05-29 22:02 GMT+02:00 Dylan Laduranty : > Dear community, > The ongoing I2C refactoring effort has been on track for a whole week. I > think it will take a little more time than I expect. > You can have a look at [1] to see how this is evolving. > All the changes are done on a dedicated branch (new_I2c_if) right now. > Once everything will be done, we will merge the branch to master. > > Such a big rework requires a lot of time but also a lot of hardware > (boards, devices drivers...) > If you want to participate to this huge and intense effort, do not > hesitate to put your name on the list ! > We're looking for people to handle some CPU driver and also some devices > drivers but we also need some help for testing all the current open PRs ! > You can find all the PRs on github labelled I2C REWORK > > The new I2C API will bring more flexibility, more features and also fix > some bugs at the same time. > > Keep RIOTing ! > > [1] https://github.com/RIOT-OS/RIOT/issues/6577 > -- > Dylan Laduranty > -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] I2C refactoring status
Dear community, The ongoing I2C refactoring effort has been on track for a whole week. I think it will take a little more time than I expect. You can have a look at [1] to see how this is evolving. All the changes are done on a dedicated branch (new_I2c_if) right now. Once everything will be done, we will merge the branch to master. Such a big rework requires a lot of time but also a lot of hardware (boards, devices drivers...) If you want to participate to this huge and intense effort, do not hesitate to put your name on the list ! We're looking for people to handle some CPU driver and also some devices drivers but we also need some help for testing all the current open PRs ! You can find all the PRs on github labelled I2C REWORK The new I2C API will bring more flexibility, more features and also fix some bugs at the same time. Keep RIOTing ! [1] https://github.com/RIOT-OS/RIOT/issues/6577 -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] I2C Refactoring and embargo
Dear RIOTers, A RIOT Hackathon will be held at Paris from 22 to 25 May and I think this is the perfect timing to handle the I2C refactoring introduced in [1]. the 22 May, an embargo will be created regarding the I2C API, all I2C drivers and all I2C CPUs peripherals. During this time, all PR's related to I2C will be postponed/blocked. A dedicated branch will also be create at the same time and an issue is already create for tracking the remodeling [2] and will be update soon . I hope this embargo will last 1 or 2 weeks max. This time will be used to update the API for all drivers and all CPU periphs. This refactoring will also introduce some new features like 10 bits addressing. I guess it will be impossible to implement all the new features for all CPUs in such a short amount of time. This is why we will implement these features on several (but not all) CPUs as a proof-of-concept during the embargo for testing purpose. I hope all CPUs will support these features for the 2018.07 release. Any help on this scope is welcome (rewrite drivers, reviews, tests on hardware) even if you cannot attempt the Hackathon. Keep RIOTing ;) [1] https://github.com/RIOT-OS/RIOT/pull/6576 [2] https://github.com/RIOT-OS/RIOT/issues/6577 -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Status of new I2C API
Dear RIOTers and maintainers, I would like to know the current status of the new I2C master API. It's been a long time since we heard about it. I'm willing to work on it and maybe others are also interested. I'm fully aware that such a big rework will take some times and a lot of efforts but this task has to be done. Would it be useful to create a task force ? What do you think ? Cheers -- Dylan Laduranty ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
