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 ipc_pi
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 board
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
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
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 <mailto:gu...@schorcht.net>>
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 c
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
pr
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 Marat
r port 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'
much 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 c
th RIOT using a single
> core?
>
> cheers
>
> Emmanuel
>
> On Fri, May 4, 2018 at 3:08 PM, Gunar Schorcht <mailto:gu...@schorcht.net>> wrote:
>
> Hi,
>
> I just want to inform that I have started a RIOT port for ESP32.
>
> I suppose
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 ein
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,
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,
a
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 f
u define 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 be
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 low
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 *
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 t
; 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 tried to use the
utput 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 vari
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 burdene
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
acc
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 mak
ment:
>
> USEMODULE="sdcard_spi mrf24j40" BOARD=... make ...
>
> Regards,
> Martine
>
> Am Do., 6. Sep. 2018 um 10:33 Uhr schrieb Gunar Schorcht
> mailto:gu...@schorcht.net>>:
>
> Hi,
>
> It is often necessary to enable or disable
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 t
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' configurati
ocumentation,
>> 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
nction 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, G
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!
>
>
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 L
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
Regards
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 Meil
use the whole array is not 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
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
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
36 matches
Mail list logo