Looking for help with uC / MIDI

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

toolstudio

New member
Joined
Jan 28, 2009
Messages
2
Hi,

I hope I find somebody who could help me with a uC/PIC solution.

For a project I need a code for a uC/PIC which does:

When a sequenzer is in play (MMC) it should make a pin HI (5V) if the
sequenzer is in stop it should be LO (0V) and another PIN which inverts.

If there is somebody who could help me with a solution please EMail me to:
[email protected] to discuss further.

If this is in the wrong forum please move.

Thanks in advance,

wolfgang

 
toolstudio said:
Hi,

I hope I find somebody who could help me with a uC/PIC solution.

For a project I need a code for a uC/PIC which does:

When a sequenzer is in play (MMC) it should make a pin HI (5V) if the
sequenzer is in stop it should be LO (0V) and another PIN which inverts.

I'd rather eat glass than use a PIC for anything. But having said that:

I don't think there's a specific MIDI message or other indication that a sequencer is running. Perhaps you have to monitor a specific MIDI channel and an absence of messages in a certain time indicates that the sequencer is not running.

-a
 
The low cost modern PIC are 3.3V process, while older ones, and some more expensive newer ones (like DSPic)  are still 5V. You can generally interface with 5V logic using open drain and resistor pull up, but some times edges are marginal for critical timing.

They have a lot of canned applications and contacts through their website. While these are generally just modules, You still need to connect the dots.

I'd stay away from the older PICs, and maybe the newer ones too if starting from a blank page.

YMMV

JR
 
Andy, John,

Do you mind me asking why you feel that way about PIC?

I have been using them for 12 years now and without any problem. And I have a friend whom is a serious PIC developer and he has been designing serious applications with it.

 
sahib said:
Andy, John,

Do you mind me asking why you feel that way about PIC?

Well, I'm an 8051 partisan, having used them for over a dozen years, so shoot me.  OK, not old-skool original Intel 8051s, but we use the Silicon Labs variants a whole bunch and they work well. And we love the built-in JTAG emulator and tons of flash. Remember the Nohau bond-out emulators and how the pods would die at the worst possible time?

But seriously: the PIC instruction set is wacky and features like general-purpose registers and memory are sorely lacking unless you get into the big parts. You wanna program in C? Forget it. Stack? LOL! Interrupts? OMG, where's the context?

I suppose if you're working in the most cost-constrained market then the cheap PIC is a contender.

And a lot of processor choice is simply inertia: you have the tools and you figure out all of the quirks, so it's easier to reuse what you know than to use something else.

-a
 
Andy Peters said:
Well, I'm an 8051 partisan, having used them for over a dozen years, so shoot me.

So I guess I'm not the only one ;)

I love the huge range of 8051 chips you can get - from small cheap ones to large, fast and complex types. And the code you wrote for the cheap chip works without changes on the big ones as well...

Best regards,

Mikkel C. Simonsen
 
When a sequenzer is in play (MMC) it should make a pin HI (5V) if the
sequenzer is in stop it should be LO (0V) and another PIN which inverts.

What you're saying is that you want some sort of "auto-talkback" - e.g. muting TB and RTB when "tape is running" like in the good old days?

A simple non-computer solution is to have a separate audio-track running along, using that to gate the needed signals.

But I agree - a simple PIC that detects "tape is running" would be very nice to have around. MMC will work quite often, but you may want to add detection of MTC (miditimecode) in order to be more universal. I'm trying to persuade a friend of mine to write this program, but no luck yet..

Jakob E.
 
It should be for a redlight for voice over recordings.

The program may also be paid a bit, as we need this..

wolfgang
 
Andy Peters said:
I'd rather eat glass than use a PIC for anything. But having said that:

I don't think there's a specific MIDI message or other indication that a sequencer is running. Perhaps you have to monitor a specific MIDI channel and an absence of messages in a certain time indicates that the sequencer is not running.

How about MIDI clock?

Regarding the microcontrollers TI's MSP430 series look nice to me, I've just started learning using them. You have the free mspgcc tools (tip: google mspgcc), and there's the cheap MSP430F2013 USB dongle starter kit available.

Seems this little project does the MMC thing:
http://little-scale.blogspot.com/2008/07/how-to-build-midi-clock-to-game-boy.html

Here's a hardware project that does the same:

http://www.hollis.co.uk/john/sync24.jpg
http://www.hollis.co.uk/john/circuits.html (scroll down to the MIDI to Sync24 Convertor)

Have you tried the Philip Rees MDS, it's also got the flashing LED?
http://www.philrees.co.uk/products/sync-if.htm
(not manufactured anymore)

or the Doepfer MSY2:
http://www.thomann.de/fi/doepfer_msy2.htm

 
sahib said:
Andy, John,

Do you mind me asking why you feel that way about PIC?

I have been using them for 12 years now and without any problem. And I have a friend whom is a serious PIC developer and he has been designing serious applications with it.

I'm self taught, and have been coding on PICs for maybe 5-6 years.  I am still forced to wrestle with the 8 bit proc used in my first generation tuner, until I use up that inventory, and move on to a newer part.

I did a more recent Peak/VU meter design using a newer PIC (16b) family and have kicked the tires, but not completed a finished design on their DSPic platform. The instruction set, registers, and architecture of the newer 16b PIC is pretty similar to their DSP, while lacking some of the DSP specific instructions. While I have a few complaints about the documentation and web support, I found the newer PIC platforms a pleasure to work on. Especially compared to the older PIC. I do not have experience with coding other processor families but can imagine the criticism about the PIC in the context of the early stuff as well founded. While some of this is just favoring the family you learned on.

While I only work at machine level, there are C compilers available for even the old PIC and the architecture looks like it supports the kind of tricks a C compiler would use. In fact I bought the C compiler for the old PIC when I started out since I had taken a night school course in C programming years earlier, not to mention writing tons of BASIC in the '70's, and even a little Fortran in the '60s. But when I started to familiarize myself with the C functions, I found the machine language descriptions of how they worked far easier to follow. I will probably use PIC again in the future since like Andy mentioned, I am well along on the PIC learning curve. Like I joke privately the scars on my ass form a Microchip logo.

FWIW I am in the middle of trying to code some pretty hairy tricks on the old processor platform and I am constantly reminded of the limitations. Having only one working register, requires swapping a list of variables into and out of that one register for crunching. Very (clock) time consuming, to the point I had to use the internal PLL feature to step my clock up 4x to get enough ticks inside my primary interrupt to take care of business. There are still features of that old PIC I never got working and if it wasn't for the debugging environment, I wouldn't have figured out as much as I have.

The last time I tried to use their website support was when I was first bringing up the Pk/VU meter design. After several days with no answer to my simple (after I figured out the answer) question, I informed the web contact of my solution I had figured out myself using trial and error. He then parroted my answer back to me, as if he had helped me.  Arghhhh.

I really like (most) of the chip design, but I find the documentation annoying. This may be because I am self taught without a handy mentor to ask stupid questions. The descriptions of the instruction set seems almost an after though, written by experienced engineers that don't know what I don't know. I have to use the debugging environment sometimes to figure out obscure instructions.

This may be a personal problem, but I am now hooked on digital processing. I can do stuff that would be impossible using analog technology. I will do a full review of feature sets before locking in my next project but the PICs seem competitive.   

My advice to someone starting out from scratch is that the different platforms all seem similar in power/features, so pick the more popular platform to make it easier to get local support. I bought stock in the Microchip company, so I believe in the parts, and should probably be more of a pimp for them.

JR


 
 
hobiesound said:
if someone wants a simple uC to start with they should check out the arduino at www.arduino.cc

Arduino would be a LOT more useful if they bothered to bring out the debug pin.

I'll mention Silicon Labs again -- their 8051s are great, and you can get a eval board kit for $99 for most of their variants. And the biggest bonus? All parts have onboard debug/programming AND the debug dongle is included in those eval kits, or available separately for $40. Which is what, two orders of magnitude cheaper than Nohau!

Last time I looked, the Atmel debug ICE thing was fairly expensive for a hobby thing.

-a
 
Back when I was an analog puke working at peavey the 8051 was popular with the digital lads... maybe that's why I didn't use it.  ;D

I recall one particularly difficult time I had back then, trying to get a 6511AQ prototype PCB up and running (software and circuit designed out of house) for a project I was managing. I went to the digital group and begged for help (my ego didn't like that). After a couple hours, the digital boys gave up and said I was on my own. I finally got it running myself (my ego liked that part), but this analog boy was sweating bullets. I had to add some gate propagation delays to get the external memory to read and boot up.

To this day I really prefer the modern processors with everything including a kitchen sink built in... much harder to screw up critical timing (but still possible).

JR
 
Great to get to hear past experiences. I suppose the success of Microchip is that they brought their products down to even a hobby level. At some point I was doing a feasibility study on a high precision robot arm controller in 16 bit operation and played with a Mitsubishi chip that came with a development board. It was a great chip but we found it to be pretty specialist to work with. Also you did not get a choice of compilers and the one at that time existed was very expensive.
 
JohnRoberts said:
To this day I really prefer the modern processors with everything including a kitchen sink built in...

That describes the modern 8051s quite accurately :)

Built-in ADC, DAC, PWM, I2C, SPI, USART etc. What more do you want?

Best regards,

Mikkel C. Simonsen
 
JohnRoberts said:
Back when I was an analog puke working at peavey the 8051 was popular with the digital lads... maybe that's why I didn't use it.  ;D

Well, I won't say the 8051 is without flaws. It has its quirks, and dealing with the 256-byte internal SFR/RAM space, half of which has to be addressed indirectly, can be just weird. And remembering which bytes are bit-addressable and which aren't can be annoying. But the compiler hides most of that, though the wise embedded guy understands the architecture (it ain't a PC!).

I recall one particularly difficult time I had back then, trying to get a 6511AQ prototype PCB up and running (software and circuit designed out of house) for a project I was managing. I went to the digital group and begged for help (my ego didn't like that). After a couple hours, the digital boys gave up and said I was on my own. I finally got it running myself (my ego liked that part), but this analog boy was sweating bullets. I had to add some gate propagation delays to get the external memory to read and boot up.

That board should've been kicked back to the contractor who designed it. There's no excuse for failure to do a proper worst-case timing analysis. (Ignore the data sheet sections that indicate "typical" and "best-case" data. That data are irrelevant.)

Anyways, shouldn't the board have booted before the contractor shipped it to you?

-a
 
My first intro into microcontrollers was with the 16F84 PIC way back in college.  I can see that a lot of more experienced people probably see the 16F PIC's as a bit toy-like in comparison with the more serious uC's, but for simple tasks on a budget you can't go past them IMO.

I've done a couple of MIDI projects with the 16F84 and the (slightly less pissy) 16F873.  A few years back I made a MIDI floor controller/rack switcher using these chips, and they're still going strong today.  The F84 doesn't have a UART so I had to "bit bang" the code to do the serial MIDI data transmission.
 
Andy Peters said:
That board should've been kicked back to the contractor who designed it. There's no excuse for failure to do a proper worst-case timing analysis. (Ignore the data sheet sections that indicate "typical" and "best-case" data. That data are irrelevant.)

Anyways, shouldn't the board have booted before the contractor shipped it to you?

-a

I won't name names because this guy who designed it was pretty well known (and is also dead now RIP). Several times I wanted to kill him myself. I got stuck with this project, that he presented to the company as a done deal (for a royalty), we just had to build it, and they would come. He designed the schematic, we laid out the PCB and built it... I came damn close to sending it to him to make it work that day but IIRC I was under some time pressure. I got zero support from our in house digital group after the initial tire kick. This was competition for them and they were happy to see it/me crash and burn. So the buck stopped with me... So far (knock wood) I have been pretty good about figuring stuff out when I have to, but it can get a little stressful. 

Getting it running was only the beginning, this project was a black hole for time and resources... His software was so buggy it was embarrassing. If I knew then what I know now he would have been dead years sooner. Long ugly story... don't bother.

JR

 

Latest posts

Back
Top