Jump to content

keves

Members
  • Posts

    33
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by keves

  1. Hi! I hope this is the right place to ask a question: How are the two button rows used, and how does it compare to the original Wilba SEQv4 panel?

    For example, whats the process for switching between different layers (I think that's the correct term? notes/velocity/length/etc)?

    I'm curious about the workflow differences between the Wilba panel and the new one, which by the way looks so amazing!

     

  2. Hello!

    I'm currently in the process of building the awesome Midibox SEQ using Wilba's front panel PCB from SmashTV's shop. I am using an STM32F core board. I have soldered the following on the front panel PCB:

    - All diodes

    - J1 connector

    - All 5 pin resistor networks

    - All IC sockets

    - All pushbuttons

    - Capacitors

     

    I have not soldered ANY of the following:

    - Resistors

    - Rotary encoders

    - LEDs

    - Anything else I am missing?

     

    I have two LCD modules connected to my core board (and they work fine), and the front panel PCB (to J8/9). Pressing any of the buttons does not do anything. 

    Things I have checked:

    - All diodes are in the right orientation

    - All ICs are in their sockets in the right orientation (U1-U6 are the 165, U7/8 are 595)

    - I can see a clock signal on J1 SC pin. I can see VCC and GND.

     

    One important mistake that I made: I initially soldered the J1 connector in the wrong orientation (or the flat cable I used is different than the one that's on the photo instructions thread). This resulted in U1 overheating and may have ruined it or anything else. After discovering this awful mistake I used wire patch cables to connect the core module and the PCB so I am fairly certain they are properly connected now (I can see a clock signal on SC, and measure ~5v between VS and VD). 

     

    Does anyone have an idea of what can be wrong? Here are some theories that I have but not sure if they make sense:

    - I ruined some or all the ICs - thankfully they are socketed so I will just order a bunch of new ones and try that next week.

    - I ruined something else - I doubt that because capacitors, switches and diodes are pretty resilient and I can't see reversed connector being an issue

    - This thing does not work without the LED resistors (I doubt, but maybe I'm wrong? I couldn't find a schema of the board online).

     

    I have access to a 2 channel scope so I can look at signals if someone has an idea of what would be worth checking.

     

    Many thanks!

  3. Hello and thank you for the reply.

     

    I just checked with MIDIbox KB and this isn't happening (I can repeatedly upload it). With my app it fails repeatedly the moment I introduce EEPROM_Init(0).

    Note that I am not doing anything with the EEPROM at the moment other than initializing it. In addition, the rest of my app seems to work (MIDI over USB, DIN/DOUT chain, AINSER are all working as expected).

     

    Any idea what else could cause this? I will start commenting out parts of my code and see if I can narrow it down.

     

    Thanks again,

    Eran 

  4. Made some good progress :smile:

    10420023_10152857369055071_3144345444809

     

    So far I tested this UI module (combination of DIN/DOUT/AINSER) - it works! However the main board support two such modules, and the second one would not work because I mistakenly confused RC(RCLK) signals to be chip selects. New revision would allow to chain the shift registers on the modules by providing a header with the outputs of the DIN/OUT registers that would go back to the main board, and on to the 2nd module. A bit of an inelegant hack, but should work. Haven't tested MIDI ports or LCD yet.

  5. Hello!

     

    Is the MIOS32 JUCE port functional in any way?

    Do people only develop on actual hardware, or is this port or something similar can be used to aid in development?

    The app I will be working on will have LCD and a few pushbuttons and pots - and I feel like developing with some kind of hackish port would speed things up - downloading to an embedded target is slow and annoying.

     

    Thanks!

  6. Hello,

     

    I got my STM32F4 board today, and for reasons beyond my understanding I cannot get any LEDs other than LED1 to light up.

    I am modifying the application template - so my code is as minimalistic as it gets. If I call MIOS32_BOARD_LED_Set(1,1), the green LED turns on.

    MIOS32_BOARD_LED_Set(2,1) or even MIOS32_BOARD_LED_Set(0xF, 1) do nothing.

     

    Some answers to potentially obvious questions:

    1) I am certain I am properly recompiling the code and uploading, as I see the green led no longer lighting up when trying MIOS32_BOARD_LED_Set(2, 1) and lighting up again when I switch to MIOS32_BOARD_LED_Set(0xF, 1).

    2) I tried commenting out the code in the timer function and simply turning the LEDs on in APP_Init()

    3) I am compiling using the following env variables:

    export PATH=$PATH:/Users/eran/Projects/mutebox/gcc-arm-none-eabi-4_7-2013q3/bin
    export MIOS32_PATH=/Users/eran/Projects/mutebox/mios32-svn
    export MIOS32_BIN_PATH=$MIOS_PATH/bin
    export MIOS32_GCC_PREFIX=arm-none-eabi
    export MIOS32_FAMILY=STM32F4xx
    export MIOS32_PROCESSOR=STM32F407VG
    export MIOS32_BOARD=MBHP_CORE_STM32F4
    export MIOS32_LCD=universal
     
    What am I missing?
     
    Thanks!
  7. Maybe I haven't recognized a certain detail, but I don't see the need to modify MIOS32 code or any driver.

    Just use the MIDIbox NG app and you can even use this hardware with an existing firmware without modification.

    My mistake - I wasn't sure there would actually be a need to modify anything.

     

    However, please note that the LEDs and buttons are connected in the wrong order.

    The leftmost LED (B_LED_1) has to be connected to 74HC595 QH7, the next to QH6, etc...

    The leftmost button (B_PB1) has to be connected to 74HC165 A, the next to B, etc...

    Due to my cramped board layout (or lack of layout skills...) my LEDs/buttons are already in a messed up order that made routing easier...

     

    In other words: when you compare with the MBHP_DINX4/DOUTX4 schematics, the LEDs are connected from D7, D6, D5, ... and buttons are connected from D0, D1, D2, ...

     

     

     

    yes, this was a good idea.

    But I'm missing the 10 Ohm resistor between digital and analog ground: http://www.ucapps.de/mbhp/mbhp_ainser8.pdf

    Thanks for the catch! Will add one.

     

    Bad idea, use two ADCs for best results.

    Okay, staying with 2.

     

    Shouldn't happen with the 10 Ohm resistor which acts as some kind of filter.

    As you can see here I even provide a jitter monitor to check this: http://www.ucapps.de/mbhp_ainser8.html

    And the conversion results are very stable, especially when we consider that for your MIDI devices only 7bit are required, and values are jittering at +/- 3 at 12bit resolution ;-)

    Sweet :)

     

    As long as you keep both SPI interfaces (and don't try to handle SRs and AINSERs via a single SPI) it will work without firmware changes.

     

    For the SRIO chain 4 signals are required: SO, SI, SC and RC1 (RC2 isn't required, it's just a duplicated RC1)

    For the AINSER8 chain 5 signals are required: SO, SI, SC, RC1 and RC2

    + 5V and Ground makes 11 pins

     

    However, it's your own decision if you select an incompatible Jxx pinout for your project, or if you take a compatible one and open the possibility for other people to re-use your PCB with a common MBHP_CORE_STM32F4 module.

    I'll revisit the AINSER8 and DIN/DOUT schematics, and try to adapt my pinout to the standard ones. It is my interest to make this reusable by other people.

     

    Just another hint: with MIDIbox NG it would be possible to scan the buttons and LEDs from J10A and J10B instead of using shift registers.

    That wouldn't work in my case since I plan on having 2 of these boards connected to my core module.

     

    This would result into one additional connector, but it would save two SRs

     

    Best Regards, Thorsten.

     

    Thanks for the detailed reply! I'll post back once I make the connector adjustments, and if everything seems correct I'll get on with the main board design. I still have to figure out if this is all going to fit given the physical size limits...

×
×
  • Create New...