• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 21 subscribers
  • Views 2041 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Tiva C, Matlab,

Noam Cohen

Hi all,

I have a Tiva-C board that I configure with Keil. I want to perform a simple task - when my MATLAB runs a specific command, I want to send an "On" trigger (analogoutput 3.3V) to a NI PCI Board to start a camera device. Also, I am relativley new in programming in Keil. I have the following questions:

I have a small program that turns a connected LED on and off.

option 1 - Is it possible to write 2 function ledON/ledOFF that can be executed from MATLAB (without a main)? Something like -

  // Make PA2 high
void LED_On(void){
  GPIO_PORTA_DATA_R |= 0x04;
}
// Make PA2 low
void LED_Off(void){
  GPIO_PORTA_DATA_R &= ~0x04;
}

option 2 - should I load a program that runs in a loop and performs the task according to a "package" sent from MATLAB? Something like -

  int main(void){
  LED_Init();               // initialize PA2 and make it output
  while(1){
  In = GPIO_PORTF_DATA_R&0x10;   // read PF4 (read 'input' from matlab)
ChangeLedState(In);'
  }

2) What is the most recommended way to interface a the Keil C-format files with MATLAB? What signal should it read, and how do I specify and connect to a specific GPIO port?

Any further wise suggestion is welcomed...

Noam

Parents
  • 0 in reply to Noam Cohen

    You can't expect to get any protocol that gives you 1ms response times between two PC running a desktop OS, because the OS doesn't promise real-time performance.

    So the protocol may sometimes manage a delay of less than 1ms - but may at other times give much, much, much longer delays.

    This is why embedded devices so often uses an RTOS, where you can design around guaranteed worst-case response times of a high-priority task (assuming the developers knows their stuff). And why lots of PC interfaces contains hardware acceleration allowing the hardware to perform tasks without waiting for the OS involvement. And why lots of communications interfaces has significant buffers to reduce the amount of times the OS needs to be there to retrieve received data and fill the output buffers with new data to send. Buf big buffers obviously doesn't solve the OS-to-OS latency issue - they only improve the link utilization.

    So in the end - you'll have to think again about your need of below 1ms latencies between two PC-class machines running standard OS.

Reply
  • 0 in reply to Noam Cohen

    You can't expect to get any protocol that gives you 1ms response times between two PC running a desktop OS, because the OS doesn't promise real-time performance.

    So the protocol may sometimes manage a delay of less than 1ms - but may at other times give much, much, much longer delays.

    This is why embedded devices so often uses an RTOS, where you can design around guaranteed worst-case response times of a high-priority task (assuming the developers knows their stuff). And why lots of PC interfaces contains hardware acceleration allowing the hardware to perform tasks without waiting for the OS involvement. And why lots of communications interfaces has significant buffers to reduce the amount of times the OS needs to be there to retrieve received data and fill the output buffers with new data to send. Buf big buffers obviously doesn't solve the OS-to-OS latency issue - they only improve the link utilization.

    So in the end - you'll have to think again about your need of below 1ms latencies between two PC-class machines running standard OS.

Children
No data