Jump to content

Move aout_ng from lpc17 to STM32F4


jbdiver
 Share

Recommended Posts

I built a new STM32F4 core board this last week with the intention of replacing the existing lpc17 core in my MBSEQ4. I'm slowly moving components over to the new core and testing as I go -- wilba front panel, TPD, etc. I'd like to move my aout_ng module over to the new core, but I'm not certain how to hook it up. I'm using a custom board on my current setup to connect the aout_ng to the core, and also to pull gate and clock signals. This custom board is connected to J5A, J5B, J19, and J28 on the LPC17 core. I can see that the first three ports are available on the STM32F4 board, but J28 is not. How should I be connecting to the new STM32F4 board?

Edited by jbdiver
Link to comment
Share on other sites

I was trying to figure out what J28 was used for last night. It's been almost 2 years since I created this aout interface board+eurorack module and and I couldn't remember all the details. :) I think I'm using that port for clock and start/stop signals. Does J10a/b provide these same signals? I guess I can try to plug in the board in see what happens.

Link to comment
Share on other sites

Here's what I see in the config file:

- DIN sync clock will be forwarded to J5C:A0 (LPC17: J28.SDA)
# - DIN sync start/stop will be forwarded to J5C:A1 (LPC17: J28.SC)

I am pulling the DIN sync clock and start/stop signals off of J28 on my LPC17 core. The J5C port referenced in the config file is for a CORE_STM32 board. Are these signals forwarded to J10A/B on the latest STM32F4 core? I can't seem to find them using my scope. 

Edited by jbdiver
Link to comment
Share on other sites

Not sure. On the Midibox CV 2 page at the Din Sync header it says:  TODO: add interconnection diagram. But considering the other text:  The signals are switching between 0V and 5V level, and should be protected with a serial 220 Ohm resistor (already part of the MBHP_DOUT module) i think you are not supposed to attach directly to an exposed IO pin anymore because it's not protected.

 

Maybe TK can answer this?

Link to comment
Share on other sites

I found the signals. The key to hunting these down was looking at this code block and using a scope to probe the pins on the STM32F4 ports:

#elif defined(MIOS32_FAMILY_STM32F4xx)
      // pin J5.A6 and J5.A7 used as gates
      for(i=6; i<8; ++i) {
        MIOS32_BOARD_J5_PinInit(i, pin_mode);
        MIOS32_BOARD_J5_PinSet(i, 0);
      }
      // and J10B for additional outputs
      for(i=8; i<16; ++i) {
        MIOS32_BOARD_J10_PinInit(i, pin_mode);
        MIOS32_BOARD_J10_PinSet(i, 0);
      }

The DIN clock is at pin 7 on J10B and the start/stop signal is at pin 8 on J10B. I also had to find the 7th and 8th gate signals because these changed as well. The 7th and 8th gates are located at J5B pin 4 and pin 2 respectively. 

Now, the question is how do I adjust to this change. My aout interface board was designed around the LPC17. It mostly still works except for the four signals above, which have all moved to a new location on the STM32F4 board. I could redesign my interface board, but that's a PITA. 

Perhaps I will just solder in some jumpers on my current interface board to match the new pinout. 

 

Edited by jbdiver
Link to comment
Share on other sites

20 hours ago, Shuriken said:

 But considering the other text:  The signals are switching between 0V and 5V level, and should be protected with a serial 220 Ohm resistor (already part of the MBHP_DOUT module) i think you are not supposed to attach directly to an exposed IO pin anymore because it's not protected.

I'm connecting to the IO pins on the core board through a custom interface board that utilizes a set of 75hc541 buffers and resistors. I adapted someone else's design that was published and discussed on the board, so I think I'm connecting to these pins properly.

Link to comment
Share on other sites

The usage of these IO pins is not recommended for new MIDIbox SEQ builds, therefore you won't find information about this legacy option at my website (this should also avoid 

In future, DOUT based outputs should be used. They have many advantages (especially the scaleability: e.g. we've 8 individual clock outs with separate clock dividers)

Best Regards, Thorsten. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...