EUSART Bug still there?

[fabb]

Hi there! I'm new to this forum, hello to all!

I read about the EUSART Bug and wondered if it's still existing for newer PICs.

Does someone know about 18F4523, 4525, 4553, 4620 and 4685?

Thanks!

fabb

[audiocommander]

Hi

and welcome to te forum :)

Yes, the 4620 still has the bug, 4685 most probably not, therefor the 4685 might become the new default.

Dunno about the others...

Best,

Michael

[fabb]

Thanks for the fast reply!

What do you mean by 'most probably not'? Did you try it out or do you know someone who did?

I don't want to use an I²C interface for midi comm cause I need the pins for SPI communication with a higher-resolution ADC. It sure wouldn't be a problem to switch to a better PIC later on but I thought I'll ask you wise guys first!

thanks

fabb

[stryd_one]

4685 is OK for EUSART, but those other PICs are unsupported so that's your guess ;)

What's the story with the ADC? I'm curious :) Do you plan to use the hardware SPI or bitbang it?

[fabb]

Oh, bitbanging is ok, I did this between the MAX1271 and an embedded Linux once, not that hard. Sure I'd prefer a more convenient solution. I saw that the MIOS C-Interface has got I²C functions embedded. I'll try to find an ADC (in a PDIP package...) which supports I²C.

What we want to do is to interface eg. a ribbon controller or a multistage poti. And I've still got this two-axe gyroscope sensor lying around... 10bit is not enough, we want to go to ~14 bit and up. There would be PICs with 12 bit ADCs (but half sampling speed), the 4523 and the 4553, but is seems they're not supportet. So an external solution has to be found.

Thanks guys, so the 4685 is the way to go. Maybe CAN can be used (Yeah we can can can, yeah we can can can! --Moulin Rouge)

fabb

[stryd_one]

The only thing you might run into trouble with is that there's a good chance your embedded linux had a lot more ram and processing power, but that shouldn't stop you at all :)

You sending pitchbend or RPNs or sysex? Given that the messages required to send 14b data are not so fast, I wouldn't worry about sampling rate... Even half-rate will be sampling far more frequently than you can send it. What's receiving the messages and what will it do with them? Why is 10b not enough? Reason I ask is that there may be a better solution, who knows :)

Although SPI is certainly do-able, I think that if you are able to find an I2C ADC that will be far more easily implemented, as you noticed MIOS has I2C support built in. CAN would probably be overkill.

[fabb]

Yeah, I thought so too that CAN would be an overkill... Just did it for the pun :)

I will send normal all-purpose CCs. When you send an extended CC consisting of MSB and LSB you actually send two CCs, one with MSB and one with LSB. I'm sure you already know this. So I thought, why not sending 3 CCs for one value? As I don't care about standard-CCs, I could use e.g. CC11, 12 and 13 to define one value (3*7bit=21bit).

We're trying to interface FL Studio which internally has a controller 'bitrate' of 16 bit! As FL doesn't support LSB AFAIK, we just would use a Formular Controller in FL to add the 3 CCs according to their valency (by which we have splitted them before on the external MIOS controller).

I was concerned of the half sampling rate because I think MIOS has been optimized for the normal one, and porting MIOS to these PICS won't be easy then (when it hasn't been done yet).

I still wonder if 18F4553 would be possible as it has got USB and a 12bit ADC too. But probably this project would be too hard for the beginning. It's my first PIC project, you know. Probably the Windows driver wouldn't be the problem as XP as got general purpose USB MIDI interface drivers. But one after another! Tomorrow I finish my PIC burner (Brenner 5 from Sprut) which I have started 2 years ago in school but never finished and then lets go and try to burn my first PICs!

greetz

fabb

[stryd_one]

If you want to send 3 bytes you might be better off using sysex, it'll end up being 5 bytes not 6... Not a big difference though.

I'm pretty sure FL supports 7bit controllers too, could save you a lot of effort! :)

[fabb]

I'm pretty sure FL supports 7bit controllers too, could save you a lot of effort! :)

Yeah, sure FL supports normal MIDI CCs which are 7bit but we want more accuracy. But AFAIK it doesn't support the LSB stuff. But that's ok, it takes only ~1-2 minutes to setup a Formular Controller in FL which adds two or three CCs to one value which can be used anywhere internally. FL doesn't support sysexmessages, that's why the workaround. And I don't want to use a software translator between FL and the controller.

If we were just for 7bit controllers we would go out and buy a Behringer BCR-2000. But we want at least a bit (haha) more accuracy!

fabb

[stryd_one]

But we want at least a bit (haha) more accuracy!

Heh, I'll try one more time... What for?

[seppoman]

Maybe this is interesting for you: http://www.atmel.com/dyn/resources/prod_documents/doc8003.pdf

when looking at midi transmission speed and having only few channels, oversampling might be sufficient for your needs.

Seppoman

[fabb]

Heh, I'll try one more time... What for?

We eg. want to change a wavetable-position or other such fine things per MIDI for which 128 values are too bold. We have not yet decided what exact input componets we will use. I'm not sure how fine we can get with a normal poti (and how big quantization errors are at 5V or when electron noise becomes a problem).

[fabb]

Maybe this is interesting for you: http://www.atmel.com/dyn/resources/prod_documents/doc8003.pdf

when looking at midi transmission speed and having only few channels, oversampling might be sufficient for your needs.

Seppoman

Interesting tip, thanks sepp! From the doc: "However another criteria for a successful enhancement of the resolution is that the input signal has to vary when sampled." I wonder if enough noise will be present in the measured signal as adding artificial noise seems to be more work then adding an external ADC. But maybe I'm wrong with this!

fabb

[stryd_one]

eg. want to change a wavetable-position

You'd probably want a slider for that, have you considered the infinium faders? They go up to 256 steps, I don't know if that's enough or not.... You seem to be a bit cagey with the information, or maybe you're not sure yet?

or other such fine things per MIDI for which 128 values are too bold

Heh, yeh, I got that bit the first three times ;D But as you can see with the one example above, the right answer needs the right question... You've said only half the question.. the more you tell us the more specific help we can give. If you tell me why you need more than 7bit and what for and how much you do need etc, then I can be more helpful...

Also, seeing as you'll be bitbanging the SPI, then you can leave the IIC pins which are assigned to the MIOS functions in place and use other pins for your SPI, so that will open up your options too, you can use 452, 4620, 4685 :) It is possible to recompile MIOS with different pin assignments for it's IIC functions, as they are bitbanged also, but I wouldn't recommend that.

[fabb]

You seem to be a bit cagey with the information, or maybe you're not sure yet?

Cagey... Curiosity kills, you know ;)

Just not sure yet! :-* And tired of 7bit messages... It's not meant for one specific application but a flexible controller for FL Studio which is capable of 16bit precision.

Also, seeing as you'll be bitbanging the SPI, then you can leave the IIC pins which are assigned to the MIOS functions in place and use other pins for your SPI, so that will open up your options too[...]

Good idea, but I look out for an IIC ADC first.

You'd probably want a slider for that, have you considered the infinium faders? They go up to 256 steps, I don't know if that's enough or not....

Yeah, the Infinium faders look nice! Not too cheap, unfortunately... And I'd have to bitbang again. But I still have the C sources of the last bitbang experience.

It is possible to recompile MIOS with different pin assignments for it's IIC functions, as they are bitbanged also, but I wouldn't recommend that.

But don't these PICs support IIC natively?? Why are they bitbanged in MIOS then?

[seppoman]

Interesting tip, thanks sepp! From the doc: "However another criteria for a successful enhancement of the resolution is that the input signal has to vary when sampled." I wonder if enough noise will be present in the measured signal as adding artificial noise seems to be more work then adding an external ADC. But maybe I'm wrong with this!

Well, I have to admit I never tried this myself. From logic thinking, I´d say if e.g. the fader is exactly inbetween two LSB values, the AD result would flicker between the higher and the lower value. So when interpolating to 11 bits, you might get a stable inbetween value even while the signal is not changing. Interpolation can easily use e.g. 5 or 7 measurements before getting into trouble with MIDI speed as long as there are only a few of them.

I´m not sure though if a resolution beyond 10 bits is really useful for your purpose - I mean, even with a 100 mm fader, 10 bits is about 0.1 mm per LSB value! I´d say that it would be hard to set the fader position purposefully to a position that is in between of two 10 bit steps. And you also have to take into account that in a typical DIY controller box, you have some wire lenghts, imperfect shielding, electromagnetic interference, slight VCC ripple etc. So even when using a 12 or 14 bit converter it might be difficult to get better and stable measurements than 10 bits. There must be a reason that most microcontroller manufacturers put 10 bits ADs into their designs, and also DAW controllers like Mackie Control use 10 bits. If you want to get better than that, you´d need:

- very clean conditioned supply power

- very good PCB design (grounding issues, interference/shielding issues, short distances, separated analog and digital grounds...)

- a very good external voltage reference - the usual internal references of ADCs/DACs are not precise enough to facilitate reproducible sub-mV measurements

- ...

So looking at both extensive design considerations and the difficulty of precisely setting a fader to positions more exact than 0.1 mm, I´d recommend just using the internal ADC with full 10 bit resolution, maybe interpolated to 11 bits, and sending these values as NRPNs.

Seppoman

[fabb]

Hmmmm, sounds not too good.

You're true about the faders, but we would go with a multistage poti (which has got several layers, is not endless, but ends after 1080 degrees or so.

Yes, the power supply could be a problem. I'd say I'll go with the internal 10 bit first and then see how we could expand it and how necessary it would be.

Don't forget, there are some PICs which have got an internal ADC with 12 bit accuracy!

fabb

[stryd_one]

Hmmmm, sounds not too good.

That'll be the part where the light bulb over your head sparks up, right :)

It's not meant for one specific application but a flexible controller for FL Studio which is capable of 16bit precision.

As you are beginning to see it's not always so simple as that ;) Aside from the technical implications which seppo has mentioned, there are practical limitations, such as the 0.1mm LSB which Seppo mentioned. Not a lot of point in having 16bit message resolution, and 10bit finger/controller resolution  ;)

You're true about the faders, but we would go with a multistage poti (which has got several layers, is not endless, but ends after 1080 degrees or so.

Then you'd end up doing many turns to get where you want. Imagine it with a soft takeover function, you could do several turns of your hand in the time taken to reach the takeover point, you might as well just punch in the number you want with a keypad... Imagine it without soft takeover, you'd change patches or whatever and then you'd have to mangle your sound for 2 or three seconds while you turn the pot to where you want it.

You'd probably be better off using an encoder with a customised acceleration function. Or coarse/fine controls. Or a keypad. or........ etc etc. Point is:

What control will be most suitable, will really depend on what it is controlling. If you're unsure what it'll be controlling, then you are designing a solution for a problem which doesn't exist yet, and what you'll essentially have is a very interesting and well thought out paperweight ;)

Even with the example you gave of setting wavetable positions, I can think of several good control methods, but which one is most suitable, would really depend on exactly how you use the wavetables. It's a tricky subject.

But don't these PICs support IIC natively?? Why are they bitbanged in MIOS then?

Because TK did it that way ;) I have a few theories but I don't honestly know heh

I'd say I'll go with the internal 10 bit first and then see how we could expand it and how necessary it would be.

You're not the first to take this path, and so far I don't believe anyone has seen the need for additional bit depth once they're tried it.... YMMV but I think you'll find that 10b is good enough for the vast majority of cases. and if not... Hey it's easy to try an upgrade later!