Dual Master SPI inquiry

[CarbonWerkes]

Hello

I have an application which will involve 2 microcontrollers and an SPI-based accelerometer. The Primary controller is heavily tasked, and therefore requires the support of a Secondary controller to handle integrations from the accelerometer data.

All devices have a single SPI module.

Im concerned about a daisy-chain connection bus with this setup. Im not sure that the accelerometer(s) have an SDO port (or support daisychaining), and there may be some clock limitations (least common denominator).

What I wonder is- can I use a dual master config, where the Primary connects to the Secondary, and where the Secondary connects to the accelerometer. The implication here is that the bus will be cross-wired between the Primary and the accelerometer (i.e. SDO<->SDO, SDI<->SDI). Yes, there will also need to be some additional inhibit signal between the Secondary and the Primary, so that if the Secondary were communicating with the accelerometer, the Primary would not attempt to initiate a connection with the Secondary.

My understanding is that, unless the CS pin is held low, the SDI/SDO pins on a device should remain in high impedance mode, and as such should not affect signaling on the bus. That is, unless the accelerometer's CS is held low by the Secondary uC, it would ignore any bus signaling from the Primary uC, and since it would be in high-impedance mode, it would not affect the signals, nor be affected by them.

Apparently this is not a common topology, but Microchip thinks it would work (but is untried there). Does anyone have any insight on this?

Best,
Rob

 

[itsmoked]

Oh. How painful.. You want to grow old quickly do yee?

Is there no other way to skin this cat? I think you are cruising to headache island you know the one, think Jurassic Park.

Other suggestions:

1) Pass the info to the Primary via an analog in. PWM the integrated value thru a simple RC and let the Primary read it directly. One pin!

2) Let the secondary read (SPI) the sensor gyro and then convey the integrated info to the Primary via the USARTs.

3) Just bit bang the Gyro with the secondary. That's its main task anyway,(apparently), and then leave the SPI to interconnect the Pri and the Sec. 'Bit banging' SPI is so easy I have been known to do that instead of wading thru the SPI module's gotchas.

Otherwise I can picture debugging confusion worthy of an ulcer. I see bus contentions hanging your ICEs. The SPI registers getting misaligned causing mysterious crashes.

Crashes and Aeronautics are mutually exclusive normally right?

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[CarbonWerkes]

Hi Keith-

I was born old

The problem I have here is a little more complex than I outlined. The requirement is for an IMU, which is 3 gyros and 3 accels. The accuracy of the 10-bit ADCs on the PICs (18F anyway) is much lower than the native 14-16-bit SPI data from the sensors. So going from digital to analog and back is a problem re: drift, and also in burning 6 ADCs.

On the Usart, unfortunately, the secondary is already handling an RS232 IO process (GPS unit). The Primary is a 4550 which unfortunately has an SPI pin multiplexed with the USART, so that is not an option either; USB is required so the 2550/4550 seem the only option in PIC-land Yea, I should move to the bigger FJ-class PIC, but they are 3V parts and dealing with lots of level shifting to my 5V external devices is a pain...

I may be able to implement software SPI on the secondary. The problem is having to disable ISRs during the comms, where I may need them for USART input.

One possibility seems to be a MUX. Presumably I could use a quad bilateral and just switch the secondary between 2 busses. It would still require a signal line between Primary and Secondary to inhibit the Primary from initiating a SPI connection while the Secondary is busy. Does this seem a reasonable alternative?

I found Microchip's response interesting- in that they almost wanted to say 'that is a really good idea, but it might be a really bad idea.'

Crashes and aero are part of my normal week; most of my work in on race cars

Best,
Rob

 

[MacGyverS2000]

A multiplexer is a quite reasonable alternative, though if you're getting to the point that multiple processors is becoming more of a hassle than their worth, maybe it's time to reconsider your main processor. A faster main processor, such as an ARM running at 80MHz, is going to crank out a lot more MIPS than that PIC is. When it comes to IMUs, you're going to need a lot of oomph to deal with the signal processing involved in handling sensor drift.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[CarbonWerkes]

Hi Dan

Yes, one reasonable alternative is a FJ- variant PIC with dual SPI modules. They run at 40Mhz, and are fast enough for the accuracy I can expect from 14-bit gyros. Certainly not what I would want for a laser-ring gyro

The two basic challenges here (strategically) are- I would prefer to stay with one processor family (i.e. the 18F pic), so that I dont have to use different dev environments/debug hardware, or track all the differences in register management, etc. The other is that most higher-performance uCs are 3V (or lower) parts, and I have a need for a lot of 0-5V ADC, as well as 5V PWM IO. Not being an EE, Im more afraid of dealing with precise bi-directional analog level shifting than I am of some digital bus switching via MUX

Regards,
Rob

 

[itsmoked]

I went to an FJ on the last project... I do not want to go back to 18Fs after trying on the FJ. It's a very easy shift. The environment is the same. Of course you need another compiler. I use HTSoft's and the shift was painless. Same ICE. But multiple USARTS and multiple SPIs and 100 pins really makes things less kludgy.

Oh the 24s are interrupt vector tabled. Really nice.
The 16bit int is a real joy! No more disabling interrupts when doing int work.

The 16x16 single cycle multiply really moves things along. The last project I did entirely with double floats. Everything in engineering units. Boy was that nice!

But yes... 3.3V
The digital can usually be shifted painlessly. If need be you add a few level shifters.

The analog. Well, I'd try shifting everything, toss in a few opamps on the serious problems.

But if you stick with the 18s why are you turning off the interrupts for comm? I don't follow.

Try an SW SPI you'll see they aren't very hard. You could run several of them.



Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[MacGyverS2000]

Let me be clear that PICs rock... I've use the gamut of choices from the simple 6-pins to 80-pin+ units. That said, I've never found them to be real powerhouses on a cycle-per-cycle basis. The really high-end units that offer single-cycle multiply, vectored interrupts, etc. are a real boon for the PIC family, but then again, you really pay out the wazoo for those, and I just don't feel the payback per MIPs is there. If you're stuck with PICs then you do what you gotta do, but just be aware that there could be significantly less painful solutions in the long haul by going with another processor.


Dan - Owner

http://www.Hi-TecDesigns.com

 

[CarbonWerkes]

Hi Keith

What I may do is leave the USB interface (4550) as is, and then use the FJs for support processing. I can then use the ADCs on the 4550 for the basic IO I need, and leave all the 3v signaling for SPI on the FJ, no level shifting needed. I dont believe any FJs have native USB, and I would rather just use my existing libraries for that vs. dealing with a USB<->SPI device.

Im not sure if an FJ can act as both an SPI slave (on port 1) and master (on port 2) at the same time. I will check into that.

I thought that with SPI, timings were pretty critical? If so, then I would need to disable interrupt for the USART to prevent screwing up the soft SPI clock. Maybe Im wrong there?

Dan- 100% with you. I like the PIC because it is easy and there are so many variants (for things like motor control, with motion feedback in hardware, etc). I may be better off going with a much more powerful/generic MCU. Im just a bit invested with the current dev hardware/compiler/IDE, so switching has some financial pain in addition to the learning curve

Best,
Rob

 

[itsmoked]

Dan, do you realize that Microchip has 32bit chips now? Look out ARMs.

BTW Dan, not everyone is doing fast, panicky, video processing.

Rob; SPI is not timing critical! That's why I like it so much. You can suspend it in the middle of anywhere since it's synchronous. Now that's as the master since you are running the CLK. If you are playing the slave then yeah, you have to take what's dealt you. You can front load your ISR to check the SW SPI slave clock first for reception and assembly of the incoming bytes. Of course you shouldn't be abusing your ISR - doing much more that checking a flag or buffering 'whatever' while an interrupt is being handled. You just need to do the math to make sure you can't miss a slave SPI CLK pulse. It should not be a big problem as I doubt you need insane CLK rates coming in on your slave channel.

Who's sending you slave SPI? What sets its clock rate?

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[MacGyverS2000]

Keith, my point was there are significantly cheaper solutions per MIP than PIC offers. They've come out with some high-end stuff, but it often seems like they're MIPS scale is linear while their price scale is logarithmic. Once I get much beyond the power a 16F630 (and similar) chip can offer, I start looking at possible alternatives for the money.


Dan - Owner

http://www.Hi-TecDesigns.com

 

[CarbonWerkes]

Hi Keith

At present, the master is a 4550, which is just acting as a USB-SPI bridge (well, it is also handling RTC and SD interfaces). The slave is a 4680 which is dealing with a USART interface, the hardware SPI interface to the master, and then (hopefully) access to the IMU components.

I may be better off just going with a chip like the 18F8722 (vs the 4680), since that is 5V capable, and also has dual SPI modules (which Microchip claims can be in Master and Slave, respectively, at once). It also seems to have more IO pins, so that could be useful.

btw- the proto PCB is working. I wrote the master/slave code last night and it is very stable. However, at 1 mhz I am seeing some ringing (may be my cruddy Fluke 123), so Im wondering if on the next rev I should install some series resistance on the lines? Unfortunately, at 4mhz, the signaling looks more like sine waves than square, and Im not getting data through. Maybe that is the board, but maybe it is partly the 4550. Strange, since it is well powered and decoupled. Anyway, 1Mhz is fine for my needs- just wanted to give you that feedback on my experience with a first-time SPI-based layout.

Regards,
Rob

 

[CarbonWerkes]

Correction, make that an 18F6722... Dual USARTs, dual MSSPs, 12ch ADC, 5 timers, 5.5v capable. Seems like a decent part.

R

 

[itsmoked]

Dan;
I understand your $/mips suggestion. Thanks. To be honest I don't think I've ever hit a MIPS wall on an embedded system. Most of the time the customer wants it yesterday so having already spent a bunch of time clawing up learning curves of certain micros, usually tripping over insane gotchas, and learning how to work around them, leaves a developer kind've stalled in a few processor camps. Not to mention, having thousands of $$$ sunk into IDEs, compilers, compiler maintenance contracts, and ICEs, further negating the 'interest' in jumping ship.

I find my mind can pop out solutions from existing knowledge/experience much quicker than with a new micro species, and without the added, "if it can handle that", aspects of a new architecture clouding things up. Often I look at a new processor like the ARM and think 'oh that's a cool feature', but alas not a logical solution to achieve reasonable liftoff with confidence for a customer.

I suspect you are more of a contractor who may find himself at, "this year's", job with a budget to buy a development system. That can greatly open your opportunities for choosing from the hoer'dourve tray.

CarbonWerkes; Egan?

Yeah that sounds like a better move if you're not price sensitive. Watch out for that 12bit A/D. They often don't quite make it. 12Bits is no cakewalk. "Watch closely ladies and gentlemen as we place our carefully crafted A/D onto this substrate shared with a 40MHz noise malmstrom". They often have 12bits that can be read....But.

Do start thinking P24FJ though as you can see the writing on the wall. Note the "Migrating to the 24FJ" document.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[MacGyverS2000]

I suspect you are more of a contractor...

Sort of, but not quite. I've been lucky enough to work at multiple companies that each offered several processors as their chosen favorites. With each company, I learn a new processor or two, as well as learn which development tools are less expensive or worth the extra money. I also do my best to find free tools.

PIC offers free IDEs, but only for assembly... to get any appreciable level of C work will cost you a couple hundred. This seems typical of most processors. Hardware, such as JTAG programmers, can typically be had for under $200 (often for under $100). I suppose I'm lucky in that I now know a large array of processors, so in that regard, spending a few hundred dollars to work with a processor that gives me a lot of power for a few $s is an easy choice. If you're working in C, the learning curve from processor to processor should be minimal, and this should be considered heavily when you find one family is causing you difficulty.

I still do the vast majority of my work on PICS (I picked up the PM3 programmer several years back before I realized the ICE unit does the same thing for 1/10th the price. Still, I know the IMU that I'm working on is going to require more power than PICs can comfortably offer.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[itsmoked]

You're using an ARM presently?

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[MacGyverS2000]

A project from earlier this year used an ARM9... 'twas an odd architecture to get used to, having separate registers to set/reset bits.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[CarbonWerkes]

back from the dead...

Im moving to the 24H PIC; aside from the vectored interrupt stuff, I get a better ADC and 4x the power, plus a lot more RAM.

Downside of course is the ADC. However, I figured if I just use a divider, that would allow me to support say 0-15V (nice for automotive), and 12bit gets me about 4mv resolution (with some slop Im sure). But from an input perspective, should I just stick a buffer between the input and the divider, so that I dont have to deal with high impedance on the ADC side, or low impedance on the signal-in side? Im sure this is a 'duh' question, but Im wondering if I might be better of just changing the gain on the buffer and forgetting the divider. I could then use a digital pot per buffer and adjust the gain in software. Any thoughts guys? Is there an easier way? My sample rate is trivial- 100hz at most per channel.

Regards,
R

 

[itsmoked]

Hi Werkes.

You will like those 24Hs.

Now I'm not following your A/D comment. (Downside?)

Otherwise - Really depends. Normally one knows this or that is being used as AIN sources. So you just handle the AINs on a case by case basis. Save money, etc.

But if you are talking general porpoise then yes by all means put in buffers. Set them up to allow gain or division of whatever signal comes along.

Remember, you can read higher impedance signals with a PIC by using a cap to store charge on the AIN channel and/or by reading the channel much slower than some speedy rate.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[CarbonWerkes]

Hi Keith

Sorry, I was thinking faster than I could type. Basically, the ADC concern is that most auto sensors are 0-5V, so a 24H with a 0-3V ADC requires some signal conditioning. But, if I decide to support 0-12V, it is moot.

Super tangent, and not worthy of a new thread- but for most purposes is it fair to assume a low-side switch is 'better' than a high side for a solenoid or lamp, etc? If the system is wired with devices to ground (most cars, for example), it is simpler logistically for a high side solution. But low side (apart from a simpler N-Channel circuit topology) allows you to sink various voltages different voltage (sources). I just wondered if there is some hidden gotcha here. Again, Im an aero guy, so asking stupid questions of EEs is part of my job

R

 

[itsmoked]

Tangent: Yes sinking has those advantages. Cheaper. Simpler. More flexible. More dangerous.

Why? Because a broken wire can result in something running when with highside solutions broken wires mean things don't run. Especially with all 'return' environments like a car/plane. Less of an issue with something like a plastic consumer gizmo.

Often run the highside switch fed from a screw or some selection bus to handle varying undefined loads.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com