Bääääär

Hello community! While developing my first MidiBox project, I noticed that the wiki is a bit messy (meaning some things are hard to find and lack a common style that makes orientation easier). Especially the problem of MIOS8 and MIOS32 brought me into trouble - which wiki page is meant for which OS? This thread is not meant to be an allegation, but to sum up ideas how the wiki could be improved. I know that I'm a newcomer here and thus not the right one to start the "geart reconstruction of the wiki". However, I think that others might share my opinion and I'd like to contribute some work to make the wiki more readable, especially with the MIOS8/32 problem. The first point would be the following: Comparing our wiki to others, I miss the sidebar and a header line. One of the main orientation issues for me was to get back to the start page. It took quite a while until I found out that the small MidiBox logo is this link. However it might be cool to have a header line with some important links in it: Main page What is "MidiBox" (might be usefull for those who found it via google etc.) Design rules for wiki page etc. The sidebar could contain links to the most usefull pages like FAQs, popular MidiBox devices and the main sections such as MBHP, MIOS, etc. as well as all the external links in the header of the forums (ucapps, forums, gallery, ...). Which pages are linked there in particular could be discussed later on. I personally don't know much about the wiki-system used and if these things are possible, but I'd really like to change that. The second point is a common design. To make a start, I set up an example wiki page that could be used as some kind of template for new wiki pages. This is my suggestion: http://www.midibox.org/dokuwiki/doku.php?id=wiki:test_page I liked the idea of a little side-box that displays some relevant information. It could have different table rows, depending on the content of the page. As an example, a page for software-tips may have a row with the matching OS (see my link), a page for a hardware module may have a row "connects to => J17 on Core8, J4 on Core32" or something like that. Some coloring could also make the wiki better. What about giving the main sections different colors? The side-box could then be in the color of the section the article belongs to. However, i'm not completely satisfied with this example page right now, but here's where everyone can change something, until we find the perfect solution. One more thing: What about adding logos for MIOS32 and MIOS8 or both to each article? (logos like USB1.1 and USB2, ...). Thus you can see, for which OS the article is meant. Well, that's all for now, Bääääär

Hello @ all! Thanks for your answers. Yes, indeed, I forgot to say I'm working with MIOS32 - sorry :wacko: @Duggle: Nice idea! I guess I won't use it this time, but I will keep it in mind - seems like a great way to save processing power! PDM, is that your word-creation? The main problem I see is that you have to change MIOS32 files - I'd better not do that until I fully know, what I'm doing. Guess it will become very hard to get help, after I fuzzled around in the system's files. Once you did one hack to the system, others will follow and by the time, the whole MIOS32 will become a big mess :hmm: I'd better wait with that... @TK: I tried your hint. However it doesn't work at the moment. I added the #define switch to disable SRIO scans by the system. Then I added the timer initialisation as described in the tutorial. In the timer routine I call "MIOS32_SRIO_ScanStart(SRIO_ServiceFinish);" as done by the system when the switch is not applied. Of course SRIO_ServiceFinish() is not found and I get a compiler error. I went the brute-force-way and added a forward declaration for it. Compiled good but during boot-up of MIOS32 nothing happens, even the display stays empty (no boot message). Well, I have no idea right now, but I'm scanning through the MIOS32 code to find the solution... I don't think it's a timer problem (timers seem to be a simple thing in MIOS - idiotproof [hopefully...]). Maybe you can help me out another time :rolleyes: Thanks a lot, Bääääär

Possible... However, the search function didn't help much in this case. Well... And the update-cycle can't be changed? I read it doesn't consume much CPU (DMA), so that shouldn't load the CPU too much. From the flickering I see at the moment, a update-cycle four times as high should be enough. I don't want 32bit PWM, 4bit is ok - and like I said - it shouldn't laod the CPU too much. Only my PWM-routine (executed before SRIO update) takes some cpu-cycles. But hey, if that works fine on a AVRs @ 16MHz without DMA but with software SPI, then it should definitly work on MIOS32. Thanks anyway, Bääääär

Hello! I habe lots of LEDs for my project (more than 160) and wanted to save DOUT-pins by using a matrix. Works fine so far, but now I wanted to go further and included PWM in my code. Works fine too, but the LEDs are flickering in 4bit PWM and a matrix of 5x11 LEDs. The update cycle of DOUTs is too low, but how can I change it? I don't find any info on that in the doku and it doesn't seem like there's any opton in the project's config file... Please help me out ;) Thanks, Bääääär

Thank you all, I finally made it! :) But there's one thing that needs to be changed: How do I find the MIOS32-guide without this direct link posted by phil? I didn't find any hint in the wiki. But IMHO this link should be on the first page so you see it, when you enter. And maybe the "old" MIOS8 guide should be marked as MIOS_8_. At the moment it is just called "MIOS guide" and that caused quite some confusion to me. Do I have wiki-permissions to add this hint? Thanks to all! Bääääär

Hello! I followed your advice and changed the variables. It didn't work first, but after changing from the "/c/users/" style to "c:/users/", it worked fine. I got quite a lot of errors from then until it dawned on me, that the setup guide in the wiki is probably meant for MIOS8 (??) and therefor the downloaded files are MIOS8 and not MIOS32. So I deleted all the base-files and re-downloaded them using SVN (in the hope to get the right files this time). Now i get this: D:/Bastelzeug/mios_base_v1_1/include/makefile/common.mk:122: *** multiple target patterns. Stop. {common.mk, line 122 contains: $(PROJECT_OUT)/$(PROJECT).elf: $(ALL_OBJS)} Sorry but I don't know what to do from here... Bääääär

Hello to all! I've just received and built my first core32 and now I'm trying to set up the toolchain, following the detailed setup guide in the wiki. Using SVN I downloaded the Tutorial 001 and tried to compile it: makefile:48: /programming_models/traditional/programming_model.mk: No such file or directory makefile:51: /modules/app_lcd//app_lcd.mk: No such file or directory makefile:54: /include/makefile/common.mk: No such file or directory make: *** No rule to make target `/include/makefile/common.mk'. Stop. In the second line, you can see, that there's nothing inserted into the $(LCD)-gap I can see in the makefile, and it pretty much seems to be the same with the other lines, where the first part of the path is missing. I can find file two and three in the mios-base directory, the first must be somewhere else. However, it looks like the environment-variables are not right here. I read something about a ".profile"-file in the forums but that seemed to be related to linux. I have the following environement-variables in my system: User: MIOS_BIN_PATH = D:\Bastelzeug\mios_base_v1_1\bin MIOS_PATH = D:\Bastelzeug\mios_base_v1_1\ PATH = D:\Program Files (x86)\SDCC\bin System: PATH = D:\Bastelzeug\WinAVR-20100110\bin;D:\Bastelzeug\WinAVR-20100110\utils\bin;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files\Java\jre6\bin\ ;C:\Program Files\TortoiseSVN\bin What else might be wrong here? Thanks! Bääääär

I've built my own midi-keyboard using an ATMega uC and two 74HC138N. You can get Fatar keyboards without electronics at Doepfer's webshop, which can be connected to my board. It works very well, it's velocity sensitive and you can even programm your own velocity curves. If you're able to burn avr-chips, I could send you some shematics and the sourcecode. Alternatively you can get the matching electronics at Doepfers shop too, but the price is incredibly high (IMHO). The Keys are about 80€, the electronics are about the same price if you by them. Well, I'm not quite shure about the prices anymore, but it's something like that. Bääääär

Wow, that's good news! Thanks,! Looks like I'll definitly build a core32 with the STM32F107RC or the STM32F105RC then.

Hello MIDIBox-community! For a huge project I need USB and CAN in parallel - the Core32 board doesn't support this atm. That's why I looked for an alternative chip to use instead of the STM32F103RE and found this one with less memory (256kB - that's ok for me) but 2xCAN and even Ethernet on-chip: STM32F107RC. STM promises their portfolio of MCUs to make switching form one to another very easy (full pin compatibility and so on). So I really started thinking about adapting the MIOS for this MCU. But, well, I didn't really work with the MIOS so far (although I read a lot about it). I would buy a core32 and start testing, but well - it doesn't fit my needs and buying it only for the first steps with MIOS seems to be a bit senseless to me. So before buying things, witch I might never need, I'd like to check if it's possible, to adapt MIOS for my needs and probably build my own core32 with this MCU. Quite a long story for a simple question: How much effort would it make to adapt MIOS for this kind of MCU? Is anyone also interested in doing this? Thanks, Bääääär PS: I know that a new core32 is planned to solve the flaws of the "old" core32 (USB/CAN) but as far a I know, TK is waiting for a new chip with at least 512kB and the connectivity-options that the STM32F107RC is already supporting at 256kB. But it seems like STM will need some time until this new chip is released.

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. 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: ). 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:

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. 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. 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

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 =) 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 =) Could you explain that? Why is it faster then? 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? 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

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

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