stryd_one

Heh, what's a 7912 when a 7912 is not a 7912? a 7917, of course! Who's the dodgy brand we should avoid, nILS?

Cue Playbo$$/turuloid in 5...4...3......

Nope.

No joy here today either.... What about attaching it to the post?

Sounds like you measured from the +5V line, you should measure from GND to -12V. Could you double check?

you might like to try the SRIO interconnection test, and the ai64_din128_dout128 app. The former will check the serial connections and the latter will allow you to check the encoders (as though each was two switches) Smash's encoder quality is great, and you should be fine without the IC inserted. Are you sure it was a dead IC? Did you swap it with one of the others and see if the short was swapped too? Maybe the short is still hanging around....

Well firstly that string's too long ;) Although maybe that's not the problem, it doesn't help that we aren't looking at real code... I can see a few reasons that might not work... Just to demonstrate why it's important to show the real code, when I tried what you said, unsigned char CTL_NAME_PART1[17][9]; // the ninth character is for \0 CTL_NAME_PART1[0]= "whatever"; I got this: main.c:74: error 47: indirections to different types assignment from type 'const-char code-[9] ' to type 'unsigned-char' Which is expected because I'm trying to assign the string from codespace to ram. You need to use memcpy or similar for that. (Note that the last time I tried memcpy it didn't work and I didn't try ito fix it yet) In order to get the error you referred to, I had to do this: unsigned char mytest[9]={"Whatever"}; CTL_NAME_PART1[0] = mytest[0]; So... do like my sig, and copy and paste, please! The memory errors may or may not be problematic, uhm... can you copy and paste for us ;)

Asking for help is always encouraged, but without knowing your design it's impossible to say... So, first you should help yourself, then we can help you :) For example, if you read the ucapps.de page, you'll already know that: And on the same page you can find: Options So you see, that the answers to your questions are already mostly answered. If you show us that you have been to these pages, and done some work on it, but still have some questions... Then we can help.

Sounds like a great price :) I'm in for a few at least....

It's not meant to help you, it's meant to encourage you to help yourself. DIY remember ;) Search Depends on your design. Depends on your design Depends on your design

Feel free to try it out :)

First I'd put the latest RC on there.... What if you disconnect the LCD? You'll know if it reboots because it'll send midi messages.... But yeh, I'd look for shorts...

Then I'm a newb too :) Good work man! I think vero is a perfectly respectable way to do it...

Craze Craze

True, but midi isn't audio, and 5V is only enough for the digital circuits :) So, first I would pull apart that charger, and post a pic if you're unsure... If it's 5.7V unregulated, then it won't be enough to drive the regulators and output 5V. If it's already regulated then maybe you could mod it to reduce the output (not sure about that....)... But I imagine it will be unregulated 5.7V, designed to drive regulators in the phone which output 3.3V, and not suitable for a midibox. Sorry :(

Comon man you can figure it out... just decide upon a design, count up the parts you need, and get your calculator out :)

CS=Control Surface Sounds like a BOR... Have you disconnected everything so it's just the core you're working on? No DIN/DOUT/etc?

yeh, thanks! A tip for next time: You can attach files to your posts here, so no need for rabidshare ;)

Thanks for the pics man! I must be looking in the wrong place, because the page hasn't been updated... Where are you going for these?

Hey cool vid! :)

That pic is a beautiful thing, thanks for sharing dude :)

WOOOO!! (and the crowd goes wild)

Argh browser crash, just as I was finishing my reply. Minefield is living up to it's name... Still seems to me that it could be avoided by buffering though... MTE and I bumped into this when doing his 8-nokia-screen thing... I was trying to find the bug in my code for days until (i think it was seppo) pointed it out.... buffering it fixed it right up :) Of course, there will be limitations in the PIC as far as how many it can handle in software, but, in theory, the fan-out limit should be avoidable? Yeh that's perfect - you'll have CC7 stored, so 'software unmuting' would just be returning to that level :) Would be nice :) First stop for me is always www.piclist.com 's source code repository. MULWF will get you 8b*8b into 16b, so you just need a 16b*8b... Check out the theory here: http://www.8052.com/mul16.phtml Or there's actually a lot of good google hits (for a change): http://www.google.com.au/search?hl=en&as_q=8bit+16bit+multiply Maybe scope out the microchip site for an appnote too, or even atmel's, because some of them use a 8*8 hardware mult too.... Or write it in C and see what the output .asm file looks like... The later versions of SDCC seem to make better use of the MULWF instruction so you might get lucky :)

Oh awesome. This is great news for two reasons: 1) You box works 2) Now people will believe me when I tell that story :D As far as I know, only you and I have had that problem.... It's a very exclusive club!

Ahh no worries man :) You might like to check out the enhanced clockbox too, to see the dividers at work in C.