[riot-devel] Notification: Hack'n'ACK @ Tue Aug 27, 2019 5pm - 10pm (CEST) (RIOT Events)
This is a notification for: Title: Hack'n'ACK https://meet.jit.si/riot-hacknack When: Tue Aug 27, 2019 5pm – 10pm Central European Time - Berlin Where: FU Berlin; HAW Hamburg Calendar: RIOT Events Who: * Martine Lenders - creator Event details: https://www.google.com/calendar/event?action=VIEW=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2dfMjAxOTA4MjdUMTUwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn=1 Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this email at the account peterschme...@gmail.com because you are subscribed for notifications on calendar RIOT Events. To stop receiving these emails, please log in to https://www.google.com/calendar/ and change your notification settings for this calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Issue with implementation of multiple boards in one directory
Hi, I think the question is what mapping you want to have between a board (the physical hardware) and a RIOT board. If the mapping should be 1:1, than one physical board could have different CPUs and configurations. If you however agree with a 1:n mapping, than having different RIOT boards for each configuration of a board is fine. With the issues you presented in mind, I'd say a 1:n mapping might be the solution with the least maintenance overhead, provided that `boards/common` is heavily used to avoid duplication. Kind regards, Marian On Mon, 26 Aug 2019 15:34:30 +0200 Bas Stottelaar wrote: > Hi Gaëten, > > BOARD_MODULE is used by the Silicon Labs SLWSTK6000b because it is one board > with many supported CPU daughter boards (different CPU, other radio configs). > You would buy that board, but also need to buy this daughter board separately. > > A similar approach is used by the EFM32 CPU family. The (incomplete) list of > daughter boards is here: > https://github.com/RIOT-OS/RIOT/blob/master/boards/slwstk6000b/modules.txt > > Kind regards, > Bas > > > Op 26 aug. 2019 om 14:41 heeft Gaëtan Harter > > het volgende geschreven: > > > > Dear RIOT developers, > > > > as part of migrating CPU and CPU_MODEL definition to `Makefile.features` I > > am facing custom handling of multiple boards in the same directory with > > sometime creative handling but not a proper build system integration. > > > > There are multiple issues with this: > > * none of the alternative boards are ever be compiled in the CI > > * when testing, giving multiple variables to specify a board is not really > > handled > > * building the separate boards is not handled with `BUILD_IN_DOCKER` > > * custom non standard configuration variables that are not properly handled > > in the whole build system > > > > The current implementation are currently done through: > > > > * Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` > > variable is not passed to docker > > * mulle (2 possibilities) > > * pba-d-01-kw2x (3 possibilities) > > * cc2538dk (no documentation but I think this one is just a mis-write and > > not a wanted thing) > > * Using a `STM32F103C8_FLASH_HACK` variable to just set a different > > `CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just > > documented for the `bluepill` > > * An undocumented `BOARD_MODULE` variable that triggers a wildcard then a > > grep to find `CPU_MODEL` (yes it queries your filesystem for a static > > mapping). Its generic with many possible values but only implemented for 2 > > "board modules" > > > > I would like to know who really uses these boards modifications, and what > > we should do with them. Why were they implemented in the first place > > instead of having separate boards? Would have prevented having them merged? > > > > Should we just split all these boards, it would currently result in 5 or 6 > > boards (depending on the blackpill). > > > > Should we keep support for multiple boards together? if yes, can we limit > > to only changing `CPU_MODEL` through this variable and remove the other > > custom handling? Still knowing they would not be automatically tested by CI. > > > > I am willing to take care of the required changes when a direction is > > decided. > > > > Regards, > > Gaëtan - cladmi > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel pgpBuYZdn2LCd.pgp Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Issue with implementation of multiple boards in one directory
Hi Gaëten, BOARD_MODULE is used by the Silicon Labs SLWSTK6000b because it is one board with many supported CPU daughter boards (different CPU, other radio configs). You would buy that board, but also need to buy this daughter board separately. A similar approach is used by the EFM32 CPU family. The (incomplete) list of daughter boards is here: https://github.com/RIOT-OS/RIOT/blob/master/boards/slwstk6000b/modules.txt Kind regards, Bas > Op 26 aug. 2019 om 14:41 heeft Gaëtan Harter het > volgende geschreven: > > Dear RIOT developers, > > as part of migrating CPU and CPU_MODEL definition to `Makefile.features` I am > facing custom handling of multiple boards in the same directory with sometime > creative handling but not a proper build system integration. > > There are multiple issues with this: > * none of the alternative boards are ever be compiled in the CI > * when testing, giving multiple variables to specify a board is not really > handled > * building the separate boards is not handled with `BUILD_IN_DOCKER` > * custom non standard configuration variables that are not properly handled > in the whole build system > > The current implementation are currently done through: > > * Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` > variable is not passed to docker > * mulle (2 possibilities) > * pba-d-01-kw2x (3 possibilities) > * cc2538dk (no documentation but I think this one is just a mis-write and > not a wanted thing) > * Using a `STM32F103C8_FLASH_HACK` variable to just set a different > `CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just documented > for the `bluepill` > * An undocumented `BOARD_MODULE` variable that triggers a wildcard then a > grep to find `CPU_MODEL` (yes it queries your filesystem for a static > mapping). Its generic with many possible values but only implemented for 2 > "board modules" > > I would like to know who really uses these boards modifications, and what we > should do with them. > Why were they implemented in the first place instead of having separate > boards? Would have prevented having them merged? > > Should we just split all these boards, it would currently result in 5 or 6 > boards (depending on the blackpill). > > Should we keep support for multiple boards together? if yes, can we limit to > only changing `CPU_MODEL` through this variable and remove the other custom > handling? Still knowing they would not be automatically tested by CI. > > I am willing to take care of the required changes when a direction is decided. > > Regards, > Gaëtan - cladmi > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Issue with implementation of multiple boards in one directory
Dear RIOT developers, as part of migrating CPU and CPU_MODEL definition to `Makefile.features` I am facing custom handling of multiple boards in the same directory with sometime creative handling but not a proper build system integration. There are multiple issues with this: * none of the alternative boards are ever be compiled in the CI * when testing, giving multiple variables to specify a board is not really handled * building the separate boards is not handled with `BUILD_IN_DOCKER` * custom non standard configuration variables that are not properly handled in the whole build system The current implementation are currently done through: * Using a default `CPU_MODEL ?= default_model` however the `CPU_MODEL` variable is not passed to docker * mulle (2 possibilities) * pba-d-01-kw2x (3 possibilities) * cc2538dk (no documentation but I think this one is just a mis-write and not a wanted thing) * Using a `STM32F103C8_FLASH_HACK` variable to just set a different `CPU_MODEL`. It applies to `bluepill` and `blackpill` but is just documented for the `bluepill` * An undocumented `BOARD_MODULE` variable that triggers a wildcard then a grep to find `CPU_MODEL` (yes it queries your filesystem for a static mapping). Its generic with many possible values but only implemented for 2 "board modules" I would like to know who really uses these boards modifications, and what we should do with them. Why were they implemented in the first place instead of having separate boards? Would have prevented having them merged? Should we just split all these boards, it would currently result in 5 or 6 boards (depending on the blackpill). Should we keep support for multiple boards together? if yes, can we limit to only changing `CPU_MODEL` through this variable and remove the other custom handling? Still knowing they would not be automatically tested by CI. I am willing to take care of the required changes when a direction is decided. Regards, Gaëtan - cladmi ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Thingy52: Real time terminal output
Much appreciated! On Mon, Aug 26, 2019 at 9:44 AM Hauke Petersen wrote: > Hi Rik, > > it has been a while since I last used that board. I have one here, so I > will give this a test sometime today. I'll let you know what I can find out. > > Cheers, > Hauke > > > On 8/22/19 10:49 PM, Rik Gene wrote: > > Dear All, > > I'm not getting through to the shell when running > release-2019.07/examples/default on the Thingy:52. > > I'm using a JLink-OB on another DK. The following devices show up on Linux: > /dev/ttyACM0 > /dev/ttyACM1 > /dev/ttyACM2 > > I've tried them all with no success. > > Programming works fine, but the RTT terminal doesn't: > > Downloading file > [release-2019.07/examples/default/bin/thingy52/default.bin]... > Comparing flash [100%] Done. > Erasing flash [100%] Done. > Programming flash [100%] Done. > Verifying flash [100%] Done. > J-Link: Flash download: Bank 0 @ 0x: 1 range affected (16384 bytes) > J-Link: Flash download: Total time needed: 0.327s (Prepare: 0.032s, > Compare: 0.004s, Erase: 0.000s, Program: 0.280s, Verify: 0.002s, Restore: > 0.007s) > O.K. > > release-2019.07/dist/tools/jlink/jlink.sh term_rtt > ### Starting RTT terminal ### > Twisted not available, please install it if you want to use pyterm's JSON > capabilities > 2019-08-22 22:03:24,215 - WARNING # Host name for TCP connection is > missing, defaulting to "localhost" > 2019-08-22 22:03:24,216 - INFO # Connect to localhost:19021 > Welcome to pyterm! > Type '/exit' to exit. > 2019-08-22 22:03:25,220 - INFO # SEGGER J-Link V6.48a - Real time terminal > output > 2019-08-22 22:03:25,221 - INFO # J-Link OB-K22-NordicSemi compiled Feb 14 > 2019 14:03:18 V1.0, SN=960077373 > 2019-08-22 22:03:25,221 - INFO # Process: JLinkExe > > Any ideas? > > Cheers, > Rik > > ___ > 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
Re: [riot-devel] Thingy52: Real time terminal output
Hi Rik, it has been a while since I last used that board. I have one here, so I will give this a test sometime today. I'll let you know what I can find out. Cheers, Hauke On 8/22/19 10:49 PM, Rik Gene wrote: Dear All, I'm not getting through to the shell when running release-2019.07/examples/default on the Thingy:52. I'm using a JLink-OB on another DK. The following devices show up on Linux: /dev/ttyACM0 /dev/ttyACM1 /dev/ttyACM2 I've tried them all with no success. Programming works fine, but the RTT terminal doesn't: Downloading file [release-2019.07/examples/default/bin/thingy52/default.bin]... Comparing flash [100%] Done. Erasing flash [100%] Done. Programming flash [100%] Done. Verifying flash [100%] Done. J-Link: Flash download: Bank 0 @ 0x: 1 range affected (16384 bytes) J-Link: Flash download: Total time needed: 0.327s (Prepare: 0.032s, Compare: 0.004s, Erase: 0.000s, Program: 0.280s, Verify: 0.002s, Restore: 0.007s) O.K. release-2019.07/dist/tools/jlink/jlink.sh term_rtt ### Starting RTT terminal ### Twisted not available, please install it if you want to use pyterm's JSON capabilities 2019-08-22 22:03:24,215 - WARNING # Host name for TCP connection is missing, defaulting to "localhost" 2019-08-22 22:03:24,216 - INFO # Connect to localhost:19021 Welcome to pyterm! Type '/exit' to exit. 2019-08-22 22:03:25,220 - INFO # SEGGER J-Link V6.48a - Real time terminal output 2019-08-22 22:03:25,221 - INFO # J-Link OB-K22-NordicSemi compiled Feb 14 2019 14:03:18 V1.0, SN=960077373 2019-08-22 22:03:25,221 - INFO # Process: JLinkExe Any ideas? Cheers, Rik ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
