Fast(!) Interface

[Bääääär]

Hello everybody!

I found out about the MIDIBox platform and it seemed to be the perfect solution for a workstation I'm planing. However, I'm still looking for a very fast Interface between several Midibox devices or other uC controlled devices. I need a transfer speed of at least 20kbyte/s.

I'm planing a master device and several slave devices, which can be addressed by an 8bit long adress-ID. Additionally to the data lines I need two or more status-lines; e.g. "new data available" (slaves pull this line to "high", when they have new data für the master) or a line to wake up the slaves for communication.

I thought about a parallel interface but where to connect it to the board? All the jacks on the core32 board seem to be in use for other extensions that devices within my workstation might need (analog ins, SD-cards, etc.)

Do you have an idea?

Thanks,

Bääääär

[lylehaze]

Designing your own interface is a tall order.

Getting it working right is even tougher.

If I needed the connections you are looking for, I would try to find a fast serial interface that is widely supported, has a robust physical layer, included error detection and collision management..

Sounds a lot like CAN bus.

I believe there was some CAN work on the midibox already.. search around and see what you can find.

Have Fun,

LyleHaze

[Bääääär]

Designing your own interface is a tall order.

Getting it working right is even tougher.

If I needed the connections you are looking for, I would try to find a fast serial interface that is widely supported, has a robust physical layer, included error detection and collision management..

Sounds a lot like CAN bus.

I believe there was some CAN work on the midibox already.. search around and see what you can find.

Have Fun,

LyleHaze

Thanks for the reply!

Yes, that seems to be what I was looking for. The only problem so far: I can't use the internal CAN support of the STM32. I found this device here: MCP2515. Seems like it would do the job. The MCP2515 has some output pins for controlling interrupts which I would like to use due to easier programming and faster dataflow. I read, that the STM32 chip on the core32-board can use any of its i/o pins for interrupts, depending on the configuration. So I'll need an SPI-interface and at least one i/o input.

Some questions: I don't want to block other functionalities (AOUT, SID, SD, Ethernet, ...) because I want my workstation to be extendable at any time with any functionality I need. So where would you connect the MCP2515 chip? I guess J16 is best for it has hardware SPI, isn't it? For what clock speed is it configured? I'd like to use the full 10MHz clock speed that the MCP2515 supports - if possible.

Where would you connect the interrupt line? J16 is in use (I dont want to use the other chip select line for this, to be able to additionally connect another module to J16).

Thanks,

Bääääär

[TK.]

SD Card and Ethernet are usually connected to J16. It is possible to connect a third device, but it should be clear to you that this slows down the overall performance of your application.

J8/9 would be an alternative solution - you haven't listed DIN/DOUT, so this port is free.

You would use the MIOS32_SPI* function to configure the SPI interface:

http://www.midibox.org/mios32/manual/group___m_i_o_s32___s_p_i.html

Configuring SPI for ca. 10 MHz clock isn't a problem (-> MIOS32_SPI_PRESCALER_8)

MIOS_SPI* transfers data via DMA, so that this clock rate indeed improves the performance.

Interrupt line: check which pins are free on your board, search in the STM32 datasheet for possible routings.

On the other hand: I would prefer STM32F105x for this usecase.

It has two integrated CAN controllers, and there is no conflict with USB.

Accordingly the transfer performance will be much better, and the complexity will be reduced -> improved robustness.

Disadvantage: it only has 256k flash maximum (yet)

But since you are planning to split tasks over multiple chips anyhow, this shouldn't be a problem for you.

Best Regards, Thorsten.

[Bääääär]

Hi!

Using a STM32F105x chip would indeed be the best choice, thanks for the hint. 256k should be no problem. The only thing I'm worried about is: I can't simply order a core32 board from SmashTV. Making my own double-layer pcbs has always been a hard task. Probably I'll try a local board manufacturer. Just one question: Is MIOS32 prepared for use with the STM32F105x? At least both chips seem to be pin compatible, what would save me the work for layouting another board =)

J8/9 would be an alternative solution - you haven't listed DIN/DOUT, so this port is free

Well actually not =) I guess this port is used by pretty much every regular MIDIbox. And who wants a workstation, that has no buttons on it =)

MIOS_SPI* transfers data via DMA, so that this clock rate indeed improves the performance.

Could you explain that? Why is it faster then?

SD Card and Ethernet are usually connected to J16. It is possible to connect a third device, but it should be clear to you that this slows down the overall performance of your application.

Yes, I know. I don't think any device within my planned workstation will need both at a time, that's why i suggested it as a possible place to connect the chip.

A third device? How? Sure, I'll be able to use three devices once I use a third chip select line. But there is no third line on the connector, or did I simply not see it?

Interrupt line: check which pins are free on your board, search in the STM32 datasheet for possible routings.

Yes, that's logical. I thought that probably some pins aren't used by the regular moduls. e.g. a pin is free on the AOUT-connector. As I said before, I don't want to block other modules to keep my project expandable. You probably have the best overview - that's why I asked.

Thanks for your hints and your support,

Bääääär

[TK.]

Hi,

Just one question: Is MIOS32 prepared for use with the STM32F105x?

Not yet, but soon. Only the USB driver has to be overworked due to the new peripheral version.

Could you explain that? Why is it faster then?

It's hard for me to explain you the details if I don't know your background knowledge.

Could you please introduce yourself first, tell something about your skills and what you already realized before so that it's easier for me to give you individual help?

A third device? How? Sure, I'll be able to use three devices once I use a third chip select line. But there is no third line on the connector, or did I simply not see it?

A chip select line can be located at any free IO pin.

As I said before, I don't want to block other modules to keep my project expandable. You probably have the best overview - that's why I asked.

There are so many different applications that I'm sure that you won't find any free pin which is not allocated by any of them ;)

Therefore pins (and SPI ports) are usually mapped via #define statements that can be overruled in a mios32_config.h file

The next MBHP_CORE_STM32 module (planned for next year) will use at least a 100 pin device.

More details about such topics can be found in the programmers lounge. I already gave you access to this hidden forum section.

Best Regards, Thorsten.

[Bääääär]

Not yet, but soon. Only the USB driver has to be overworked due to the new peripheral version.

Too bad, this is the only thing, that I wouldn't try to hack myself... I'll have to be patient and wait for the community/you to release the overworked version.

It's hard for me to explain you the details if I don't know your background knowledge.

Could you please introduce yourself first, tell something about your skills and what you already realized before so that it's easier for me to give you individual help?

Ok, here we go:

I'm 19 years, just finished school with the German "Abitur". I've been programming for quite a while, mostly using Delphi. One day I found out about the AVR chips. So far I have built a lot of things, the biggest being a Keytar (just like the "Roland AX" ones, but with _very_ extendet functionality). I guess I know most of the things to be known about the AVR-devices. Of course I'm an autodidact and therefore more of the practical manner. I make music a lot and liked all the MIDI-things. As I wrote before, I'm now planning an extendable MIDI-Workstation that consists of many independent devices. I'd like to see it becoming a platform for individual live-performance-setups and I'd like to make my workstation opensource someday - in case it works fine. But that's more or less a dream of the future. However, that's why I got into the whole MIDIbox thing and that's why I asked for the interface.

Background knowledge... Well, just give me a short hint and/or keywords. I'll ask, if the web doesn't give me my answers =) My guess about the DMA thing: DMA (direct memory access - hope that's what you mean) speeds up the whole thing for the uC doesn't need to poll for empty registers and fill registers with new data to be sent. But I'm not quite sure about that =) Just a short hint would be great, I'll dig into the topic myself if I find it interesting.

The next MBHP_CORE_STM32 module (planned for next year) will use at least a 100 pin device.

More details about such topics can be found in the programmers lounge. I already gave you access to this hidden forum section.

That's good news. I digged into the new pcb-topic already - however I havent read everything yet. I'll do that tonight, drinking a beer or something. =) From what I read now it seems like you're waiting for another STM device with more memory/flash. I could help layouting or whatever you might need help for. Yes, I know, that sounds like a young guy trying to change the world but hey - all those communities gave me the knowledge I have so I guess its just fair to give something in return. So if there's something to do, just let me know. The good thing is that I have a lot of time during the next year. Only money is a problem (as always for someone without any "real" income).

Thanks,

Bääääär

Edited July 25, 2010 by Bääääär

[TK.]

Thanks for the introduction, now I understand why you asked this question.

DMA (direct memory access - hope that's what you mean) speeds up the whole thing for the uC doesn't need to poll for empty registers and fill registers with new data to be sent. But I'm not quite sure about that =) Just a short hint would be great, I'll dig into the topic myself if I find it interesting.

Welcome to the wikipedia generation! ;)

It will be hard for you to find an explicit answer in the internet, since a DMA peripheral is used for multiple purposes. There are differences between chip families and there are different usecases.

You probably know from your AVR history, that as long as the CPU handles a data transfer with the polling method, it would get frequently interrupted by interrupt service routines. As a result this reduces the bandwidth. Even interrupt based transfers can block each other, they lead to unwanted dependencies (-> complex, inflexible, intransparent, timing critical, hard to maintain code) and they reduce the performance of the main thread(s).

In the MIOS32 specific context you have to consider that functions are running in FreeRTOS based threads that are timespliced. By using a DMA (which you probably don't known from AVR controllers) data transfers will be handled in background >>immediately<< w/o using the CPU. A CPU thread typically waits until the complete transfer (with a definable number of bytes) has been finished. While doing this it can be interrupted by other threads/ISRs - but the bandwidth won't be affected.

I could help layouting or whatever you might need help for.

Nils is still our No#1 layout slave and deserves my full trust! :)

Yes, I know, that sounds like a young guy trying to change the world

Your idea doesn't sound so unusual to me. If you would know my applications better, you would know that the concepts are already available (e.g. search for MBNET and the appr. source codes - it exists for "low-cost" PICs and STM32), resp. that complete applications already exist. The reason why I don't "sell" this as a "workstation concept" is just that I know that people would expect a bit more than just some programming experiments, but a complete "plug&play" infrastructure for cheap money, similar to Yamaha MLAN.

What I can already tell you: such a infrastructure will cost a lot of money (since multiple chips are involved), a lot of programming effort and at the end also chip resources (more flash/RAM memory for higher flexibility during runtime)

The art (and you will see this point in 10..20 years) is to create a simplified infrastructure which doesn't support everything, but which makes most people and especially yourself happy, for as less money as possible with as less effort as possible.

But I don't really want to reduce youthful enthusiasm - maybe you will find a clever solution which hasn't been found by somebody else before by working on a high-level approach based on existing concepts, and/or just by ignoring any objections! :)

Best Regards, Thorsten.

[nILS]

Nils is still our No#1 layout slave and deserves my full trust! :)

Awwww :flowers: Looking forward to it!

[Bääääär]

If you would know my applications better, you would know that the concepts are already available (e.g. search for MBNET and the appr. source codes - it exists for "low-cost" PICs and STM32), resp. that complete applications already exist. The reason why I don't "sell" this as a "workstation concept" is just that I know that people would expect a bit more than just some programming experiments, but a complete "plug&play" infrastructure for cheap money, similar to Yamaha MLAN.

I already read that MBNet page on ucapps.de but it seemed to be meant for RAM data exchange, which seemed to be a bit too freaky for me atm. Possibly it could nevertheless be used for my purposes, but I decided to find a solution myself. Not only to be proud of it :shifty: - it's just that you learn so much, inventing the wheel yourself. I don't need a fast time-to-market. My goal is to understand how things work. And it's quite satisfying, once you see that commercial products often consits of really simple technics.

What I can already tell you: such a infrastructure will cost a lot of money (since multiple chips are involved), a lot of programming effort and at the end also chip resources (more flash/RAM memory for higher flexibility during runtime)

That's why I'm happy to find a prepared environement for a 32bit cpu. It's a completly different league than the AVR chips and the prepared OS helps me to save money and time: I don't need to design development boards - and by studying the code I'll be able to learn the tricks without running into the wrong direction. Additionally the modular structure makes it easy to change a project at any time without the need to redesign it all (which is probably the most important thing I learned during my Keytar-project).

These AVR chips get knocked out quite fast, when it comes to time critical and fast calculations. (e.g. a velocity sensitive keyboard, where 2x49 switches have to be checked in a 128us cycle. I somehow managed to get it work on a ATMEGA32 cpu @ 16MHz but I guess there's not much power left for other calculations anymore - however a MIDI-Out is working :whistle: ).

The art (and you will see this point in 10..20 years) is to create a simplified infrastructure which doesn't support everything, but which makes most people and especially yourself happy, for as less money as possible with as less effort as possible.

But I don't really want to reduce youthful enthusiasm - maybe you will find a clever solution which hasn't been found by somebody else before by working on a high-level approach based on existing concepts, and/or just by ignoring any objections!

No, I'm sure you won't reduce my enthusiasm =) I'm actually quite optimistic that I'll turn my plans into reality within the next 2 years. Once the low-level things work (which was a grey area for a long time but now gets enlightened step by step) it will only be a matter of money - as I wrote before... =)

Thank you for the explaination btw. Seems like I wasn't too far away with my guess.

Bääääär

PS: We start to miss the actual topic of this thread :ahappy:

[TK.]

W/o the risk for drifting too much into an off-topic discussion: two years sounds realistic - not to complete all of your vague ideas, but at least to find something which works at your side. And I'm sure that you will gain a lot of experience by starting from scratch. :)

Have fun and don't hesitate to ask for details if something is unclear or not working, and/or to share your code (write permission to the subversion server is available for all programmers)

Best Regards, Thorsten.

[Bääääär]

After a little break, I'm working on my project again. Reading a lot about the CAN bus, I found out it's actually the best choice for my workstation. It solves a lot of open questions and saves me from a lot of programming (-> the intelligent hardware-CAN of the STM32). However I'm struggeling with hardware questions:

The STM32-Core uses a single-wire connection for CAN, connecting RX and TX via a diode. What lead to that choice? I'd like to use "normal" CAN tranceivers in my workstation (what hopefully makes the whole thing more stable) but I need RX and TX for that. Would you say it's enough to use one wire for CAN between e.g. 32 devices (with a total of ~10m of connection cables) and 1MBit speed? I'd prefer differential CAN, but that would mean to de-solder that diode between PB8 and PB9 and add a new connector.

And one more thing: In the MIOS32 SVN, I found CAN sources provided by ST. However, there seems to be no MIOS-Module for CAN so far. Or did I simply miss something here?

Thanks for your help,

Bääääär

[TK.]

I developed a complete MBnet module which is available here: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fmbnet%2F

Programming example: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fmbsid_can_osc_proxy%2F

I think that this will answer your question? :)

Yes, you probably need a CAN tranceiver for connections > 30 cm!

Best Regards, Thorsten.