Duggle

They have nice products! Just ordered a bunch of 40x2's (black on white). I'll post back when I get them up and running.

Well TK, this is amazing! :frantics: Within the performance limitations of sdcard, this adds an awesome amount of potential without using precious RAM. I started this thread with the desire for a sexy, colourful splash of the 64 rgb LEDs on my MIDIbox on startup, and now this! I would like to play phrases with push buttons, to aid with the synth programmer functionality (auditioning while patch editing). I take it that the performance of run-script events is not guaranteed if other EVENTs are triggered? Say I have a run script that plays a phrase, it loops under push button control. Meanwhile, I edit the sound. What is the worst thing that could happen?

Make sure you use an IC socket, because MC33079 (according to my reading of the data sheet) outputs >1.0V above GND at minimum output. This is common with op amps. Thus, I don't think MC33079 will work well. This is why I specified LM324. Don't worry, they're pin compatible, easy to swap.

One more thing: from playing with the speadsheet, it looks as though Vref can be equal to 5V rather than 3.3V. This means one less connection to your PCB. If you do this the position of the trimpot will be a little different and the gain is less by 1 or 2%. Which should be fine, the most important thing setting up this circuit is to make sure the ADC does not saturate, (i.e make sure 0.0V<Vout<3.3V across the range of your modwheel.) Then do final calibration in firmware.

That's good. What software did you use for the simulation? Can you access the spreadsheet and pdf file attachments o.k? (I don't have 2 forum accounts to test it.) [edit] I can now see there have been a number of downloads.

I've just inserted the pictures as "image links", I think this is better than the "My Media" method. Can you access the spreadsheet and pdf file attachments o.k?

I've put the description, info, and example in it'd own thread: (Folly, I've used your case in the examples, so lets us know of your success (or problems) if you try it!)

When interfacing a Joystick, Modwheel or Pitchbender it is sometimes found that the voltage range on the potentiometer output is well inside the range of the Core ADC input. This can often be overcome with digital calibration in the firmware (e.g MIDIbox KB) in some cases there is extreme loss of resolution. Presented here is a circuit to overcome this to give the ADC the full range (in this case 0..3.3V) even though the range of the potentiometer is well inside this. The design process is very easily done following this app note:sloa097.pdf I've done a spreadsheet to make it even easier!Scale Offset.zip If you don't have MS Excel, you can use it with free tools Google Docs, or Open Office. To use the speadsheet you enter numbers into the blue fields. The input range at the top as measured on your pot. In preparing the examples, I played with the value of Rg2 so that Rg2+R1 came close to 10k. This allowed to replace them with a 10k trimpot as in the example circuits. It was just as well, as the trimpot did require some tweaking away from the calculated values, I found. I chose LM324 op amp as it's output goes down very close to 0V. It's maximum possible output with a Vcc=5V is about 3.5V which should be quite safe with a 3.3V Core ADC such as LPC17 MBHP Core. There are 4 op amps in this device, so 4 scaling/offset circuits can be implemented with 1 chip. Here's the circuit with 2 worked examples: Here's the test (input on left, output on right) showing 3 points (Modwheel example): Here's another test (input on left, output on right) showing 3 points (Pitchbender example):

Maybe I should use NG for the KB. However, would this work? ( could add more routings for USB, but it isn't used) ///////////////////////////////////////////////////////////////////////////// // This hook is called when a MIDI package has been received ///////////////////////////////////////////////////////////////////////////// void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package) { // -> MIDI Router //***not using router*** MIDI_ROUTER_Receive(port, midi_package); //***route "hardwired"*** switch( port ) { case UART0: MIOS32_MIDI_SendPackage(UART0, midi_package); break; case UART1: MIOS32_MIDI_SendPackage(UART0, midi_package); MIOS32_MIDI_SendPackage(UART1, midi_package); break; } // -> MIDI Port Handler (used for MIDI monitor function) MIDI_PORT_NotifyMIDIRx(port, midi_package); // forward to MIDI Monitor // SysEx messages have to be filtered for USB0 and UART0 to avoid data corruption // (the SysEx stream would interfere with monitor messages) u8 filter_sysex_message = (port == USB0) || (port == UART0); MIDIMON_Receive(port, midi_package, ms_counter, filter_sysex_message); }

It is possible to scale and offset the signal from your pot wiper to the ADC input with a single opamp and some resistors. There are cheap dual and quad op amps that output down to 0V. You would use +5V for the op amp supply. I guess you would only bother going down this path if *really* like the particular modwheel/pitchbender/joystick and want to make it work with full resolution. I can post more details if there is any interest. (*not advised for total newbies, not too difficult though, if you've built electronic circuits on matrix board before)

Could you give me a hint to permanently route IN1->OUT1 IN2->OUT2 IN2->OUT1 in the code? (I think this should be quick and easy for me) Thanks

Hi, has anyone else the above noticed the above problem, that is the router setting "forgets" between power-ups, although "store" is done? I have an external merger rigged up as a work around. Or has this been fixed already? Thanks

This works great. Keeps things "integrated". Very happy about this feature! Thanks,TK! :smile:

yay! :happy: More good news: it fixed the "LCD Labels value not changing" problem. Thanks TK!

Well it seems the problem lies in my projects default.ngc. It only manifests the problem (not reading the first DINx4 SRs) if my project (sys.ngc renamed to default.ngc) is in the sdcard slot during power up. If it is, then loading a simple button reader script like in post #3 (buttons.ngc) will have the problem. It seems like only a power cycle will restore proper functionality (with another script such as buttons.ngc renamed to default.ngc). When this is done I can manually load sys.ngc and the DIN works o.k (there are still "LCD labels not updating" problems which are probably unrelated). I stress the importance of "power cycle" in reproducing this fault. When trying different scripts I have been tending to load manually, or type "reset" in MIOS Studio. TK, I will email the sys.ngc to you, as it is rather large, then when you can, see if you can reproduce. Basically, if sys.ngc is default.ngc on power up, then the DIN problem persists until you power up with a different default.ngc Note as before, this problem does not manifest on V1.017 and earlier. OMG this has been very confusing! :wacko:

Working now!!!! I am yet to investigate, but I put in a different sdcard, the core then generated a new DEFAULT.NGC, etc, and the default set up is reading the DIN o.k with all versions! :rolleyes: I will first of all copy all the files from the "faulty" sdcard to the new card, then see if the problem comes back, but I'll also zip the files for later inspection. I guess the sdcard and it's contents (other than the *.ncg) was something I have been overlooking.

The same results have been found whether loaded from DEFAULT.NGC or manually loaded from another file after startup.

I have wondered why there are no other reports of this. To try to eliminate variables I am now using a new "virgin" Xpresso with it, in case some wrong value somehow got stored on eeprom or flash, that corrupts it's behaviour somehow. Same result. I should try an STM32 core next... [edit] O.K, I've just tested and it's the same situation with the STM32: Hardware: Core<->DINx4 Script: Just like in post#3 Result: V1.017 works, V1.018 and later *do not work* I'll now have to leave it to others to reproduce the "bug"?

No, V1.017 is the latest that works.V1.018 is the earliest to have this problem. Why does V1.017 respond to "kb" query if keyboard support was added after this?

Yes, both "kb1" and "kb 2" yield din_sr1=0, din_sr2=0. Hang on! I just realised V1.017 is loaded. Flashing V1.018 now..... Same, both zero. It might appear keyboard was added before V1.018?

Unfortunately, I've had to use UART because older versions are not aware of the bootloader setting "single_usb". Hence 4 USB devices appear and those old driver problems make it unusable. The first observation is that under these circumstances (UART MIDI) debug feedback is printed only on loading an ngc not when events are generated? The buttons work in V1.017 (and earlier) but do not work with V1.018 (and later) I tested with all the versions you sent.

Thanks Thorsten, I'll try them later today. It will be very interesting to find out about this. I say this because the buttons did work for brief period, with latest version, but not since.