Midibox LC with core32 (tiny) questions

[djamon]

Hi everyone !!

This is my first topic, so I hope I'm in the right section :ahappy:

So, as written in this topic title, I'm planning to build a MBLC with a core32. I have a few skills in electronics (and much more in programming), and I love DIY concepts. But despite I've been hanging around this forum/wiki and http://www.ucapps.de for a while (few weeks/months) and have done a lot of reading, a final question still remains (it may not be the last). In fact it is because i'm planning a core32 instead of the very well documented core8 based MBLC.

You could tell me to build my MBLC with a core8, but, in the future, i'm planning to build an additional LC extension on the same core (but it would the 2nd midiport), I'm confident in my programming skills to adpat the MBLC program by myself, but it will be the 2nd phase. For now, I'm just trying to build a cor32 single MBLC.

So my question is (snare roll...) :

- About the touch sensors of motor faders : the connection diagram pdf (here) shows that they have to be connected to the core8 J14 pin through 4 x 47kOhm resistors, it also says that 10 kOhm resistors must not be soldered on the DIN board. What about connecting those sensors to the core32 ? core8 J14 pin hasn't any (visible) equivalent ? how to connect touch sensors on the core 32 ?

Thanks in advance for any answer !

(Hope I have not miss an old post that explains this...)

Bye !!!

[TK.]

Hi,

the touchsensors are currently (*drumroll*) the big blocking point for me - I don't want to release a MIOS32 based MBLC without this feature, on the other hand I still haven't found an acceptable solution to control touchsensors from a STM32 on a reliable and not CPU time consuming way. :-/

Best Regards, Thorsten.

[djamon]

Hi TK !

Thanks for your response, I understand now why I could not find any info about this point :tongue: .

I read the forum article where you describe how sensors works, and I guess that if I want those to work properly on a core32, I would have to design an additional circuit that would :

- substitute the J14 pin, by supplying some periodic square signal to charge the capacitance (pfffiou, many questions : is it possible to get a regular pulse signal from the core to synchronize this external periodic square one, etc.), AND

- detect the capacitance change if a button is pressed.

To minimize cpu-load, from the core and DINx point of vue, each touch sensors would act as a regular pushbutton.

I think my current electronics skills are not good enough for now. But I need to refresh some old memories, ten years ago I think I was able to design this... Let's put it aside for now (I'll wait for my single MBLC plus its extension to be finished).

Thanks again (further questions or design validation may come later :ahappy:)

[TK.]

Yes, an additional circuit would help. The most simple solution (for me) would be to outsource the task on a PIC16F88, and to access the results via IIC.

But for users this would mean that a PIC burner is required to program the (minimal) firmware into the PIC (update via MIDI not possible), therefore I'm still hoping for a more elegant solution.

Best Regards, Thorsten.

[Screaming_Rabbit]

Why not use qt1080 with 8 sense lines for direct, discrete connection to DIN (€4.2 @ farnell)

... or AT42QT2160 (€3 @ farnell) which has I2C and 16 sense lines multiplexed. Since they are sensed multiplexed, I don't know about how easy they are to tune (specially when connected "far" apart from each other according to fader spacing).

Greets, Roger

[djamon]

Why not use qt1080 with 8 sense lines for direct, discrete connection to DIN (€4.2 @ farnell)

... or AT42QT2160 (€3 @ farnell) which has I2C and 16 sense lines multiplexed. Since they are sensed multiplexed, I don't know about how easy they are to tune (specially when connected "far" apart from each other according to fader spacing).

Greets, Roger

Hi Roger !

Thanks for your response. And yes, despite I think I won't "resolve" this issue for now, I spent some time hanging around on Farnell website and I also found the chip you mentionned. And, it looks like very powerfull, maybe too much (as I say in my mother language : "It would be like shooting a fly with a Bazooka" :rolleyes: ) it could be a kind of solution. But in my own opinion, this chip is a PCB one, and, firstly I don't think I will make my own PCB for it (nor ask someone to make it for me), secondly I don't think I'm able to solder this correctly (too small for my fat fingers :sweat: ).

I was thinking about another solution, quite similar to the core8 one as describe in this topic :

- Use an 555 timer IC (0.34 €/unit) in monostable mode (see wikipedia description):

- It would act as the J14 pin of the core8.

- It would be synchronized with the DINx4 clock signal

- Need additionnal resistors, capacitors, and maybe OPAMPs (very cheap too) to invert trigger signal or in comparator mode, etc.

But I don't know if a decent synchronisation can be obtained from the serial clock of DINx4 bus.

And in this way It could react as in the core8. TK do think it can be a reliable solution ?? :tongue:

Edited March 22, 2010 by djamon

[TK.]

Roger's proposed solution is attractive, because it doesn't require a PIC programmer. On the other hand using a small PIC16F88 would be better for those DIY people who prefer easy to handle DIL packages.

Djamon: your proposal to use a "discrete circuit" sounds simple, but it's much more complex (and therefore more error prone) than using other solutions I had in mind.

E.g., instead of a NE555 timer, I could simply use a timer output pin of STM32 to generate a pulse. By using a transistor it could be easily converted to 5V in push-pull mode.

The pulse has to be generated before DIN inputs will be captured.

This backup solution will allocate some resources of the STM32, such as one GPIO pin and a timer. It will require some SRIO driver changes (pulse has to be triggered before DIN values are captured, implementation should be completely interrupt driven), and it will be difficult to identify a GPIO pin which isn't used yet (at least by MBLC), and can be controlled by a timer peripheral which isn't used yet and won't be used by future enhancements.

This backup solution will require some conceptional work at my side, for which I don't have the time yet (project overflow).

Using a PIC16F88 would be a solution where I could already say today, that it will perfectly work without conflicts. Therefore this is the only solution today where I could say: yes, I can do it this way without much effort (especially since I've enough spare PICs)

Best Regards, Thorsten.

[djamon]

Hi TK !

Thanks for taking time to answer our questions. I won't go any further about this subject for now. Let's have a functionnal midibox first :) !

Greets, Dja'

[ssp]

thorsten.

is it possible to have the 32 mblc released without the touch feature please? i dont really use touch anyway, and im not using motor faders at the moment on mine, i just want to use the slimline 100mm panasonic faders i have got that i used in my mb-mmc unit.

also in a previous conversation with phil we discussed that the mblc 32 would take 16 faders, has that been implemented into the 32 version of mblc as well yet or is it a section of code to be edited? i was wondering as it would require more lcd display space, unless a 40x4 was used or a graphical unit.

thanks

[TK.]

I would have to spend some time to reach the state that you and some other people requested:

• 1 day: adding option for 16 instead of 8 faders (probably requires to open a second USB MIDI port and to make the SysEx handler multi port capable - I cannot give you exact instructions what exactly has to be edited, but many changes at different places have to be expected)
  
• 1 day: adding configuration possibility w/o the need to recompile the firmware, e.g. config options stored in a .txt file on a SD Card
  
• 2 days: providing the possibility to store the configuration in internal flash instead of SD Card + appr. SysEx transfer tool. Note that this option will be required for your usecase, as a SD Card has to be connected to J16, but this port is already allocated for fader #13..16
  
• 1 day: support for 2 CLCDs instead of a 240x64 GLCD
  
• 1 day: support for even more CLCDs instead of GLCD
  
• 2 days: find perfect solution for touchsensors
  
• 1 day: testing under MacOS and Windows before release to avoid time consuming troubleshooting sessions at your side
  
• 2 day: writing documentation to avoid confusion at your side
  

I don't think that I can spend such efforts before July/August, since there are so many other interesting projects in the queue. :)

If you are happy with the current state of the MBLC application, you could use it as it is - it works fine at my side :)

But this would require that you recompile the firmware by yourself anyhow, accordingly a release is not required. Just download the current code from the SVN server and install the MIOS32 toolchain.

Best Regards, Thorsten.

[findbuddha]

TK, is there any update to this situation?

If I were to be ordering from SmashTV shortly, would it be safe to get a Core8 for this purpose? I assume this would be overkill, but a safe option.

Thanks :)