philetaylor

Probably worth trying as if nothing else you can eliminate XP Mode as the cause. What Midisport do you have as it should just use the "class compliant" drivers included in Windows 7 for the Uno, 1x1, 2x2 and 4x4 There are also beta Windows 7 drivers available from here I don't know how stable they are though :) Cheers Phil

I think that this may very well be the problem. Do you have a midi interface that is directly supported by Windows 7 I haven't been able to successfully use either version of MIOS Studio over XP Mode, I got lots of timeouts. It isn't clear which version of MIOS Studio you are using? Is it the Java one (V1) or the Juce one (V2)? Cheers Phil

I would certainly say it is a few hours ahead of it's time ;) Phil

Perl is only "required" if you wish to "make dist" MIOS apps. I thought you were developing for MIOS32??? If you "really" want perl, you could always try http://www.activestate.com Obviously putting a direct download link to make things easier for people can backfire when the download location changes :) Cheers Phil

Not exactly. The System and User environment variables effectively do the same thing. System is "system wide" and User is configurable on a "per-user" basis. As a MINUMUM, one of those (system or user) must have ";C:\MSYS\1.0\bin" and ";C:\Program Files\CodeSourcery\Sourcery G++ Lite\bin" The reason I said add this to the user environment is that you can't then break anything "system wide" if you do it wrong :) The instructions aren't very clear I admit! What you need to add (in the user section) is: Variable: Value: MIOS32_PATH x:\path\to\trunk MIOS32_BIN_PATH x:\path\to\trunk\bin MIOS32_GCC_PREFIX arm-none-eabi MIOS32_FAMILY STM32F10x MIOS32_PROCESSOR STM32F103RE MIOS32_BOARD MBHP_CORE_STM32 MIOS32_LCD clcd If I get time, I will try to add some screenshots and improve the wiki instuctions! Cheers Phil

If you don't have a USER Variable called "PATH", just create it. Windows will automatically add it to the end of the system variable "PATH". As long as you don't mess about with the system path, you can't really break anything. The order isn't that important, it becomes more important if you have multiple versions of the different utilities like make etc.You just need to make sure that the MSYS bin directory is in the path. (CodeSourcery should set the system path itself) Cheers Phil

Hi. When you turn on the core, do you get an upload request every second in the MIDI Monitor? If you have the same info in the MIDI IN and MIDI OUT monitors then that means you have a loop, either a software (wrongly patched in MIOS Studio maybe) or hardware (in and out connected together). Can you post a screenshot of the MIOS Studio Patch screen? Also check your connections. I doubt you have "killed" the PIC unless you did something REALLY stupid. I have applied power with the PIC inserted the wrong way round and various other things and never blown one up! What you have probably done is corrupt MIOS. MIOS can be downloaded from http://www.upcapps.de and you can use MIOS Studio to upload it. You may want to try MIOS Studio 2.0 as that has (IMHO) better MIDI handling and is less confusing to use :) The MIOS boot phase is: BOOTLOADER Starts and sends an upload request. It waits a second for a response and if it doesn't get one, it will boot MIOS. If MIOS can't be started then the BOOTLOADER will reboot the PIC. (The line of black on the display usually means that you are at this situation as this means the LCD has power but has not been initialized). If MIOS can be started then it will start. It initializes the display and then isplays the Copyright message and if an application exists it will start it. If no application exists, it will display READY Cheers Phil

Probably Flea Market or Miscellaneous/Miscellaneous.... This forum is intended for people asking for permission to sell products that are based on MIDIbox software/hardware. I took a quick peek at your website, looks interesting :) As one of the most expensive parts of a project is often the front panel, if you are competitive then I'm sure you will get business here ! To get an idea of pricing, I tried uploading the design for Wilba MB-SEQ, dxf is available from here: =wilba&s[]=mbseq]http://www.midibox.org/dokuwiki/doku.php?id=wilba_mb_seq&s[]=wilba&s[]=mbseq to your estimator program but it thinks that the panel is 482.600 inches by 132.080 inches so a bit big :) Cheers Phil

I think that is a "placeholder" The instructions are here: http://www.midibox.org/dokuwiki/doku.php?id=windows_mios32_toolchain_core Cheers Phil

That may be my fault... I inadvertantly left debugging on when I committed my last change. That logs every read and write to MIOS Studio which will "massively" slow the operation down :) It should be quite a bit quicker now. Cheers Phil

I thought that might be the reason :) In case you haven't seen it, this has been discussed before: Cheers Phil

Which PIC do you want to use? MIOS supports the PIC18F452, PIC18F4620 and PIC18F4685. Any other PIC device would require possibly significant changes to MIOS. Cheers Phil

That doesn't sound good.... If you are not even getting the MIOS welcome screen then unless there is a wiring error, it does look like the display is toast..... Cheers Phil

Hi. It looks to use a standard HD44780 or equivalent controller so should definately be supported by MIOS8. What app did you have loaded on the core? Is it definately compiled defaulting to the clcd driver??? Most LCD problems are related to wiring, so I would double and triple check it, also what PIC are you using? The PIC18F4685 for example only supports 4-bit LCD connections. What mistake did you make when you connected it? Was there smoke ? Cheers Phil

OK try it now. I have tried another option which uses: 16 << (csd.DeviceSizeMul>>4) which should be a more reasonable number. Try the latest svn! Cheers Phil

Oops, double post (it looked like it had hung!)

It should be pretty quick (a few seconds).... This looks like another CSD issue: This should be (16<<csd.DeviceSizeMul) although for some reason your DeviceSizeMul is 240 and 16<<240 will wrap quite a few times. I would expect DeviceSizeMul to be between 7 and 9 !!! Leave it with me for a while and I will see what I can do :) Cheers Phil

It looks like I never committed my latest changes to mios32_sdcard.c (oops!) Can you download the latest svn and try again please? Cheers Phil

It is possible that the card is faulty but it is also possible that the size detection algorythm that I am using is wrong :) I have made various changes to the detection code as it uses the cards CSD (Card Specific Data) to find the size etc of the card. Unfortunately, when I wrote the SDHC (V2.0) detection code I didn't realise that the CSD format had also changed. This is why csd->DeviceSize was reported as 0 in your earlier post. The CSD should now be correctly reported so could you try the CSD command on mios32_tools now please and post the results? The problem is that there are at least 3 distinct types of card, SD SDHC and MMC, each one requires special handling and although I do have one of each (which are working fine), different manufacturers seem to interpret the spec differently. Most of mine are SanDisk cards and because they wrote the SD/SDHC spec, hopefully they are the most compliant :) Cheers Phil

before you format it in windows, could you just run the "filesys" command please? Cheers Phil

That's great. Since I started looking at SDHC/MMC support some months ago, I have discovered that all cards were not created equal :) I will see if I can find a better solution (as that was a very quick hack). Cheers Phil

I know this really isn't helping you to get a working sd card but it gives me some really interesting debug info :) It looks like your card doesn't confirm to the SD spec fully. All of the SD/MMC cards that I have tested, all report csd->RdBlockLen of 9 whereas looking at your previous posts, yours reports 0. The format routine needs to know how many 512byte sectors can be written at a time and this uses RdBlockLen. Attached is a quick hack which forces rdblocklen to 9 if it is returned as 0...... Cheers Phil project.hex

That is strange, can you try running this version (I have enabled debugging) Phil project.hex

Here is the same MMC+ card using the new "benchmark" function, the copy overhead isn't much at all really.. [3101294.650] benchmark [3101300.205] benchmark: Starting [3101300.205] Write: 1048576 bytes in 1.375 seconds (762 KB/s) [3101300.205] Read: 1048576 bytes in 1.364 seconds (768 KB/s) [3101300.205] Copy: 1048576 bytes in 2.814 seconds (372 KB/s)

I got some interesting results copying the same 12MB file with some different cards. A standard Lexar 128MB card was the slowest at 122KB/s, then a 4GB Sandisk Ultra II SDHC was 202 KB/s, the surprising thing was a Dane-elec MMC+ 1GB card managed 365KB/s, nearly twice as fast as the SDHC :) Cheers Phil