Jump to content

yogi

Members
  • Posts

    218
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by yogi

  1. Hi,

    Yes, that setup file sets the options for mapping CS controls to firmware routines, within limits. So rearranging LEDs, buttons and encoders connections is a matter of changing this file and compiling. To add new features would require adding to the main source. If you look at this file closely, you'll see a section for the build options of MB6582 or sammichSID; these flags are for the re-arranged CS of these projects. They use SR IO matrices for all control elements. As opposed to the 1 to 1, SR I or O pin to a CS Element as you do with the standard build.

    Like all the synth projects, most everything can be controlled over midi with CC and SysEx messages without changing the code. The most min system would be a Core and a SID board, this is playable via midi. With a min CS (step B), synth prams can be changed through the menu layers. The Full (step C) CS allows less button pushing, having a dedicated controls or displays for most of the synth sections. The MB6852 or sammichSID just improve on the full CS by minimizing shift regs. Even though there is code for a specific control or LED the synth will work if it's not attached.

    From the MB6582 Wiki

    Quote

    You don't have to use the DIN/DOUT at the bottom of the PCB, and you don't have to use the optimized switch/LED matrix I designed to get a “step C” control surface with only 8 shift registers, and you don't have to use a “step C” control surface (or any control surface). However, TK has kindly done all the code changes to support the optimized switch/LED matrix so you can have a big control surface with only the shift registers on this PCB.

    . So you could use the base board, without the bottom SRs, and a min CS connected to the first core's J8/9 and I think just the stock FW on the cores ( each with a different ID). If anyone can confirm?

    Yogi

     

  2. 17 hours ago, hyperr said:

    Thanks again for your response yogi.

    Just got back from the shop with a new cable, and that's fixed it. With all my experience... you should always start by replacing the easy parts first!

    Oh well, I guess I'll have a spare board now (ordered it last night in case)!

    Cheers!

    Having a spare STM32 is a good thing, lots of  uses :) Glad it was only the cable,

    Yogi

  3. Congrats on your SID synth!

    The MB6582 is basically 4 cores and 8 SID boards copied to a single PCB. The cores are networked and the code for the cores is slightly different then the stock app. If you can poke around in the code, could change the FP options to your own needs and build the FP as you please. Don't know if you have any programming experience but it's not too hard and there is plenty of info on the wiki.

    There is a new MB board supplier They are carrying the main board for $24.99, http://modularaddict.com/manufacturer/midibox  

    So using the main board saves you alot over modules. Without the interconnecting.

    There are a few threads here on the PSU and the MB6582 is flexible for setting up the power supplies.

    Good luck,

    Yogi

     

  4. So after many months and a little testing I ran into a problem with the build, hex upload doesn't work right. But it seems to be a general Linux issue. The issue is already reported in this thread,

    And a work around

    Midi In/Out and File browser works fine; haven't tested any other tools.  Still to test the Hex upload work around so time will tell.

    Yogi

    EDIT: Tested upload with work around, direct entry of file path works fine. Yea!

     

  5. Hi urtzurd,

    Well, for options A and B J73 should be bridged to route +5V from an external PSU; and for Option C J73 is can be used to route to/from the on board +5V regulator. So for all options the J73 footprint is used, just in very different ways depending on how you plan to supply power. I think that on the parts list, it is saying that the use of a header is mainly needed for option C, as A and B only needs a wire bridge. Of course one could use a header and a shunt for A and B, OR not use a header for C and solder jumper wire directly to the solder pads.

    There are so many options to supply the board that it can be confusing but with a little study of the schema and reading the forums it will make some sense.

    Yogi

  6. I can't say that Notepad++ is the best way to work on projects; and if you want to dive into a proper IDE, Eclipse would be my first choice. In Npp you can trace a var to a point, you just have to setup the search. Eclipse would help with organizing your project and auto completion is handy, so getting to know it can speed your coding but it's not going to tell you if your logic is wrong. For this you would need a simulator or ICE tool so you can step through code and see the effect on memory or registers. I think STM does have tools but never looked. I'm a "code; compile; crash; repeat" guy :)

    Yogi

  7. OK, so that kind of leaves the changes you made. mios32_config.h is where the boot string is defined, it gets displayed till the app changes the output to the LCD. Not familiar with NG and when it rewrites the LCD.

     What I usually do is make a copy of a project and place it in a new folder in my MIOS32 directory, alongside the trunk folder. This way I have the original code in 'trunk' and my changed code in the other folder. From then on, I run Make in the edit folder and this produces the new hex in this folder. From MIOS Studio I then upload this hex. I haven't worked on the NG scr but the process has worked well for what I have been working on.

    Check that MIOS Studio is pointing to your build. If that is correct then review the changes you made and try only the boot string for a start. The only other thing I can think of is on a few occasions I have made changes to a scr file and run Make, BUT forgot to save my scr changes back to disk. Of course Make built a hex but based on the old scr!  So ' Edit, Save and then Make'. I'm using Notepad++ with the 'NppExe' plugin.

    Yogi

  8. Generally you would just need to upload the new hex to the core and it should display the changed text when it boots. I've never known what the release.sh is for, I assumed it was for IDE use. Have you uploaded the pre-compiled hex to make sure the defaults works? I'm not sure about NG, do you have an SD card attached? It may be hanging without a card, but I don't know for sure.

    Yogi

  9. 21 hours ago, jaytee said:

    Ok, took it out of the breadboard, soldered everything up, double checked my connections, fired it up....nothing. U solder some wires to try out 4-bit mode, nothing. But at least now it's a consistent nothing rather than constantly changing gibberish, which indicates to me that the breadboard *was* an issue, just not the only issue.

     

    So the "nothing" I'm getting is two full lines of completely blacked out characters. Contrast knob does nothing. Backlight turns on fine, but as before, brightness knob does nothing. Checked the input voltages and they come out to 5V as expected. Not sure where else to start checking.

    any ideas?

     

    edit: just found the LCD connection test app. trying it now...

    double edit: I ran the app, everything checked out, felt *really* stumped, then realized I've have it connected backwards the entire time somehow, even though I double and triple checked before hooking it up every single time. WTF.

    As I was reading your posts , first thought was 'it's connected backwards' - because I have done the same thing and puzzled for days why the contrast didn't work :) Glad you got it straightened out!

    About the Brightness, it could be that the LCD doesn't respond to any current changes, I have a blue display that works this way. Other LCDs plugged in work fine but that one just has fixed brightest. I would say to not mess with the bias circuit till you can try a different LCD, I wasted time doing the same thing only to find out is was the display.

    Yogi

    EDIT: the Bright bias circuit only adjusts the current level, the line will always be at +5V. If you really want to test, you'll need to attach a load, R about 1K would be OK, and have your meter inline set to mAs. Don't know the range of the circuit but assume it's only about 10 mA.

    OR you could try a LED across the pins B+ & B-, should see it dim/brighten

     

  10. 37 minutes ago, tffshtt said:

    @yogi

    Great to hear you're having a good time with it! I think it is a super fun synth and pretty much unbeatable on the price / size side of things.  I thought goom was moog spelled backwards too, but Mark (goom creator) said it was "it's just a rip-off of the theme music from a 1970s BBC TV programme written by Derek Goom."  Awesome to hear about the boards!
     

    hahaha OK but will always be gooM to my eyes now :)

  11. Good to know there is no special handling for the source. Currently my system's EVs are setup for 'F4 builds.

    Quote

    I haven't looked too much into the firmware, but the button assignments for the "SRIO" version are done with "m" for the matrix. To use an old CS board with an STM32F4 Core, you might have to go through and tweak the pin assignments -- could be possible!

    Might have a go at it, but a lot of my programming time, ATM, is spent on messing with the Goom synth code. So kind of think for the moment the best choice is to finish up the LPC build (as ugly as it is). 

    Quote

    You could do it like this, of course you'd need a way to break out the MIDI and a method of mounting the DISCO board (no mounting holes -- custom acrylic case with the pins straight on the plastic??!! Scrap piece of perfboard? Also, the logic is only 3V, so you may run into trouble running the LEDs

    True about the +5V rail, overlooked that but still a minor addition to a 'simple core board' on perf with just the headers needed for the Seq4Lite. The 'Lite lends itself to the Eurorack dimensions, which I've been leaning towards lately. Not so much for a pure analog system (as much as I'd like that) but a casing system to consolidate smaller projects and get away from lots of small case building. 

    Quote

    I had one builder tell me he writes on the full V4 and transfers to the V4L for live performances. So already there's a possibility of avoiding redundancy. :) The cost of the V4L is probably around $100 all up, the full is quite a bit more. I don't have any info on the Wilba version's availability, nor smashTV's plans for it. My work is still under development, but it's coming together. As long as Tim chooses to continue selling, you'll have the option of either project.

    Sorry, I was kind of rambling, was trying to say I'm reluctant to buy supplies and parts for a second Seq Lite because would like to also have a full Seq along with a Lite. My LPC build is more than halfway done and money already spent so my practical side votes for finishing what I started. I just got frustrated with my choice of perfboard. Could have saved myself some effort also by not building ALL the headers; as it's stands now, I've wired most of the headers that AREN'T used for the 'Lite :P

    Anyway, looking forward to your full Seq boards, not that the Wilba board is bad, just that your modular design seems more flexible for laying out a front panel. 

    Yogi

     

  12. Thanks, mainly interested in an 'F4 build. I have the STM tool chain setup so can/will build here. Another 'dumb' question, aside from my system's Env Var "MIOS32_Processor", shouldn't have to make any changes to the Makefile or the source for an 'F4? Or do I have to complete this section in Make:

    # (following source stubs not relevant for Cortex M3 derivatives)
    THUMB_AS_SOURCE =
    ARM_SOURCE      =
    ARM_AS_SOURCE   =

    I have the older CS board, but your board is wired different, so a new SW build (for a 'F4) may not work with the older layout? The pre-built bin, on the DL page, for the Seq4 Lite is based on an older Seq4 version, so I guess that the newer sources on the SVN only supports your newer layout.

    Got the original SEQ4Lite board ages ago (and  an LPCXpesso) but put it aside for a long time. Finally got around to it  last year and big surprise, LPC core boards are long gone. Had a go at wiring the LPC 'core board' but then got frustrated with the perfboard (single sided) I was using, so it went back into a box ( worst is, I didn't use sockets for the LPC headers; SO... would have to de-solder half the pins to start again with better perf board ).

    Well, I guess I can either start again with new Core/CS/parts or 'man up' and finish my hand wired LPC build on the cr@p board :(  I really like your version, very clean layout. The single cable interconnection is great and for this app, don't really need a full 'F4 core board; just the J8/9, SD and midi headers. Have to think about this, really would like to build a full Seq4 but Smash has been 'out of stock'  on the Wilba board for a long time; aren't you working on a new board set? Guessing he may be holding off  till your boards are ready. So kind of want to not spend on replacing stuff I already bought and save my budget for the 'full monty'.

    Yogi

     

  13. I believe the only impact of the split is adding two propagation delays on each of the midi Outs. For 'HC logic it's about 10 nS for each gate but I would have to check the datasheet to be exact.

    Of course as Ilmenator noted, you will see more timing impact with the traffic/bandwidth on a interface. But I'm not sure you would be able to send two notes on different channels at the same time from a single source. I mean, it could happen if you were merging two midi devices onto one interface, but with just a Seq sending to an interface, UART or USB, it should always be one package at a time regardless of channel. OTOH the GM5 may have more trouble with processing two, three... USB streams in parallel, leading to one UART out of sync with another UART. I've never seen this but I've yet to load a GM5 to this extreme :)

    Yogi

×
×
  • Create New...