Hello,
Raspberry Pi creating their own chips? Sounds like a stupid idea...
Am 21.01.21 um 16:44 schrieb Joel Sherrill:
Hi
Is a BSP for this feasible? If it is feasible, is is a GSoC size project?
It is an M0+ with 264k SRAM. Although I'm not sure what six independent
banks does to the amount of RAM for programs?
The SRAM isn't really big. But the STM32F4 is in a similar range. So
that could work.
https://www.raspberrypi.org/products/raspberry-pi-pico/
<https://www.raspberrypi.org/products/raspberry-pi-pico/>
I can see the M0+ support in RTEMS being a broad issue and the memory
layout being another but the datasheet seems to show the memory as one
block:
https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.pdf
<https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.pdf>
Agreed: It seems that the memory can be used in a continuous address
space so the organization shouldn't matter as long as no performance
optimization is necessary.
The M0+ could be a real problem. Do we currently have any BSPs for an M0
or M0+ core? I think adding a new core would be _very_ difficult for a
GSoC student. Especially I think it's less time this year, isn't it?
By the way: It's a dual core. So if the support is added, it would be
most likely our smallest SMP system ;-)
Feature list:
Dual ARM Cortex-M0+ @ 133MHz
264kB on-chip SRAM in six independent banks
Support for up to 16MB of off-chip Flash memory via dedicated QSPI bus
DMA controller
Fully-connected AHB crossbar
Interpolator and integer divider peripherals
On-chip programmable LDO to generate core voltage
2 on-chip PLLs to generate USB and core clocks
30 GPIO pins, 4 of which can be used as analog inputs
Peripherals
2 UARTs
2 SPI controllers
2 I2C controllers
16 PWM channels
USB 1.1 controller and PHY, with host and device support
8 PIO state machines
The chip seems to be thrown together using various IPs (which is not
necessarily a bad idea if they did it right). UART is an ARM PL011 which
should be simple - we have already a driver for that. The other
peripherals seem to be sometimes ARM, sometimes Synopsis, sometimes
something else. The documentation looks OK on a first glance. So it
should be doable.
Not our problem but I don't see obvious details on hooking up a JTAG but
if someone does a BSP, that will be an issue.
The chip has a SWCLK and SWDIO. So its not a full JTAG but at least a
debug interface. The Board has three pins marked "DEBUG" on the small
side opposite to the USB connector. So in theory a debugger could be
connected. It even seems that there is an openOCD port done by the
Raspberry Pi developers:
https://github.com/raspberrypi/openocd/tree/rp2040
Best regards
Christian
--joel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
