MOD54415 SPI and I2C question

[Ridgeglider]

Semaphores, and even more so, their close cousin FLAGS are really worth learning to use. See the C:\nburn\examples\StandardStack\RTOS folder for examples.
The one thing I'd comment on Chris' recent overview is that in my experience, when using Semaphores, they are typically inited only once. When you post to a semaphore, behind the scenes, you're actually incrementing a count, and when who pend on one, you decrement the count if it's not already 0. If you re-init, odd things will happen not the least of which is that the aforementioned count gets confused and you'll miss events. Flags on the other hand must be manually cleared, although they too MUST be inited before either posting to them or pending on them.

[jediengineer]

Ok, that kind of makes sense. I think for this application though, semaphores might be a bit too much extra.. Plus, for different subroutines, I'm locking the OS out - can't have multitasking during the routines. Very time sensitive. Thanks though!!

[dciliske]

A word of warning about ALL OS synchronization objects: they should be initialized only once, unless your really know what your doing with the bowels of the OS. If you don't know how the OS and the scheduler works off the top of your head, then you shouldn't. The reason is that the object itself is what tracks which tasks are pending on it, and when you initialize the object, everything gets reset, including the pend list. This means that anything that was pending will forevermore be waiting.

[jediengineer]

Thanks Dan, that kind of settles it for me then... Semaphores are out for now. I'll stick to the straight up code.

[rnixon]

Just my opinion, but semaphores are very easy. Nothing to be afraid of. You just need to do a couple hours of reading and experiment with the examples. I do agree that if someone tried to learn from only an example and just hack at it, their program would be prone to errors. Conceptually its like a flag, but better. If you go w/o the os, you will probably use a flag anyway, so you will be 80% of the way there.

[jediengineer]

rnixon, et al, since semaphores are the topic here now, and since they're used in the example files, here's a little of what I'm doing. Can't tell you much due to security issues... sorry. But tell me if semaphores apply:

I have a DAC that is I2C. I'm writing to it only, not reading back from it.

I have a 16 input ADC that is SPI controlled, I will be using a subroutine to write to and read from the ADC.

I have an 8 bit SPI-GPIO breakout that controls 2 muxes simultaneously. The mux outputs are read from an onboard GPIO pin. The GPIO takes care of addressing the muxes only.

That's all I have to do. I'm not sure a semaphore is warranted because my subroutines are specific, and when they're run, the OS will be locked out anyways.

[Chris Ruff]

If you control your analog multiplexors using GPIO writes, what are you reading from the GPIO?

If you are locking out the OS are you turning off the interrupts? Like, with CRITICAL calls? Or are you locking out the OS with the OSLock call?

It sounds like you are:

1. set DAC MUX
2. set DAC
3. set ADC MUX
4. read ADC
5. goto 1

So how do you know when the ADC is done? Do you ask it with the SPI?

Do you have the ADC interrupt line connected up?

Chris

[tod]

I would agree with Chris also but only 75%, I don't think you should declare your semaphores globally or initialize them outside the constructor. Then again I don't think you should declare anything globally that you don't have to. You can easily make a semaphore a private member of a class. Then you can initialize that semaphore in the class constructor, thus honoring the resource acquisition is initialization idiom (RAII).

Your class then needs only a simple getter that returns a reference to the semaphore

Code: Select all

OS_SEM& GetSemaphore()
{
	return myPrivateSemaphore;
}

In the external code when you need to use the semaphore you just grab the reference (and probably just store it in a local variable), use it and you're done. Like this

Code: Select all

OS_SEM& some_sem = InstanceOfClassThatOwnsTheSemaphore.GetSemaphore();
OSSemPost(&some_sem);

I typically don't keep the references to a semaphore I don't own around, I just call the GetSemaphore method every time I need to use it.

[jediengineer]

Chris and Todd:

So I just finished laying out and routing my board, waiting for it to be printed now. Sorry I can't share all my code with you, but I can say this much:

The DAC is I2C. the NB receives a UDP packet that addresses the DAC, ADC, and muxes individually. so if a "read mux" signal comes through, and because I don't have a complete IO port pin sequence (ie B0-B7) to address because I have other peripherals that need the I/O, I'm using spi to control the mux through an 8 bit spi-gpio breakout chip. So I pull the cs line down for the mux and spi channel, send the mux address to the gpio breakout, and read the NB gpio that the mux output is connected to. The mux address is incremented and the process repeats. I have over 50 inputs to read, thus the muxes.

Same for the ADC. I send a command for it to convert, then read in all the data.

As for the dac, I'll be addressing channels individually.

Chris, you asked about OSLock() - I will be using it whenever a command comes through to process the command as fast as possible. I've experimented without it for the last few months, and found that the system runs nearly perfectly when I locked out the OS. Or at least I should say, in my situation, it performed the way I wanted it to.

with respect to the I2C Dac, I'm still trying to figure out how to work the I2C on the 54415 platform. Maybe you guys could shed a little light? I've set I2C 2 pins (SDA and SCK)to their right designation, I called the I2Cinit routine, but sending data is eluding me. I'm talking to a quad DAC (AD5696) which has a 24 bit register. The 8 MSB are control and dac address (DAC 1-4), the last 16 bits are the dac data (voltage level). In the runtime library, it shows the I2CSendBuf command, but I'm a little confused by the address portion. I'm assuming that is the address of the particular I2C channel I'm using? If so, I couldn't find it in the book, unless I breezed over it and didn't see it.

I tried taking apart the header to see how it was processed, but I'm still a little green with C++. I'm trying to do it at a simpler level for now.

So let me ask - is the default frequency for the I2C set to 100kHz? The header has the prescaler of 0x37, which if I calculate right comes out to 244Khz... And I assume that if I wanted to run the DAC at maximum speed of 400kHz, I would need the prescaler of 0x34? Also, why are there so many repeat prescalers?

Anyhow, before my ADD takes over and I make a book of this, I'll rest... If anyone can shoot me a snippet explaining how this stuff functions, I'd appreciate it. It's quite obscure to me at the moment. Thanks!!

[Ridgeglider]

This is kind of an old post, but it had some i2c example code:
http://forum.embeddedethernet.com/viewt ... ?f=5&t=982


There is also the NB app note on i2c:
http://www.netburner.com/component/docm ... on?Itemid=