Should I use a slave processor for this?

I am a computer engineering major and am leading a team to build an IOT alarm clock as part of a senior design project. Currently we are using a Beaglebone Black as our primary dev board. The Beaglebone will be used to get the time using NTP and will then store and maintain an accurate time using a RTC. I am currently debating how we should connect the Beaglebone to the 7-segment clock display which is going to be used to display the current time.

The two options I have come up with are:

  1. Hook the display directly to the Beaglebone’s GPIO using a shift register and wright a kernel module to drive the display. (easy and maintainable)

  2. Use a slave MSP430 which is updated with the current time at regular intervals (every hour or so) over SPI and otherwise maintains the time itself. The msp420 would directly drive the 7-segment display using it’s GPIO pins (rather than a shift register). (more complicated, harder to maintain, but possibly allowing for a lower power mode on the main processor)

Do you think it is worth it to have a slave processor which drives the display? On paper this seems like a better option as it would not occupy the processor nearly as much (possibly allowing the main processor to be put into sleep mode when the user is not interacting with it) however this makes re-programming difficult, may allow the processor to go out of sync (though highly unlikely) and will likely (slightly) increase cost.

We want to keep the cost as low as possible as we are planning on starting a kick-starter and would like to have the unit cost low. We will be migrating to our own pcb implementation with appropriate hardware as soon as we have the design finalized.

Have you looked into using the Programmable Real-Time Units (PRUs) that are integrated into BBB’s processor? They are real time microcontrollers that have direct access to GPIO and can share memory with the primary ARM cores. They are perfect for offloading the 7-segment drive functionality and would make the project simpler in the long run.

http://hackaday.com/2014/06/22/an-intro … ebone-pru/

-Bill

Option 1 is the simpler and cheaper. It would be even easier if you use a MAX7219 to drive the display.

phalanx:
Have you looked into using the Programmable Real-Time Units (PRUs) that are integrated into BBB’s processor? They are real time microcontrollers that have direct access to GPIO and can share memory with the primary ARM cores. They are perfect for offloading the 7-segment drive functionality and would make the project simpler in the long run.

http://hackaday.com/2014/06/22/an-intro … ebone-pru/

-Bill

Thanks! I did not know about the PRUs. I will probably use this solution possibly combined with a shift register.

lyndon:
Option 1 is the simpler and cheaper. It would be even easier if you use a MAX7219 to drive the display.

The MAX7219 makes things easy but it is VERY expensive (around $6 per chip when buying in quantities of 500). Thanks for the suggestion though.

trekkie33:
Thanks! I did not know about the PRUs.

Lot's of people have no idea they exist as part of the processor package. The main Cortex A8 is an application processor that isn't well suited to bit banging information in a deterministic manner. A microcontroller alone will not have the means to handle HD video, gigabit Ethernet, DRAM control, etc. like the A8 can. Combine a couple of microcontrollers along with an A8 in the same package and you have yourself a powerful little platform that can handle deterministic tasks while still running an operating system like Android or Linux.

-Bill