There’s nothing particularly special about that MPU except its price. My humble opinion is that a cost effective SiP for (power-)constrained IoT applications could contain:
CPU @ 400 Mhz or more (with good Linux support)
RAM (256 MB seems acceptable)
microSD interface
Ethernet interface
2+ x SPI
1+ x I2C
1+ x I2S or similar
1 x USB device
1 x USB host
Some GPIOs
(Optional) Flash memory (4GB+)
(Optional) LCD interface & touch controller
That’s on top of my mind for now.
I’ve been looking for other possible MPU options on that leagle and NXP i.MX28 (ARM926) series looks like a good candidate. Also, NXP has low-cost Cortex-A options like the i.MX 6ULZ or 6ULL series. Although, I don’t know about NXP’s Linux support and community.
I assume you’re aware that Microchip has their own SiP offering based on their ATSAMA5D27 Cortex-A5 MPU (ATSAMA5D27C-D1G-CU) at about ~$15 @ 100pcs, but its 0.8mm ball spacing and pin layout is still hard for cost-effective PCB design.
A price around $20 @ 100pcs seems reasonable to me, but of course that’s just my wish
> Would a AM57x work for your application? If so which version 1, 2, or 4?
not sure, i’m not familar with it. we currently have a plain bare metal application, so no linux or something like that involved. is there a starterware-like board support package available for this SoC?
> – CPU @ 400 Mhz or more (with good Linux support)
> – RAM (256 MB seems acceptable)
> – microSD interface
> – Ethernet interface
> – 2+ x SPI
> – 1+ x I2C
> – 1+ x I2S or similar
> – 1 x USB device
> – 1 x USB host
> – Some GPIOs
this is something where i also could imagine some very nice applications - when it would provide a lot GPIOs instead only some
Thanks for the detailed info. Like I mentioned this is something we are looking into. We will let you know if we have something that might fit with what you are looking for.
If you do an AM57X SIP I would like a USB-C interface. Something like the TI:TPS65981 chip with USB 3.0 and DisplayPort. This would be nice because the designer would only need to add one port to the board and they can both power the board and have an entire desktop environment using a decent USB-C hub (USB Host ports, USB Ethernet, HDMI Output). USB-C supports dual role mode so you can still boot the board over USB. If you allow the user to modify the EEPROM of the USB chip you can request up to 20V.
Are TI based SOC’s a constraint? I would love to see something from the NXP i.MX series. (i.e. the new i.MX8 with Cortex A53’s and A72’s).
The new i.MX8 devices use LPDDR4 which is challenging to route. A SIP would be a very nice product! A Multicore SOC built on a smaller geometry process for power efficiency would be a helpful. The current TI parts seem to run quite hot at idle.
Having a part with an easily accessibly datasheet for the SoC (which pretty much limits you to TI and NXP these days) is a big deal for me. I avoid anything “Rasberri Pi” like as it is impossible to dig into any details unless you have lawyers to deal with Broadcomm directly.
We are not restricted to TI and I appreciate your input. I have not looked at these NXP devices yet. Besides the cores is there anything that stands out to you as a differentiator? Any special peripherals that are must haves?
These modules were never generally available and are EOL. I have some internal knowledge of the history and you will never seem them through general distribution in low quantities like the Octavo product. They are only being offered to teir 1 customers. Also, the BGA package is very difficult with the POP RAM. It is a .65mm BGA and much more difficult than the current octavo offerings. Once you go down that road you might as well use the raw chips.
The i.MX integrates standard cortex MCU microcontroller cores along side the application processors. It is a bit easier to do development vs the PRU’s as there is a lot more cortex M support in the wild.
The new Quad Max devices support hardware virtualization. I was at a training event where a couple VM’s were created with the internal cores/peripherals partitioned in hardware. It is an advanced use case but it is possible to boot android for a GUI and Linux for a processing backend on a single chip. Also, some of the device support instant on video for applications that require cameras to come on with graphics before linux is booted.
This is certainly on the high end but the i.MX is a good family for automotive and robotics.
I would be happy with a TI part inside built on a smaller process node for the power efficiency and to get a bit more horsepower. The other key feature to keep is the easy BGA layout!
Easy BGA layout is definitely one of the best features of current Octavo System’s offering. Where I live, it is very difficult to find high-end PCB houses and using Octavo System products has enabled us to make some products that we didn’t have any chance to do a couple of years ago.
Relaxed BGA ball spacing and optimized ball layout allow people like me (with no experience in high speed layouts) to tackle projects I didn’t think of.
So keep the easy BGA routing… it’s definitely a must!
Thank you both for the feedback. We are glad the BGA placement has been a benefit to you. That was definitely one of our main goals when creating these devices.
Please keep sharing your thoughts. We do take your feedback into consideration when developing our road map.
Yes the AM57x is something we are strongly looking at. We are trying to narrow down what the correct configuration would be for a SiP. Should we build it around the AM570, 1, 4, or 8. How much DDR memory is required, what peripherals are required.
Can you give us any insights into your application and how you would be using the AM57? What are your system requirements?
If you don’t feel comfortable discussing on the forum please contact us directly.
Thanks for the good-work so far. The OSD32MP15x has been a great addition to your product portfolio. Most embedded developers need a SIP that can run Linux but can also do some “real-time” stuff. However, we do not really need the dual-core STM, a low-cost single core version would suffice most not-so-high-end applications. Thus a single core variation of the OSD32MP15x with STM32MP151C, eMMC (1 or 2GB would suffice most) and oscillator could be your best-seller with the right price tag.
I’d be very interested to see a SiP version of the TI AM64x. You already provide a SiP version of the AM62x, which is a great fit for some applications, and indeed we are actively considering it for integration into one of our upcoming products.
One of the killer features of the AM62x is the PRU cores, which provide extremely low-latency access to GPIOs. This is a major differentiator between, say, the AM62x and the NXP i.MX 8 or i.MX 9 families. The only real advantage of the NXP chips is that you can find them in smaller packages. For example, there are variants of the i.MX8 that are only 9x9 mm, whereas the AM62x is 13x13 mm. But with the LPDDR4 packaged into the SiP, the OSD62x makes all of that irrelevant, because it is already smaller than the smallest i.MX 8 with discrete LPDDR4. And I think it’s very unlikely you’d end up with something smaller than the OSD62x even if you started with a smaller CPU die like that of the i.MX 8.
However, we have another product that we are developing in parallel that needs more GPIOs connected to the PRU core(s) than are available in the AM62x. For this, we have no choice but to use the AM64x. Unfortunately, Octavo has no SiP for this part… yet. I’d love to see it considered. Given the significant similarity between the AM62x and AM64x, I would expect you can re-use a lot of the learnings from building the OSD62x, and, hopefully, much of the software SDK, too.
Cody,
Thank you for your request. I am happy to hear you are considering the OSD62x-PM in your projects. I understand the desire for more PRUs, unfortunately an AM64x version is not currently on our roadmap. However, I will take note of your request and will keep you posted if anything changes.
I’d love to see it considered. Given the significant similarity between the AM62x and AM64x, I would expect you can re-use a lot of the learnings from building the OSD62x, and, hopefully, much of the software SDK, too.