stryd_one

I don't suppose you'd like to share the answer for everyone else?

Just for the newbies: The above post was a joke. DW can get away with it cause he's a regular around here... Just a thought from me: When you say "I'm waiting patiently" - that is not waiting patiently! That's waiting loudly.

Uhm... how so? That'd be about the most complex answer I could think of... The more I think about it, the more a switch makes sense here. If you think about what the aim is, it's just a simple matter of *switching* the LCD from one core to another...

There are faster switches you know, that one isn't etched in stone, it's just the first one I saw, posted it to demonstrate... That's why I left the google search in there... Anyway it doesn't have to switch with every byte sent to the display, only switch at the beginning of sending the bytes. My original search was for logic BTW, but I didn't find anything quite so suitable. Let's see about the truth table... We have three inputs and an output... In3 is the control of which core has locked the buss, In1 is from the first core's output, In2 is from the second core, output goes to the LCD In3 In1 In2 Out 0 X 1 1 0 X 0 0 1 1 X 1 1 0 X 0 So what is that, logic wise? I'm at work, only posting this cause I need to restart my browser and close the tab... If someone doesn't nut this out before I get back from work I'll actually apply thought ;) Regardless, I think a switch will do the trick.... And it's bidirectional which is good for my own case (but not relevant for MTE)

http://www.google.com.au/search?aq=f&num=100&hl=en&safe=off&as_qdr=all&q=%22quad+spdt%22+analog+switch+TTL+DIP&btnG=Search&meta= pair of MAX394, driven by a spare pin, and another spare pin on each of the two cores to negotiate control of the bus ? I have an interest in this myself, keep us posted MTE :)

Hello! Mulint is the function used by SDCC when you need to multiply an integer, which you do when calculating the array address from the index. In order to have this function, you need to include LIBSDCC in your linker script. Alas, that is about to be/has been phased out, I removed the documentation from the wiki last night, as the new MIOS/GPUtils structure includes it automatically. You could consider looking at the new structure in SVN. Anyway, in the meantime, grab the library from here and read the readme :)

No, you read another thread about RUMOURS of bogus parts, which are not yet proven, and if anything have been proven FALSE. Please feel free to direct me to any real hard evidence, otherwise let's not start this conversation again ;)

HAhahaha...my first thought for my reply was "Pure insanity" Then I saw all the other people: Uhm... I hope you have a good headshrink ;D

Hope the surgery is minor and uneventful ;) (and they give you some of those superfun painkillers, wheeeee)

Ummm, yes! Keywords union struct bitfield by user stryd* First hit is : Re: Bitfield s are no longer limited to 8 bits! Yay!. That's not it. That's me proving that we can now have stupid size bitfields. Second is this thread right here. Third is the one about bitfields: Re: Scan Matrix extended : VOIRINOV

I would very much like to have a C-wrapped ASM CAN implementation, but there isn't one yet. It's also quite possible to make a performant library written in native C, but... Why bother when the ASM is already done :) Totally doable. I guess you've already seen the MIDIbox Network page? You may have noticed that it's a master/slave arrangement, so you should keep that in mind. Instead of a X tells Y: 'A' ... Y tells X: 'B' it's more of a: X tells Y: 'A', and asks about stuff, and then Y replies: 'B' You could do this by reading RAM from the slave after writing some...or you could implement your own extension to the MBNet protocol by using the special TOS flags 16...127, where your master can send a payload (bank), and request a payload in response (which button's pushed) ... or you could use a multi-master environment where each core takes turns being the master.... Each has it's benefits and drawbacks. As illy mentioned, the only example in use right now is SIDv2, so I can understand why it's not sinking in right away! Is there anything in particular you want to know? The whole story is a bit long heh. Have you scoped the wikipedia article on CAN and the philips datasheet on it? It helps a lot to understand how CAN itself works. A lot of the hard work is taken care of by the protocol itself (and the hardware support for it in the 4685). You might also find Microchip Appnotes AN738 © and AN853 (ASM) interesting, although keep in mind that they are intended for a different architecture so they may just confuse matters... But maybe they'll help show how the registers are used. Reading the 4685 datasheet is an absolute must, you'll need to get to know what the registers are. If you can memorise them all in less than a few weeks, you're a bigger geek than I :) Once you've done that, have a look at the mbnet.inc file and it might make a bit of sense ... Uhm...what else?

Wow I haven't heard that one before ;D Check out the BLM... nothing bigger is currently planned (doesn't fit with the mbseq design)

Hey dude that panel artwork came out great! Can you tell us about how you did it?

Not any more. I think I made a 256-bit long bitfield recently to test it out :) NSunier I've written a big explanation of structs unions and bitfields in another thread, you should check it out! Just search for those three words in posts made by me, you'll find it. Edit: BTW, if you missed the HLP functions, it's time to read the Function Reference again!

Yerp, them's filters alright!

Patience is a virtue ;)

Yep... free help is given, for making free devices ;) It's cool that you asked tho man, props!

Please refer to The definitive MB-6582 PCB/kit thread

Latching (electronic, as opposed to physical, where the actuator stays put as well) Momentary In the case of the midibox, we use momentary switches, so if you want them latching, then you store the virtual state of the switch (on/off) in a variable, and swap it when the button is pushed in.

Thanks man!!

Errr... Your post is a bit fuzzy on the details.... So you applied -5V to one of the data pins? Maybe you did fry your LCD....

OK let me rephrase my response.. Yes, you can assume that the IC is the problem. But you'd only be assuming, you don't know for sure, cause you didn't test it. how do you know it's not the socket you had it in, or one of the wires it connects to being shorted, or..... Try the downloads page on ucapps ;) Probably. As far as I know, noone else needed to do that to make smash's encoders work. Read the comments in the source files :)

Gummi bears?

http://svnmios.midibox.org/trunk/etc/lkr/ Not sure what you're using as a skeleton?

I think it'd be very unusual to get a batch of dodgy encoders, especially from smash... Unless maybe they were all overheated a bit when soldering... If it was just one, then I'd be blaming the encoders, but chances are, when it's all of them, that there's a short which intermittently causes bad input.