Hi,
what would be the right way, if there is one, to use vendor code without
modifications in case of bunch of following error messages?
"error: function declaration isn't a prototype [-Werror=strict-prototypes]"
Regards
Gunar
--
Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
Hi,
what is the right location for additional settings of CFLAGS, INCLUDES
or LINK_FLAGS that are required by a pseudomodule which is enabled in
Makefile.include of CPU? Should these additional settings be done in
Makefile.include or in Makefile.dep of this CPU?
Regards
Gunar
--
Wenn du laufen
t visible to the compiler during
> compilation of periph/abcd.c, so it can't fully perform DCE and other
> optimizations.
Ah ok, I understand.
To summarize your e-mail, you would advise to change the definitions of
ESP32 boards to expose configuration structures in header files
according to
rds
Gunar
--
Dr. Gunar Schorcht
Mission Level Design GmbH
Langewiesener Strasse 22
98693 Ilmenau
schor...@mldesigner.de
Sitz der Gesellschaft:
Lohmühlenweg 2
99310 Arnstadt
Amtsgericht Jena: HRB 111384
Geschäftsführung: Dipl.-Inf. Tino Jungebloud
--
Wenn du laufen willst, lauf eine Meile. We
Hi,
I'm thinking about to revise the ESP32 board definitions and would need
an advice from experienced core developers.
Most (if not all) boards define their peripheral configuration of ADCs,
DACs and PWMs in `periph_conf.h` in a kind of static const arrays and
define macros based on the size of
Hi,
I don't see any reason why not to start with an existing board
definition and to change it as required.
Sparkfun ESP32 Thing and HUZZAH32 are quite generic boards like the many
others that have nothing else on board than the ESP32, e.g., all ESP32
DevKit clones (esp32-wroom-32) or the MH-ET
Hi Jose,
is it necessary to tell you also features that were merged into master since
last release or are they included automatically, e.g., the ESP8266 platform?
Regards
Gunar
Am 4. Oktober 2018 15:09:06 MESZ schrieb "Alamos, Jose"
:
>Dear RIOTers,
>
>
>The 2018.10 release is on its way!
>
>
n should of course correspond to the
data format of raw data.
Regards
Gunar
On 26.09.2018 12:16, Juan Ignacio Carrano wrote:
> Hi Gunar,
>
> I'm not very experienced on the driver development side, but enough as a
> user to see some issues.
>
> On 9/26/18 9:27 AM, Gunar Schor
ntation,
>> e.g. reviving the concept of RDM [1] ?)
>>
>> Best
>>
>> Emmanuel
>>
>> [1] https://github.com/RIOT-OS/RIOT/pull/6191
>>
>>
>> On Wed, Sep 26, 2018 at 11:38 AM Gunar Schorcht > <mailto:gu...@schorcht.net>> wrote:
>
Hi Hauke,
many thanks for your comprehensive and clearifying answers. Most of them
met my thoughts about driver design.
>> - Should a driver support at least data-ready interrupts (if possible at
>> all) to realize event-driven data retrieval?
> If the driver comes with a 'full/extra'
Hi,
I wrote a series of sensor drivers for esp-open-rtos/ESP-IDF, for
example for different ST sensors, the BME680, the CCS811 or the SHT3x. I
would like to port some of these drivers to RIOT OS. All the drivers are
quite complex as they try to cover all the features of the sensors.
I have seen
Hi,
It is often necessary to enable or disable various functions at
compilation time, for example, to test dependencies. In RIOT, features
are activated using the module concept:
USEMODULE + = feature
I'm wondering whether there is a possibility to enable modules without
changing the
Hi Juan,
every approach which is not bloating a git repository is surely the best
one. IMHO, it is important that the approach gives the board developer
the possibility to upload/update pictures without involving maintainers.
Would it also be possible with git-lfs to give the board developers
Hi Jose,
last week, when I wrote the documentation for the ESP8266 boards, I had
to realize, that I had to change some pictures several times during the
documentation process.
I think the wiki approach to ask the maintainers everytime is quite
impractical:
1. Maintainers are additionally
quality.
Let's see what RIOT's maintainers think about it.
Regards
Gunar
On 28.08.2018 10:45, Juan Ignacio Carrano wrote:
> Hi Gunar,
>
> On 8/27/18 7:05 PM, Gunar Schorcht wrote:
>> Hi,
>>
>> it seems that the style of the output changes either if a variable or
>
; and "MTD emulation configuration" look different.
Regards
Gunar
On 27.08.2018 18:50, Gunar Schorcht wrote:
> Hi,
>
> finally, I'm trying to improve the doxygen documentation of
> board*.h/periph*.h configuration files for my ESP8266 port.
>
> I t
Hi,
finally, I'm trying to improve the doxygen documentation of
board*.h/periph*.h configuration files for my ESP8266 port.
I tried to use the @name command together with @{ and }@ , to group all
definitions that are related to a certain peripheral interface, e.g.,
I2C interface.
It seems that
Hi,
I'm trying again to sort the definitions of board configurations. I feel
like doing this for the tenth time.
I have taken a look at many board.h, periph_conf.h, board_common.h and
periph_conf_common.h files for different platforms, eg., Arduino*,
Nucleo*, IoTlab, ...
The difference between
Hello,
RIOT defines a low-level CAN device driver interface.
Suppose the MCU (for example, Espressifs ESP32) provides a CAN hardware
implementation that could be used to integrate CAN peripherals into RIOT
if there were a low-level CAN device driver for it. So I thought about
including such a
a
queue with a certain queue lenght and arbitrary item size. All
exisiting tasks can send items to and receive items from this queue,
also on single processor architectures.
Regards
Gunar
Regards,
Juan.
On 07/12/2018 09:58 AM, Gunar Schorcht wrote:
Hi,
what would be the best way
but fixed size in the queue.
Regards
Gunar
Zitat von Kaspar Schleiser :
Hi Gunar,
On 07/12/2018 09:58 AM, Gunar Schorcht wrote:
what would be the best way, if there is one, to use the existing
mechanisms to implement a message queue that is not bound to the
receiving thread?
What I'm looking
Hi,
what would be the best way, if there is one, to use the existing
mechanisms to implement a message queue that is not bound to the
receiving thread?
What I'm looking for is a message queue that can be used by a number of
threads to send messages to and receive messages from the shared queue,
On 10.05.2018 13:02, Cristiano Gavião wrote:
> Hi Gunar,
>
> may I ask you to tell us what is the current status ?
>
> thanks,
>
> Cristiano
>
>
> On 09/04/2018 18:38, Gunar Schorcht wrote:
>> Hi Martine,
>>
>> yes, I will provide a PR as soon as I had
Hi,
can RIOT be ported to multicore architectures? As I understand the
scheduler, there can always be only active thread at any time (thread_t
*active_thread). That is, it is not possible to have multiple threads
active on different cores, right?
Regards
Gunar
--
Wenn du laufen willst, lauf
with RIOT using a single
> core?
>
> cheers
>
> Emmanuel
>
> On Fri, May 4, 2018 at 3:08 PM, Gunar Schorcht <gu...@schorcht.net
> <mailto:gu...@schorcht.net>> wrote:
>
> Hi,
>
> I just want to inform that I have started a RIOT port for ESP32.
&g
better documented than ESP8266. So I hope I can provide a
first version in less than 2 months.
Regards
Gunar
On 14.04.2018 16:15, Gunar Schorcht wrote:
> Hi,
>
> Has anyone already tried a RIOT port for the Espressif's ESP32?
>
> If not, I would start a port and would check fi
t will work on the ESP32 (the successor of the
>> ESP8266),
>> too?
>>
>> cheers
>> Mathias
>>
>> On Mon, 2018-02-26 at 13:00 +0100, Gunar Schorcht wrote:
>>> Hi,
>>>
>>> I just want to let the community to know that I'm trying an ES
Hi,
Has anyone already tried a RIOT port for the Espressif's ESP32?
If not, I would start a port and would check first which parts of my
Espressif ESP8266 port could be reused.
Regards
Gunar
--
Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
kennenlernen willst, dann lauf
Hi,
I have some files bundled with the ESP8266 port that contain a vendor
specific MIT license. Command dist/tools/licenses/check.sh fails since
this pattern is not known.
What is the right way to add a new license test pattern in
dist/tools/licenses/patterns? As usual PR or is there any other
Hi there,
today I provided a pull request for my port of RIOT-OS to ESP8266.
Now the question is, whether I should already start to document it in
the wiki or to wait until it is merged.
Even though I documented on how to install the tool chain and how to use
ESP8266 in a README.md file in the
already asking for.
Regards
Gunar
On 07.04.2018 14:49, Martine Lenders wrote:
> Hi Gunar,
>
> Cool, do you think you can get it in a state where you can provide a PR?
>
> Cheers,
> Martine
>
> 2018-04-07 14:00 GMT+02:00 Gunar Schorcht <gu...@schorcht.net
&
Hello,
I just want to inform that I have commited a first working version of
the RIOT port to ESP8266 to my fork at
g...@github.com:gschorcht/RIOT-Xtensa-ESP8266.git
Regards
Gunar
--
Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
kennenlernen willst, dann lauf Marathon. (Emil
P packets might be a place to start?
>>
>> I'm not a RIOT expert - so that's where I stand.
>>
>> If RIOT supports Sockets or MQTT that might also be worth looking into.
>>
>> Regards
>>
>> David
>>
>> On 2018-03-25 05:33, Gunar Schorcht wrote:
>
Hello,
most parts of my RIOT-OS port to the ESP8266 has been implemented. GPIO,
SPI, I2C, UART, PWM seem to be ready and most of local applications are
working.
However, RIOT-OS makes no real sense without networking. Unfortunately,
ESP8266 doesn't have Zigbee or 802.15.4 radio interface on
Hi,
I just want to let the community to know that I'm trying an ESP8266
port. At the moment
- the core's thread interface is implemented and tested,
- the core's irq interface is implemented and tested,
- GPIO handling module periph_gpio is implemented and tested,
- small applications like
35 matches
Mail list logo
