stryd_one

IIC's not a prerequisite for MIOS really, I guess the thing is that it needs '452 compatible instruction set/memory use/etc. 4550 is used in the USB PIC Module ;)

Sweet :) xmas colours too, awwww.

LOL! No that was just a joke :D (see, he made a smiley)

In that case it should be possible to write your driver in a way that allows other devices to share the buss :) Maybe just set a flag to prevent other IIC functions from being called when your device is locking the buss. Nah, they are blocking though. It's not an alternative to IIC MIDI or GLCDs though ;) Point is, if you exclude all of the existing IIC devices, you aren't just excluding banksticks... Any way I don't think that should be an issue. It comes down to a matter of the desired implementation really. You'll only be duplicating existing code if you make your own IIC handler, and the calling overheads are up to you, so personally I would use the existing functions. If you're really worried about losing a couple of cycles now and then to call the mios_iic functions, you can write your own, and you'll need multiple copies of certain things, so you'll be duplicating the code that you duplicated already. It will be marginally faster, but the codespace used will be much larger. Honestly I think that the bigger bottleneck is not calling overheads, but simply the speed of the buss (even at 1mhz) , and the tradeoff would not be worth it. It'll go as fast as the PIC will :) I'm never sure where to put stuff like that :/ I often take a few minutes out to explain stuff like that. I would like to have it on the wiki though - even when I knew it was here, it took me three searches to find it .... Ich bin ein Germanduden. :D You got it!

All that is here, just a few clicks away. It takes a little time to read it all, but it's there. There's also a big overhaul of our wiki documentation underway, to give an end-to-end set of instructions. I think it's more about enabling anyone (even idiots) to teach themselves, and each other. I didn't recognise the box. I did recognise a few features which have been designed by end-users in here, and secretly taken without so much as a thankyou. I think it's cool that you've decided to do the right thing. That auction is a real slap in the face for a few people around here.

Well, did you have the designer and several other knowledgable experts and a few thousand experienced people helping you last time? Extensive documentation? Realtime chat support? In case you can't tell, that's a "YES!" ;) That's why we have troubleshooting guides and applications, if it comes to that. Most of the time, it doesn't, because of the hard work of people like TK and SmashTV and Wilba. That's the same hard work that it's frowned upon to profit from. Unlikely. I think that's only happened to like two people, and only then because they refused to take the advice they were given (ie, they were told "do this, to fix it", and they refused). Occasionally something gets fried, but it's rarely a drama to find the problem and fix it. What is the harm? Well, that would be a question only TK could answer, and so that person should Request his permission to make the Sale, in an appropriate forum, like say, Sale Requests (You are HERE) :D You said you don't see any for sale here, and that's because there aren't any for sale.. with this one unpleasant exception. Really, the only reason to not ask TK's permission, would be if you knew you weren't on the level, and would be denied. Usually, it's encouraged to sell the box here. If this person only wants to sell the box at cost-price, and is happy to sell it on the forum, historically that is the kind of thing TK has given his approval to do. You can find a few examples on the forum here - although there aren't many, because people tend to hold on to these things if they've invested the effort in creating one ;)

Of course, yes :) Several of the apps on the box I'm building at the moment are KDE-based.

Sounds like the right path and good enough English to me :) Happy New Year mate!

Yeh, that's the password I was referring to then.... Just my own opinion, I always give passwords to midibox named stuff, to the admins. You never know what will happen in the future, better to leave the account details with the person who 'owns' the account's name...

Oh yeh, that's easier than banksels :) Thanks! That's right. Essentially my rule of thumb is: 4620 (from smash, to avoid the EUSART bug) or if I need CAN, 4685. That's because some of the extra RAM in the 4685 is reserved for the CAN peripheral, so the 4620 does have a bit more space than it seems. If it's not communicating using IIC, I think this would be a shame... Especially with the theoretical ability to handle lots of fast data, IIC_MIDI modules seem to be in order, so I'd try to keep those free. Personally, I'd be aiming for J10, unless you plan on using this with a SID; or maybe J7, if you don't need more than 8 AINs. Alternatively, you can share pins between your buss (what buss is it anyway?)and others. Usually you only need one extra line, so you can use the touchsensor pin or something else that's rarely used. Yep they'll all act as an input in hi-z mode (TRISx 1) BTW Isn't it convenient that it's 1-nput and 0-utput :) Latch. Check out this post: How pins work It's got a lot of information that will be boring to you, but also has a few specifics that might help... PICList.com is my favourite jump-off for all things PIC.

Agreed... ;; -------------------------------------------------------------------------- ;; FUNCTION: mod_skel ;; DESCRIPTION: mod_skel. does something stupid. Put your code in here instead. ;; Maybe it would be a good idea to put the BANKSELs in there anyway... avoids this confusion... OK it's on my list...

Wow, way to jump right in the deep end... of the pool with sharks in it... with fricken laser beams attached to their heads... and bees in their mouth, and when they bite you, they shoot bees. :D Good stuff!!

Gday mate, I kinda threw that skeleton together, so there would be an example of how the modules interact with the app. There's a matching template application that goes with the module template, to help to demonstrate the way that variables and such can be passed to or from the module. Anything (functions, variables, defines, etc) with the name mod_skel* is just there as a kind of placeholder, so that you can find where you might put your code for a similar use-case. Basically, when you are done writing your driver, do a search for mod_skel in those files, and you should not have any remaining. But I would not say that it is a great example of how to code in ASM ;) In that case, movwf works fine, but it won't always be that way. As you noticed, movwf requires you to set the correct bank, before you use that instruction. Ensuring that is always the case, is up to you (doh!). The upside, is that movwf is a single-cycle instruction. So, if you need to do several sequential movwf instructions, moving data to the same bank, you can save a few cycles by using movwf. However if ensuring the correct bank is used, is difficult, or if you are copying data to several different banks, then movff would be more suitable. In the instruction set summary table in the datasheet, there is a column showing how many cycles each instruction takes to execute. In ther, you'll notice that all the two-word instructions, also take two cycles to execute. I'm assuming that the internals of the PIC only allow for one instruction word to be loaded per-cycle (which makes sense I guess) Hope that helps!

Perrrrty. Hey man, you should put the code on SVN :)

How can I edit the information about the group? Like the "About Midibox" info... perhaps anyone who joins the group instantly gets access to overwrite this info? If so, perhaps it would be better to set a password....

LOL :D I think that needs to be changed, or better yet, removed. That's the third time this week I've had someone think these wires were optional.... I am not aware of any problem if you do solder them... But if you leave them out........ What do you think TK?

If there's a password on that group it'd be nice if you could pass it to TK/Twin-X/SmashTV ;) Better to post the doco (pics are doco too!) onsite, and either resize it first or tag the image to resize them [img=http://www.midibox.org/forum/Themes/Midibox/images/smflogo.gif] [img width = 300]http://www.midibox.org/forum/Themes/Midibox/images/smflogo.gif[/img] [img width=300]http://www.midibox.org/forum/Themes/Midibox/images/smflogo.gif

Good stuff man. I'm sure this will be a useful guide for those who follow you :)

rofl I think you've been spending way too much time with nils and cimo ;)

Bump. Was thinking the same myself :)

Heheh, it was your good timing, I just came in from work - I always read the forums to "switch off" from a hard day ;) Anytime !

I kinda touched on this in your other thread you linked... I've read that the caps have the effect of handling the current individually even though they're in parallel. I guess it makes sense if you consider that the charge is caused by electrons that can't be in two places at once, but of course they are still all influenced by each one's neighbour's potential to flow. Kinda like, one body of water flowing through a pipe, but still individual molecules of water being effected at each point in the pipe. I guess that's also why 'the done thing' is to put the big caps at the big end of town, and then pass the lighter-duty work onto the lighter-duty components later on. Personally, I'm inclined to look at this and go "that's how it's been done for decades, it's probably right" I hope someone can back this voodoo up, or trounce it, with something vaguely scientific ;)

Well firstly I wouldn't wait for my answer on this one... Analog electronics (including PSUs) are not my forte. I just share what I've learned so far, but I'm no expert. As was mentioned in the first post, that design is aimed at audiophile use. TBH, it's probably overkill for a crappy old 8bit analog synth that's well known for being a noisey SOB. But it won't hurt ;) The audiophile factor explains the number of caps there, as yeh, it'll help smooth things out a bit. (also explains the use of the illustrious panasonic blackcaps) I've that n-number-of-caps will smooth better than a single cap of the same total capacitance, because the caps don't all 'pulse' outwards simultaneously, rather, they kinda pass the excess electrons from one cap to the next, each time smoothing it a little bit. Edit: oh, the boxes on the left of the tranny... I'm not sure you're meant to mount them all? F1 is the fuse, that much I'm pretty sure of... If you mounted *only* the 230V 'component' (and *not* the 115V ones), then the two primaries would share 230V in series, which is correct because they're 115V primaries. If you mounted *only* the 115V* "components" (and *not* the 230V one) then the two primaries would be in parallel, which is right for 115V input... I'm thinking that those little boxes are actually meant to represent a mains voltage switch? As LH mentioned, getting the right cap values is a bit voodoo. Sure, there's math to it... if you know the equations please share, because I have no clue ;) I tend to KISS, and just use a well known PSU design that someone smarter than me figured out :D

F0 00 00 7E 40 <ID> 01 00 00 20 00 F7 See here for more info: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=/trunk/doc/mios/mios_sysex_implementation.txt