[riot-devel] 2017.04 feature freeze
Dear fellow RIOT'ers, I've just created the 2017.04 branch and tagged the first release candidate [1], which means we're now in feature freeze. Theres an issue for tracking the testing progress at [2]. Any help is highly appreciated! Best regards, Kaspar [1] https://github.com/RIOT-OS/RIOT/tree/2017.04-RC1 [2] https://github.com/RIOT-OS/Release-Specs/issues/42 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] [CFP] Elsevier FGCS Journal [IF=2.43] -- SI on "Internet of Things (IoT): Operating System, Applications and Protocols Design, and Validation Techniques"
Dear researching IOTlers, please find below a call for papers for Special Issue in Elsevier Future Generation Computer Systems Journal that might be interesting for some of you. Apologies if you receive multiple copies of this announcement. --- CALL FOR PAPERS Special Issue in Elsevier Future Generation Computer Systems Journal. "Internet of Things (IoT): Operating System, Applications and Protocols Design, and Validation Techniques" Submission Deadline: June 30, 2017 THE THEME -- Internet of Things (IoT) connects durable goods, cars and trucks, industrial and utility components, and sensors to Internet with data analytics capabilities. IoT is flourishing due to technology advancements. The key features of IoT Operating Systems (OSs) are modularity, energy-efficient scheduler, hardware support, architecture, network stacks, reliability, interoperability, unified APIs, generic interfaces, and real-time capabilities. The applications for IoT service scenarios are diverse and challenging. These range from smart energy, transportation, etc. to big data analysis. The integration of all these applications is essential to eventually make everything smart. The memory and energy efficient IoT protocols are desirable. The validation of IoT protocols and applications is a key to success. Therefore, an IoT OS requires to support not only a huge variety of heterogeneous hardware, but also simulators and emulators as well as testbed facilities Further, it should provide th e capability to perform small scale to large scale testing with heterogeneous physical devices and communication technologies. The availability of variety of IoT OSs, low-cost IoT devices, heterogeneous telecommunications technologies, big data technologies and standardization is a key of success for IoT deployment. To fully exploit these technological advancements, there exists many issues related to applications, protocols, testing, interoperability; time bounded big data processing and analysis, heterogeneous communication technologies and platform support. This Special Issue focuses on the most recent advancement in interdisciplinary research areas encompassing IoT OSs, applications and protocols design, development, and validation domain. This Special Issue will bring together researchers from diverse fields such as communication engineering, computer engineering, computer science, electrical and electronics engineering, bio-informatics and mathematics. Through this Special Issue, we invite researchers from industry, academia and government organizations to discuss innovative ideas and contributions, demonstrate results and share standardization efforts on the IoT OSs and related areas. Topics of interest include, but not limited to the following: · IoT Operating Systems (OSs) oEnergy and memory efficient approaches oSensors, IoT platform support and limitations in IoT OSs oInteroperability of IoT OSs protocols and devices oSimulation, emulation and testbed support, limitations and Solutions oResource management for IoT OSs oMemory management for resource constrained IoT devices oSecurity issues and solutions for privacy in IoT OSs oCo-existence of technologies, limitation and solutions oStandard API specifications for IoT OSs · Applications for IoT Service Scenario oSmart energy oSmart transportation oSmart waste management oSmart buildings oSmart physical safety and security oSmart health care oSmart education oSmart Personal Network (SPN) oEdge Computing oCooperative and smart sensing approaches oSensor data collection and management oEfficient big data techniques, processing, and analysis · Protocol overview, issues and solutions oIoT physical layer protocols oIoT MAC layer protocols oIoT network layer protocols oIoT transport layer protocols oIoT applications oRadio Duty Cycling (RDC) oCross layer protocol design · Modeling of IoT heterogeneous wireless technologies, protocols and applications · Simulator/Emulator issues and improvements · Testbed deployment and testing Submission Guidelines: - All submissions have to be prepared according to the Guide for Authors as published in the Journal website at http://ees.elsevier.com/fgcs/. Authors should select “IoT:OS,App,Proto,Valid”, from the “Choose Article Type” pull-down menu during the submission process at EVISE. All contributions must not have been previously published or be under consideration for publication elsewhere. A submission based on one or more papers that appeared elsewhere has to comprise major value-added extensions over what appeared previously (at least 30% new material). Authors are requested to attach to the submitted paper their relevant, previously published
Re: [riot-devel] flash command without compiling
Hey, On 04/18/2017 10:15 AM, Oleg Hahm wrote: I remember that (years ago) I thought that this would be a bad idea, but got overruled. Probably the newbie friendlyness is to be blamed... Anyhow, I have a branch for on-hardware CI testing, where I've added another flash target that doesn't have the dependency. Find the commit here [1]. Kaspar [1] https://github.com/kaspar030/RIOT/commit/c183d152bf36a1e4f2d6ac3ea3b172047dd43eee ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] STM32L073 cpu support in conjunction with spi driver
Hello Alex, thank you for your answer. I configure APB1 and 2 to work at 8Mhz
because my attached device is slow. The values of the spi_divtable were new
calculated via the spi_divtable tool. I wanted just know if spi was tested with
the L073...
Regards, Neo
RIOT OS kernel developers schrieb:
> Hi Neo,
>
> Looking at the configuration you provide, it's hard to tell exactly what is
> the problem. How did you configure the clock for APB1 and APB2 in periph.conf
> ?
> If you set them to use highest speed (32MHz for this MCU), then the
> spi_divtable is wrong and you can reuse the values used for nucleo-l073 where
> the SPI works.
>
> Hope that it helps,
>
> Alex
>
> - Mail original -
>
>> Hello RIOT developers,
>>
>> on the weekend I tried the STM32L073 support in conjunction with spi
>> support but I had no success.
>>
>> I wanted to test this on a board equiped with a STM32L073CZ MCU (48pin
>> TQFP). Therefore I made a copy of the linker file (stm32l073rz.ld ->
>> stm32l073cz.ld) and I altered the boards Makefile.include file to
>> support this derivate (export CPU_MODEL = stm32l073cz).
>>
>> I enabled spi support in the feature list inside of the Makefile
>> (FEATURES_PROVIDED += periph_spi) and altered the device descriptor in
>> the periph_conf.h file but I got no hardware response on the analyzer
>> when I tried to run the second spi interface (SPI2). The MCU does nothing.
>>
>> /**
>> * @nameSPI configuration
>> *
>> * @noteThe spi_divtable is auto-generated from
>> * `cpu/stm32_common/dist/spi_divtable/spi_divtable.c`
>> * @{
>> */
>> static const uint8_t spi_divtable[2][4] = {
>> { /* for APB1 @ 800Hz */
>> 5, /* -> 125000Hz */
>> 3, /* -> 50Hz */
>> 2, /* -> 100Hz */
>> 0 /* -> 400Hz */
>> },
>> { /* for APB2 @ 800Hz */
>> 5, /* -> 125000Hz */
>> 3, /* -> 50Hz */
>> 2, /* -> 100Hz */
>> 0 /* -> 400Hz */
>> }
>> };
>>
>> static const spi_conf_t spi_config[] = {
>> {
>> .dev = SPI1,
>> .mosi_pin = GPIO_PIN(PORT_A, 7),
>> .miso_pin = GPIO_PIN(PORT_A, 6),
>> .sclk_pin = GPIO_PIN(PORT_A, 5),
>> .cs_pin = GPIO_UNDEF,
>> .af= GPIO_AF0,
>> .rccmask = RCC_APB2ENR_SPI1EN,
>> .apbbus = APB2
>> },
>> {
>> .dev = SPI2,
>> .mosi_pin = GPIO_PIN(PORT_B, 15),
>> .miso_pin = GPIO_PIN(PORT_B, 14),
>> .sclk_pin = GPIO_PIN(PORT_B, 13),
>> .cs_pin = GPIO_UNDEF,
>> .af = GPIO_AF0,
>> .rccmask = RCC_APB1ENR_SPI2EN,
>> .apbbus = APB1
>> }
>> };
>>
>> #define SPI_NUMOF (sizeof(spi_config) / sizeof(spi_config[0]))
>> /** @} */
>>
>> The application I tried to run was the tests/periph_spi test application.
>>
>> Do I have to enable some other features or dependencies to get the spi
>> interface running?
>>
>> As far as I have seen the spi driver was rewritten since the last
>> release and I tried to configure it as described on the riot-os.org/api
>> web page.
>>
>> Any thoughts what could be wrong with this configuration?
>>
>> Thanks a lot!
>>
>> Regards,
>>
>> Neo
>>
>> ___
>> 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
Re: [riot-devel] flash command without compiling
Hi! On Tue, Apr 18, 2017 at 10:12:13AM +0200, Kaspar Schleiser wrote: > On 04/17/2017 04:47 PM, Jose Alamos wrote: > > I noticed the 'make flash' recompiles everything before flashing. What's > > the reason behind this? > > Does it actually recompile? > > The flash target in Makefile.include depends on the "all" target, ensuring > that the build is up-to-date. I guess at some point we thought that is a > good idea. I remember that (years ago) I thought that this would be a bad idea, but got overruled. IIRC the reasoning was that otherwise `make flash` may fail. Cheers, Oleg -- printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n"); linux-2.2.16/drivers/char/msp3400.c ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] flash command without compiling
Hey, On 04/17/2017 04:47 PM, Jose Alamos wrote: I noticed the 'make flash' recompiles everything before flashing. What's the reason behind this? Does it actually recompile? The flash target in Makefile.include depends on the "all" target, ensuring that the build is up-to-date. I guess at some point we thought that is a good idea. Removing that dependency stops the forced update. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] STM32L073 cpu support in conjunction with spi driver
Hi Neo,
Looking at the configuration you provide, it's hard to tell exactly what is the
problem. How did you configure the clock for APB1 and APB2 in periph.conf ?
If you set them to use highest speed (32MHz for this MCU), then the
spi_divtable is wrong and you can reuse the values used for nucleo-l073 where
the SPI works.
Hope that it helps,
Alex
- Mail original -
> Hello RIOT developers,
>
> on the weekend I tried the STM32L073 support in conjunction with spi
> support but I had no success.
>
> I wanted to test this on a board equiped with a STM32L073CZ MCU (48pin
> TQFP). Therefore I made a copy of the linker file (stm32l073rz.ld ->
> stm32l073cz.ld) and I altered the boards Makefile.include file to
> support this derivate (export CPU_MODEL = stm32l073cz).
>
> I enabled spi support in the feature list inside of the Makefile
> (FEATURES_PROVIDED += periph_spi) and altered the device descriptor in
> the periph_conf.h file but I got no hardware response on the analyzer
> when I tried to run the second spi interface (SPI2). The MCU does nothing.
>
> /**
> * @nameSPI configuration
> *
> * @noteThe spi_divtable is auto-generated from
> * `cpu/stm32_common/dist/spi_divtable/spi_divtable.c`
> * @{
> */
> static const uint8_t spi_divtable[2][4] = {
> { /* for APB1 @ 800Hz */
> 5, /* -> 125000Hz */
> 3, /* -> 50Hz */
> 2, /* -> 100Hz */
> 0 /* -> 400Hz */
> },
> { /* for APB2 @ 800Hz */
> 5, /* -> 125000Hz */
> 3, /* -> 50Hz */
> 2, /* -> 100Hz */
> 0 /* -> 400Hz */
> }
> };
>
> static const spi_conf_t spi_config[] = {
> {
> .dev = SPI1,
> .mosi_pin = GPIO_PIN(PORT_A, 7),
> .miso_pin = GPIO_PIN(PORT_A, 6),
> .sclk_pin = GPIO_PIN(PORT_A, 5),
> .cs_pin = GPIO_UNDEF,
> .af= GPIO_AF0,
> .rccmask = RCC_APB2ENR_SPI1EN,
> .apbbus = APB2
> },
> {
> .dev = SPI2,
> .mosi_pin = GPIO_PIN(PORT_B, 15),
> .miso_pin = GPIO_PIN(PORT_B, 14),
> .sclk_pin = GPIO_PIN(PORT_B, 13),
> .cs_pin = GPIO_UNDEF,
> .af = GPIO_AF0,
> .rccmask = RCC_APB1ENR_SPI2EN,
> .apbbus = APB1
> }
> };
>
> #define SPI_NUMOF (sizeof(spi_config) / sizeof(spi_config[0]))
> /** @} */
>
> The application I tried to run was the tests/periph_spi test application.
>
> Do I have to enable some other features or dependencies to get the spi
> interface running?
>
> As far as I have seen the spi driver was rewritten since the last
> release and I tried to configure it as described on the riot-os.org/api
> web page.
>
> Any thoughts what could be wrong with this configuration?
>
> Thanks a lot!
>
> Regards,
>
> Neo
>
> ___
> 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
