Actions
Forum Thread Details
  • State Not Answered
  • Replies 15 replies
  • Subscribers 335 subscribers
  • Views 2120 views
  • Users 0 members are here
Related

Need a hand on a small project with Maaxboard RT

samr2

Good Day,

I would like an expert to give me a hand developing a small Bare-Metal R&D project with following definitions (We will agree and I'll pay for that):

I need to have a SPI 24 bits ADC and a Small SPI touch display (ILI9341 Controller Chip for example or equivalent) connected to and controlled by a MaaxboardRT (only through CM4).

CM4 should be able to receive analog input from external ADC and take care of display simultaneously.

The project has to be developed in MCUXpresso and defined as a Multicore Project.

The result of this project will be a MCUXpresso multicore project code and a wiring diagram up and running.

Please let me know if you are interested and how much it will cost you doing that or any other questions you may have.

Thanks in advance,


Cheers,



  

Parents Reply Children
  • 0 in reply to samr2

    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

  • 0 in reply to michaelkellett

    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)...).

  • 0 in reply to michaelkellett

    Hi Michael,
    Thanks for the response,
    The CM7 has to synthesize audio based on the inputs from CM4 and put heavy filters/ effects on it which is the most important thing on this project.
    Probably the only thing I need advise right now is how to use high resolution SPI  ADC (ADS1256) (or any other with same resolution/rate if easier to use) on CM4 only.
    We can cover others later on. 
    I hope it's more clear now. 
    Thanks,

  • 0 in reply to samr2

    Hi samr2,

    it sounds like, you want to use ADC1256 in order to sample audio. Are you sure?
    ADC has (just) 30 KSps (not 44.1 KHz or 48 KHz).
    And when I check the SPI timing: with 10 MHz (max.) XTAL frequency and 8 channels (each coming as 24bit = 3 bytes),
    you will get only 26 KHz audio frequency (per channel).

    For voice applications it might be OK, but not for (HiFi) sound.