Thanks
On 29-05-19 13:02, Robert Hartung wrote:
Hey everyone,
let me say a few words as Kaspar and I have been driving the
implementation of this. In general there is no need to manually go to
sleep, as the deepest sleep mode will always be selected from the idle
thread depending on the
On 29/5/19 14:58, Robin wrote:
The only problem i see is how the backend would distinguish between a
message for serial logging and a message for something else like syslog,
since both logging request would be done by invoking LOG(level,"message").
the "level" parameter of our current
Hey guys, i kind of managed to get the riotboot tests to pass. Whenever i
program via terminal (gcc-arm) i receive the error "[FAILED] You're not
running riotboot". But when i program via the UniFlash tool, it works.
Note, so far only "tests_riotboot-slot0-combined.bin" works. I assume its
an
Hi Juan,
The standard works in our favor here:
"The use of openlog() is optional" and " The use of closelog() is
optional". We can have no-ops for both functions:
#define openlog(ident, option, facility) (void)((ident), (option),
(facility))
Should not be needed if we do what unix syslog
Thanks for the advice guys, but I'm still struggling to get the cc2538dk to
pass the riotboot tests.
To: Francisco Acosta
I provided the length and start variables to link the slots.
I used the cc2538sf53.ld Linker Script.
I was not sure how to get the offset required, so i used 255 as the
Dear Juan and Hauke
Thank you for the suggestions.
To answer Juan's questions, I am not too sure about whether the vectors will
change or not. It is likely but I might have to get a better understanding to
know whether that is the case or not. The peripherals will definitely change
though,
Robin,
On 28/5/19 18:53, Robin wrote:
Only problem here is that syslog as implemented in gLibc
expects a user to issue a call to openlog first. Maybe I can make the
call to openlog implicit and thus make it compatible to both API‘s.
The standard works in our favor here:
"The use of
Hi Ashim,
the LPC2387 is unfortunately a very bad example, as this CPU is not very
well maintained and does not comply with the best practices of structure
and style that newer CPUs in RIOT use.
The general approach for porting CPUs in RIOT is to rely as much as
possible on shared code.
Assim, Hauke,
To comment a bit on Hauke's suggestion.
On 29/5/19 08:47, Hauke Petersen wrote:
The general approach for porting CPUs in RIOT is to rely as much as
possible on shared code...
That's very important, try to take advantage of what's already in RIOT.
> . All the specific CPU
Hey everyone,
let me say a few words as Kaspar and I have been driving the
implementation of this. In general there is no need to manually go to
sleep, as the deepest sleep mode will always be selected from the idle
thread depending on the deepest mode possible.
Which mode is possible depends on
Dear Juan
The board is the sf2-starter-kit and the CPU is the m2s010, which contains a
Cortex M3.
I have made a publicly accessible repo with all the code available at:
https://github.com/ashimasharaph/SmartFusion2_riot_port
I see now that the makefile in makefiles/arch/cortexm.inc.mk has
11 matches
Mail list logo
