Need a hand on a small project with Maaxboard RT

I believe Avnet themselves can provide such a service if a member here isn't interested....

https://www.avnet.com/wps/portal/us/solutions/design/overview/

Thanks for you reply, Will consider that definitely!

Hi samr2,

I have started working on MaaXBoard-RT recently.
I am just a regular user but I try to do my best to help here in forum (with current and collected experience).

I want to use SPI as well (near soon). Focus is a "network SPI adapter".

I can (and have started to) share experience in forum. If I can really help on all your project topics...?
(not sure, due to lack of HW needed and a slightly different focus for my project(s))

Let's see:
If SPI will work (and I need, not decided yet if CM7 or CM4 should do), it might help you for your ADC and your touch display,
The challenge would be: to have the same external hardware as you are using.

Personally, I would break down your project into "work items".
I would also try to start with SDK examples.

So:

• bring-up dual-core system: CM7 and CM4, "talking to each other" (I would consider the CM7 as the master, CM4 as a slave) - RPC, messages, synchronization
  BTW: why CM4 only? Why not CM7 (only)?
• implement SPI (in general), on CM7, or CM4 (but maybe CM7 triggers to do "SPI transactions" done on CM4) - I need as well and maybe I have it working in few days
• connect your SPI touch display and see some messages, graphics there: do you want to use a "graphics wizard" (tool) or hard coded display images?
  Also: "touch"? is all via SPI? Or is the touch control a different channel, e.g. I2C, a second SPI?
• OK, bare-metal. I prefer personally to use an RTOS, e.g. FreeRTOS on CM7 - all my examples will use FreeRTOS
• any other interfaces needed?
  e.g. Debug UART, UART or even ETH (network) to a host PC... Or all just controlled by user via touch display only?

If you have already the hardware which do you want to connect (the DAC board, the display board) - please provide a bit more info what and where to get
(maybe I can order and try myself).

If you need a very simple "bare-metal" starting project (but without SPI, without display, just toggle the three LEDs):

tjaekel/MaaXBoard-RT_shell_cm7: MaaXBoard-RT Shell with command to toggle LEDs (all three) (github.com)

Good luck and best regards

(I could imagine to "help", if you pay for the HW needed)

BTW: if you work for a company or you run a company... yes, you might be able to "hire" AVNET service.

Imagine: a SW engineer is paid USD 150 per hour (my office salary is even higher) and your project needs (at least) 100 hours - 
are your sure to sign a contract with USD 15,000.00? (it doesn't not look like a "simple" DIY project and paying for as an individual)?

Why not using the capacitive touch LCD board which is supported/working (not proofed myself) on MaaXBoard-RT:

https://www.avnet.com/shop/us/products/avnet-engineering-services/aes-acc-maax-disp2-3074457345648625681/

The AVNET "out-of-the-box" demo seems to use/support this LCD panel.
Order this board, try the AVNET "demo", extend it (for you SPI ADC), modify the GUI pages...
Going with a different (SPI) display might complicate your things.

Hi tjaekel 
Thanks for your response,
yes CM4 and CM7 should talk to each other. I want to keep CM7 for another heavy process, something.
Bare-metal because it really needs a real-time process on CM7, I'm not sure if we could keep CM4 on FreeRTOS separately.
I general CM4 should manage ADC / display/ Bluetooth (a2dp/BLE) and give some data to CM7.

For sure that's a big amount of money and I can't afford that. it's a personal poor-man project :) .Maybe I did underestimate number of hours needed for that.

It would be easier to give advice if your provided some more information.

sampling rate of ADC

type of ADC if known

number of channels etc

buffering required

what will be shown on the display

what kind of signal processing between source and ADC

MK

Hi michael,

I’ve provided a link to adc dev board in the original post. It’s an Ads1256.

display should contain UI for user commands/ info messages etc.

thanks,

TI offer an evaluation system for the ADS1256 - its expensive at about £190.

You haven't explained your project and the UI in enough detail for me to understand if you want a UI just to get know the ADS1256 or if it will have a specific function in your project.

I've used several TI ADCs similar to the ADS1256, they are well documented and use SPI in a reasonably standard way. The simplest way to get going is to bit bang the SPI interface - the Cortex M4 can do this at a reasonable speed. Eventually you may need to use the SPI hardware and DMA to get the throughput you need.

You will need a scope (ideally with SPI decoding) to get this working. It can be done without but it can be very frustrating.

Developing a UI using a small SPI display is a complete other thing, and potentially a lot of work. Most people try to find a ready made solution or an open source project to copy.

Your choice of partitioning between processors is unusual. It's more common to group the hard real time tasks like ADC control on one and less time critical stuff like the UI on the other.

What I've said here is all a bit vague - if you want good advice you need to describe the project in detail.

MK

I agree with MK:

To connect and use the ADC via SPI should not be a big deal (I will have a generic SPI example working soon).
It is a regular SPI, maybe with an INT signal from ADC when ready).

The GUI is really a separate topic (and might need the most effort, to define and design the UI, GUI, pages, ...).
It depends if you want to use a GUI Wizard tool or go "hard-coded" (I did on STM boards with background BMP files and touch coordinates).

Also: I agree with MK: "strange" priorities how to use the cores:
I consider CM7 as the Master, CM4 as a Slave (slower speed, released by CM7, no caches, maybe reduced access to system HW).

I could imagine to do: SPI on CM4, maybe GUI on CM4, but the CM7 should be the Master and the core with best performance.
(real-time stuff seems to run on CM7)

BTW:
Why not using RTOS (at least on CM7 side)?
The overhead of RTOS is very small. Only an RTOS provides "real-time" (guaranteed minimal response time).
With bare metal - it is tough to achieve a minimum response time under all conditions:
Often bare metal systems would poll for a variable set by an INT. If you run on a long sequence, e.g. updating your LCD GUI, it will not
poll and neither realize if a "real-time" interrupt was there. The action is scheduled after all LCD was done.

An RTOS would guarantee: if an INT was seen, the related thread/task would be scheduled (right as next). You can "play" with priorities, also design
as "cooperative" or "preemptive". Just an RTOS makes sure that an INT would start the processing (with the minimum delay, "real-time").
Any bare-metal design for real-time is pretty tough (and for my experience: almost impossible).

BTW:
It might be also easier to start with a single core project: all done by CM7.
Later, you can move "not-real-time" stuff, or stuff which runs anyway slower (e.g. SPI) to CM4.

Bear in mind: the update of the LCD GUI is potentially not "real-time" (no need) but blocking all other stuff just by updating the GUI (which can be slow, time consuming) might "violate" real-time requirements you have to have (e.g. act on ADC interrupt to drain the data from ADC without a huge delay, stay in sync with a "sample rate" (clock)...).