hello, world\n
we’re currently in the design phase for a rocketchip RISC-V project with two
harts.
Think a common HW platform where each hart drives a separate telescope unit.
The C code for each telescope is basically identical with the exception of
memory mapped registers and interrupts.
Our i
Hi Jens,
Is there a real need to have the telescope driver twice in memory?
Would it be enough to implement the driver as “object oriented” in C?
Then you would just need to create a context struct during initialization based
on the hartid with the correct interrupt assignment and base address of
Hi Jan,
well, in the beginning there was a system with just one telescope. Now a second
shall be added.
Easy as 1-2-3: duplicate the software and run it on two cores. No SW changes
needed.
Developers like me are expensive J That’s how corporate thinks.
Driving a telescope involves not just a si
Hello Jens,
in general, such a setups works. We used it some time ago on the NXP
P1020 before the SMP support was available. You just have to provide two
MEMORY definitions for the linker. You also have to make sure that you
don't accidentally share hardware modules between the two RTEMS
inst
The leon3 BSP also supported something similar at one point.
If the two applications do not need to communicate, then it should
not be an issue. If the do need to communicate, then this might be
a case where the original distributed multiprocessing in RTEMS makes
sense. It isn't used much but is s
