3 ms·

> In addition, its processor includes two 200-MHz microcontrollers that allow you to implement low-latency, real-time functions while still having the capabilit

by magnat 9y ago

> In addition, its processor includes two 200-MHz microcontrollers that allow you to implement low-latency, real-time functions while still having the capabilities of a Linux system. This is brilliant. Inter-processor communication [1] feels quite like programming GPGPU. I wish there was a way to allow one of RPi's VideoCore unit to access external IO. [1] http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_...

deleted 9y ago
[deleted]
leggomylibro 9y ago
It really is a great addition; there have been a few SoCs that packed an ARM Cortex-M core or two alongside the big Application processor, and some FPGAs come with small MCU sister cores. But gee, if I could produce BGA boards, I would be making one tomorrow with: - ARM Cortex-A SoC, preferably one with networking built-in to minimize layout hell like with the newer Raspberry Pis, but an ESP32 module could serve that purpose. - A nice ARM Cortex-M7 core @~200-400MHz, for realtime functionality and honestly, teaching. MCUs have huge potential for teaching about electronics/code with minimal overhead or required prior knowledge, imo. If your cheap laptop could also use successful educational tools like the Arduino IDE and Adafruit's libraries for things like sensors/I2C-SPI displays/etc out-of-the-box without requiring any boards or dongles...well, that would be absolutely terrific. - FPGA core with as many LUTs as I could get at a similar ~$20 price point of the Cortex-M, for ultra-realtime tasks like signal processing or video encoding. Then it would just be a fairly large software problem to make a nice GUI interface to program and debug the peripheral cores from a generic Linux/BSD environment. Unfortunately I can't even do QFN reliably, so a board like that would really limit my options with parts, and it would be huge with all the QFP-100+ parts. Also, the idea of juggling three large processing platforms' enormous documentation makes me shudder. But it would be a really cool idea for an open platform dedicated to handheld multimedia :/
- leggomylibro 9y ago
  (Late edit) Okay, about the small onboard MCUs, I looked a bit more into it, and these 'co-processors' actually look very limited and built into the Cortex-A8 silicon. They only support like, a single UART peripheral and very little else, and appear to be a custom RISC architecture. Still, it's a promising step. The ESP8266 used a bullshit processor core and still became really popular.
  - tyingq 9y ago
    They don't have a ton of software support, but you can do some neat things with them: Mac video driver: https://trmm.net/Mac-SE_video https://trmm.net/Mac-SE_video Led matrix: https://trmm.net/Octoscroller https://trmm.net/Octoscroller More, including audio: http://bela.io http://bela.io

by magnat 9y ago

deleted 9y ago

[deleted]

leggomylibro 9y ago

It really is a great addition; there have been a few SoCs that packed an ARM Cortex-M core or two alongside the big Application processor, and some FPGAs come with small MCU sister cores. But gee, if I could produce BGA boards, I would be making one tomorrow with: - ARM Cortex-A SoC, preferably one with networking built-in to minimize layout hell like with the newer Raspberry Pis, but an ESP32 module could serve that purpose. - A nice ARM Cortex-M7 core @~200-400MHz, for realtime functionality and honestly, teaching. MCUs have huge potential for teaching about electronics/code with minimal overhead or required prior knowledge, imo. If your cheap laptop could also use successful educational tools like the Arduino IDE and Adafruit's libraries for things like sensors/I2C-SPI displays/etc out-of-the-box without requiring any boards or dongles...well, that would be absolutely terrific. - FPGA core with as many LUTs as I could get at a similar ~$20 price point of the Cortex-M, for ultra-realtime tasks like signal processing or video encoding. Then it would just be a fairly large software problem to make a nice GUI interface to program and debug the peripheral cores from a generic Linux/BSD environment. Unfortunately I can't even do QFN reliably, so a board like that would really limit my options with parts, and it would be huge with all the QFP-100+ parts. Also, the idea of juggling three large processing platforms' enormous documentation makes me shudder. But it would be a really cool idea for an open platform dedicated to handheld multimedia :/

leggomylibro 9y ago
(Late edit) Okay, about the small onboard MCUs, I looked a bit more into it, and these 'co-processors' actually look very limited and built into the Cortex-A8 silicon. They only support like, a single UART peripheral and very little else, and appear to be a custom RISC architecture. Still, it's a promising step. The ESP8266 used a bullshit processor core and still became really popular.
- tyingq 9y ago
  They don't have a ton of software support, but you can do some neat things with them: Mac video driver: https://trmm.net/Mac-SE_video https://trmm.net/Mac-SE_video Led matrix: https://trmm.net/Octoscroller https://trmm.net/Octoscroller More, including audio: http://bela.io http://bela.io