ilmenator

Post some pictures of the mess here, otherwise it's really hard to say anything...

Hehe, looks like nILS is around...

Oh, I see - :w00t: Btw, I think I was a bit unclear: I meant adding SOLVED to the title of the forum entry: "No SID sound ! (CORE8+SID)" --> "SOLVED No SID sound ! (CORE8+SID)". Sorry!

I assume that it's working now - congratulations! Would you mind telling us what the problem was? Also, it's a good idea to change the headline of the first post to contain the word SOLVED :thumbsup: !

Check first if Electron give a max. size of CF card the unit can handle. This will most likely be the case, and is due to the file system implementation they are using. Chances are that larger hard drives will not work because of this, even if your adapter would do the job properly.

Damn, nILS beat me to it...

Here is a blog about cell phone displays attached to microcontrollers - seems like a nice alternative, e.g. for channel strip info, with some of these displays being dirt cheap and really good quality.

As he said that the thief did not take the power supply, that is a pretty good indicator, together with a photo, I would think. If it showed up on ebay, ask a few insider questions and see how well the seller can answer. Unfortunately, I am not so sure about success rates when it comes to getting back the MBSID, based on such evidences...

I definitely had a mental block! Thanks!!

Hi, I have this typedef struct prog_list_tag { u16 index; u16 bank_number; char file_name[4]; char bank_name[16]; } prog_bank_list_t; // each entry represents one available PROG bank on SD card prog_bank_list_t prog_bank_list[100]; and this: extern char current_prog_bank_name[16]; How can I copy the bank_name in the struct (e.g. the one in the second entry of prog_bank_list) into the array current_prog_bank_name? I think I got a mental block right now...

Welcome here! This also means that you will need a DIN and a DOUT module. That is easily done writing your own C code, starting from the app skeleton. Have a look at the tutorials to see how easy it really is.

Good to hear that it is probably not just my stupid fault, but in general that is bad news. For my application it would be very nice to have LFN, because that would allow the use of meaningful names. My files contain banks of patch data or banks of PCM data, in analogy to the RAM/ROM sound cards and PCM cards used e.g. in Korg M1 and the likes synths. Each "card"/bank has its own name encoded in the data, and for my system these are visible by reading out these portions of data from the file itself. But for a user on a PC who might want to exchange bank files stored on the SD card with someone else (especially interesting for PCM banks!) it is hard to know which is which without meaningful file names. The code conversion functions - ff_convert() and ff_wtoupper() - are part of ccsbcs.c, they are already there, and code page is set to 437 - U.S. (OEM) by default. This is what I want, no fancy chinese characters required! I have seen this post, doing this has the same effect as declaring FILINFO static - i.e. it prevents my app from crashing, but it does not help in retrieving the long file names - unless I did something wrong...

I kind of stick out :frantics: - my multimeter does not beep! A good old Voltcraft DM 301 (Conrad?). At least twenty years old!

No, as the project they were intended for never happened :unsure: As far as I remember, I did not touch any dimension-related aspects of the component after the conversion, just naming convention of the pins. Anyways, the whole thing could be dead wrong or not even intended for PEC11, I don't remember...

Well, apparently my mistake was that I was reading de.fname[] instead of de.lfname[], so of course I should get the short file name... Unfortunately, no matter what I do it seems that de.lfname[0] is always NULL. I fiddled around a bit with ff.c to make sure those parts of the code dedicated to LFN are actually executed, which is the case, but I guess I am stuck there.

Now, that's a smart idea :thumbsup:

I am basically using SEQ_FILE_GetDirs() from ..\trunk\apps\sequencers\midibox_seq_v4\core to read the directory. I assume you are refering to DIR di; FILINFO de; and if I change that to DIR di; static FILINFO de; the application does not crash any longer, but shows short filenames as in [42316.128] [SCE_FILE_GetDirs] SCE_FILE_GetDirs function entered! [42316.128] [SCE_FILE_GetDirs] WHILE loop entered! [42316.128] --> 001.bin [42316.129] [SCE_FILE_GetDirs] WHILE loop entered! [42316.129] --> 002.bin [42316.129] [SCE_FILE_GetDirs] WHILE loop entered! [42316.129] --> 003.bin [42316.129] [SCE_FILE_GetDirs] WHILE loop entered! [42316.129] --> 004.bin [42316.129] [SCE_FILE_GetDirs] WHILE loop entered! [42316.129] --> 006VEC~1.BIN [42316.129] [SCE_FILE_GetDirs] WHILE loop entered! [42316.129] --> 006.bin I'm not really familiar with the project.map file and its interpretation, but I could not find either of the two in there!?

Okay, that transition was almost pain free, and I have parts of what I need up and running - great! Now I got adventurous and tried to switch to LFN mode - I enabled the long file names. That means I added #define FATFS_USE_LFN 1 to mios32_config.h and everything compiles just like before. But unfortunately, when I try to read out a directory, the application just crashes. With LFN disabled the same code works like a charm. Thorsten, have you tried LFN, and did it work for you? Thanks, ilmenator

:frantics: Nicht, dass ich hier klugschei**en will, aber: Die meisten Fehler haben wir alle auch selber mal gemacht... :wink:

On the stacking works quite well, but then the headers go around all of the 25cm x 25cm boards. In your case I would probably add mounding holes (one should do if space is an issue) that could be used to fix the boards to each other with a long enough M3 or so screw.

The DIL headers seem to be a little too close? At least if you prefer the kind of connectors that hold the plug tightly, like these: (Disregard that this particular one has a 2mm grid.)

MIDI in wird mit MIDI out verbunden und andersherum. Ich benutze dieses Interface - funktioniert sicher!

Most component grids are 2.54mm, so both board and frontpanel grid should follow that convention.

Sind sowohl MIDI in als auch out verbunden? In MIOS Studio sind die korrekten Ein- und Ausgänge angewählt? Kannst du ein anderes MIDI-Interface nutzen? Diese kleinen USB-Kabeldinger sind bekannt für Probleme mit SysEx-Daten...

PM sent!