what's the SPI clock speed of a midibox

[Ravager]

hey guys, hey TK,

 

I'm planning on building an DIN/DOUT encoder board - similar to the one we've just seen as a bulk order but with a few cool features.

It's going to be microcontroller-based (using SPI slave mode).

 

so how fast should the microcontroller be? usually the allowed SPI clock speed is half the uC-clock

 

I could go for an ATMEGA, with around 20Mhz but if that's not enough, PIC would be an option (up to 64Mhz). However, I'm not that familiar with PIC programming (and I don't have the necessary hardware) so if 20Mhz is enough I'd like to stick with AVR controllers

 

 

what do you think?

tk?

 

cheers

rava

[TK.]

Hi Rava,

 

today a typical MIDIbox consists of the MBHP_CORE_LPC17 module, the SPI transfer rate can be changed during runtime and is typically chosen based on the bandwidth requirements and max. "desired" cable length.

 

Anyhow, what kind of informations have to be transfered over SPI?

And why do you think that SPI is better than MIDI at the common baudrate? Doesn't this overcomplicate things?

 

And why are additional Microcontrollers required at all?

E.g. MBNG could control up to 8 LRE8x2 boards from a single SRIO chain (see  for a setup which uses only 4 LRE8x2 to get an impression how big such a controller is)

And MBNG provides pretty cool features as well! ;-)

 

Best Regards, Thorsten.

[Ravager]

thanks TK!

 

isn't SPI what you use for "talking" to the LRE boards? I haven't had a closer look at the core yet. Looks like J8J9 is connected to SPI. So that's what I wanna use as well (build a SPI slave device) :-)

 

there will be a few features in the board I'm going to use that require a Microcontroller; I don't wanna boost to much about it because it will probably turn out that I can't build everything the way I want it to be. But I'll be back as soon as I get some results - which will take months because I don't have that much time these days :-(

 

one big disadvantage is that it's going to be huge compared to what we've already got. But we'll see!

 

So I'll just assume 20MHz clock speed (that is 10 MHz SCK-speed = 10Mbit/s) is enough?

I don't wanna process that much data in my little device but if the I/O-chain is long it could be required to forward a lot of stuff through SPI to the next devices :smile:

Edited March 3, 2013 by Ravager

[TK.]

J8/9 is used to scan the shift registers periodically, it isn't used to "communicate" with a SPI slave device. For such a purpose, somebody would use J16 or J28

 

Well, I still don't know what kind of data has to be transferred, how should I estimate if 10 MBit/s are enough?

 

And:

 

 

I don't wanna process that much data in my little device but if the I/O-chain is long it could be required to forward a lot of stuff through SPI to the next devices

 

I don't know what you mean with this statement... :-/

 

Best Regards, Thorsten.

[Ravager]

as I said it's going to be an encoder board. So there will be encoders (DIN) and LEDs (DOUT) as in the LRE board - receiving and sending data will be done by the uC I'm currently choosing.

 

in SPI slave mode a microcontroller should behave like an Shift register: when receiving a SS-Signal (SCL) it stores all the data from its hardware shift register. My program should then write back the desired output data to the register. So the in/out-chain has to from a closed loop (otherwise the Core wouldn't be able to receive the data created by my board). But that's just a physical wire - no problem.

 

How much data is sent depends on the format I specify (and I most likely have to adapt the core software a little bit depending on which format I choose). And of course it depends on how many of these encoder-boards the user daisy-chains. And of course on how many other register-devices are served in this SPI loop.

 

So let's just put it that way: Is it ok if I assume the serial clock frequency depends on the amount of data that has to be sent? So I will just run into trouble if I build a daisy-chain that is waaaay to long? the core actually adjusts some sort of pre-scaler for the whole communication? If the signals are too fast, my uC might miss them - even if the overall frequency is low! _||_______________||___________________||_________...

[TK.]

Well, the SRIO driver of MIOS32 wouldn't be suitable for such a kind of communication, and especially the new paged SRIO would conflict with this (it allows to dim the LEDs, which is especially useful for RGB LED configurations)

 

Means in other words: your board would have to be accessed from J16 or J28 like other serial slaves, such as AINSER64, AOUT*, a SD Card, etc...

 

 

So let's just put it that way: Is it ok if I assume the serial clock frequency depends on the amount of data that has to be sent? So I will just run into trouble if I build a daisy-chain that is waaaay to long? the core actually adjusts some sort of pre-scaler for the whole communication? If the signals are too fast, my uC might miss them - even if the overall frequency is low! _||_______________||___________________||_________...

 

I guess that you noticed this already by yourself: than higher the bitrate, than higher the danger that your microcontroller can't forward serial data fast enough which would result into data loss.

 

So: you have to define a maximum bitrate at which it's ensured (under all conditions), that data can be forwarded on time without the danger for a buffer overrun at the SPI receiver site (e.g. by using an interrupt based SPI handler which is invoked at highest priority).

As long as this is ensured, the number of connected slaves in the chain doesn't really matter anymore - they will only increase the latency of the data transfers.

 

Best Regards, Thorsten.

[Ravager]

okay, fair enough!

thank you!