audiocommander

hehe... must be I'm a bit goofy today, don't take me too serious ;)

ROFL ;D (sorry, I couldn't resist)... ps: I really hope this is not going to be the basis of the 21st century's pointing devices ...although I got to admit it's a nice DIY idea :) Edit: ROFL even more ;D This man needs soap. Is he dirty? What does he do with that? Scratching or Pitching? Or Vibrato-ing?

Edit: the following is an answer to a posting that has been removed ;) sorry to deny that: 1st: MIDI is in fact a serial protocol, just another baud rate. There's nothing you can transmit by serial data that you couldn't also transmit by MIDI. 2nd: You are free to stuff your Core with an LTC Module that provides a COM interface! 3rd: If you're talking of better communications, I don't understand why you are referring to stoneage COM ports: Bluetooth would be interesting, but the thing is: it's also serial ;D 4th: MIDI != Music. Noone sais you must only produce sounds when a Note_ON signal is received. It's totally up to you what your robots does! 5th: You're not really wanting to say that Midi is too slow, aren't you? I mean where when not within music would that be a problem? ??? And: I think that the communication possibilities really don't matter for robotics that normally are built to function independently without any connection to a PC. The only thing that counts are good I/O possibilities (and MBHP is superb in that!), good programming possibilities (MIOS is great and C is one of the best languages a robot programmer can get). And if you ever tried to program a robot by graphical UI based software or script based specialized firmwares (think of time-critical stuff!) you'll probably know what I mean. So I cannot see any of your arguments. :-* Regards, Michael

the syx-code you posted is simply the representation of the sysex file of "mios_v1_9c_pic18f452.syx" Just to make sure: You got the bootloader v1.2 burnt onto a PIC18F452, right? If your Core PCB is from SmashTV: is the chip also from SmashTV? Because you mentioned you burned the bootloader by yourself? If you burned it yourself: with what MBHP-module have you burned the bootloader (JDM/MBHP-Burner...) and what software have you used – and were there any errors? Have you checked if the loader got burned right? (via compare-functions?) Best regards, Michael ps: do you have another PIC available to swap and test? Maybe you damaged some part of the PIC while you were trying to burn MIOS? Don't know though if this is possible, just guessing...

Sounds like henrygr is absolutely right about the power supply ;) IMHO 500 mA at 7.5 V is much too less. I've experienced startup problems with 800 mA and 7 V, though 800 mA and 9 V is working great. I'd get a good stabilized power supply. They aren't expensive. I got mine from Conrad (10 EUR, small size, stabilized) and Pollin (4 EUR, but a bit larger). I'd watch out for 800 mA power supplies minimum. Cheers, Michael

haha! I knew I would find that link again: http://www.eecs.tufts.edu/~dsculley/RCX/ I hope this helps ;) Cheers, Michael ps: storing my bookmarks on my own sitebar server. Pretty cool if you have more than one browser/computer :D

Hey stryd, your feedback is very welcome :) What I need is no *nix guru, but some experienced know-how about ASM, Linker-Scripts and Makefiles. I remember your PIC18F620 tutorials and the talks about >256 byte arrays that require linker-adaptions... you know, when I'm looking at the linker script, my eyes pop out and all I see is numbers . And up to now, all readings I've done could not light up my personal brain darkness in this area ;D Up to now I tried <updated>: PIC18F-based apps: - bootloader: okay* - midimon_v2_0: okay* - mios_v1_9c_src: okay* - midibox_fm_v1_1: okay* (some warnings may occur) PIC16F-based apps: - midimerger_v1.4: not okay* - mbhp_iic_speakjet_v1_0: not okay** - mbhp_iic_midi_v1_0: not okay** * macro conversion with perl-script ** no macro conversion needed I'm not yet totally clueless, but shortly before :) see my last experiment with the mbhp_iic_midi below; I just generated the makefile with mkmk.pl and compiled the unaltered sources without errormessages with gpasm... the result is attached... Cheers, Michael Edit: added test results for ASM based midimon & midimerger apps. The good thing however is, that my perl-script seems to work sofar 8) Edit2: added FM, changed MIOS_v1_9c results, split into PIC16 & 18 results... gets a lot clearer now...

Hi Antimon, What about my suggestions? http://www.midibox.org/forum/index.php?topic=8201.msg57394#msg57394 I believe you should check the software first... Michael Edit: IMHO that means your hardware seems to be okay!

Hey, as the name of this topic is not really matching, I allowed myself to open a new topic: http://www.midibox.org/forum/index.php?topic=8275.0 I posted the download link to a first version of a perl script there. It works with the bootloader! @nhaudio: you are welcome to try the script, although it's just a rough first test... because the script is actually overwriting files, please backup the original sources before applying the script...

Hello everyone, The information about this issue is a bit cluttered, so I start a new thread about it. My aim and the reason for this posting is: I want to achive full *nix compatibility and be able to change and compile ASM based applications (like the SpeakJet PIC16F Firmware) without windows. As you might know, one cannot compile MIOS sourcecodes (and also ASM based applications) with GPASM. Only MPASM can do the job without errors, but the cause of this is quite simple: The problem is an instruction parameter passing in the Macros defined in "macros.h" http://www.midibox.org/forum/index.php?topic=8175.msg57319#msg57319 As this bash script using sed is obviously not working on macs (don't know the reason though, seems I'm too dumb to read regular Expressions...), I wrote a perl script, that you can download here: http://www.audiocommander.de/downloads/midibox/mpasm2gpasm.tgz (4kb) It's my first perl script ever, so don't expect poetry and elegance... The thing is however: - I tested it with the bootloader src and it works fine, can compile it & the hex is the same the original hex-file. - I haven't tested it with the MIOS src, because I don't know how to setup a linker script to generate a Makefile for gputils As some of you might have read in the speakJet thread, I have massive problems to compile the SJ firmware for the PIC16F. The generated .hex-file is different from .hex files compiled on Win-PCs. So I guess this is another incompatibility issue between MPLAB and GPUtils. Because I checked the bootloader .hex and it is not different from the original bootloader .hex, I can roule out gpasm as the error... so the linker comes to my view. I'm going to interspect that and report back, if someone likes to try the perl-script or has a nice link for me about GPUtils and Linkers, I'd be happy for feedbacks... Cheers, Michael Related Links: Wiki: How to compile MIOS on linux: http://www.midibox.org/dokuwiki/doku.php?id=compiling_the_midibox_source_on_linux Compile on Linux please: http://www.midibox.org/forum/index.php?topic=6420.0 Assembler SID Help: http://www.midibox.org/forum/index.php?topic=8175.30 Speakjet (hex file mismatch, unresolved): http://www.midibox.org/forum/index.php?topic=2870.msg54723#msg54723

As I'm the reason you deleted the other thread :-[ , I just got the window open and think it may be of use to post the old informations:

Hey antimon, don't worry, I'm just being practical :) Now the first and most important thing is: don't panic, you are most likely to find the errors if you stay logical: I really do not understand what you are trying to do? the "burner" is the MBHP burner module and you "burn" the bootloader. You cannot send the bootloader by Midi. If you get that 2 sec poll, it means that the bootloader is already on the chip. Please look at this schematic: There are plenty of topics here that illustrate that basic concept, think of it like a Computer: (BIOS -> Windows -> Word) ... okay? To me that sounds like a problem with MIOSStudio and not your hardware. Now forget your burner, and think about the next logical step: finding out where the error is (I mean get the location of the error by testings) : - Check if you made the right midi-connections inside MIOSStudio (you have to draw connections beween the IN and OUT port! - Connect something else to your Midi-Out-Port, virtual or real, does not matter: a simple synth or anything – and use the Keyboard of MIOSStudio to see if you can get anything out of MIOSStudio. If the suggestions above still don't work, you got to check if it's MIOSStudio, so: - Try if you can upload MIOS with another program (eg. MidiOX, search the forum for upload procedures and see the advanced description) If that does not work, you should follow the Midi Debug section at ucapps. Best regards, Michael

I think the MIDI support/focus is one of the great advantages of MBHP! Why? Because the need for device drivers sucks – regarding the "problem" of different operating systems. This way you just need a midi-device (which most of us have anyway!) and you're done! There are much more *nix-Systems around here than one would expect at the first sight :) Cheers, Michael

There are two more topics that might be of interest for you, if you're not sure how to access pin within your program : http://www.midibox.org/forum/index.php?topic=6208.msg43831#msg43831 and http://www.midibox.org/forum/index.php?topic=6754.msg43142#msg43142 best regards, Michael

oh, cool :) I missed that... nice one stryd :D

Hi Jidis, here's a pin listing, it sounds as it's exactly what you're searching for :) http://www.ucapps.de/mios/mios_pin_list.txt Best regards, Michael

you're welcome ;) have a good year, too! Cheers, Michael

Hi Gert, I bought them for 3 EUR at farnell, but I think there may be cheaper distributors. However, I uploaded a video experimenting with the QT301 that is a capacity to PWM IC. One can see that it's not exactly what I would call a slow response ;) best regards, Michael

I see! Thanks a lot for pointing me to that, mess! Now I got the root of all evil, the problem is the instruction passing as parameter: [tt] BIFSET MACRO reg, bit, reg_a, instr btfsc reg, bit, reg_a instr ENDM [/tt] the macros have to be rewritten like this: [tt] BIFSET MACRO reg, bit, reg_a btfsc reg, bit, reg_a ENDM [/tt] and a typical call to this macro would now be: [tt] IFNEQ BYTE_NUMBER, ACCESS, rgoto MainLoop_WaitSequence ;; should become IFNEQ BYTE_NUMBER, ACCESS rgoto MainLoop_WaitSequence [/tt] Now there's only one thing that I don't understand: what advantage does one get by passing the instruction ??? it does not reduce typing or anything. The only thing it does is to prevent compilation with GPASM. I tested it and compiled successfully with the bootloader source. The generated .hex file is the same as the ready-compiled one. No differences :D Cheers, Michael

Maybe I asked my question unclear, but my interest has mainly been the microKORG; I just wondered because the MX has not been there and now it seems I was right about it. I don't like auctions that end before they're over :( I would have submitted my bid if the roules would have been clear.

Hi, I know about Arduino for some time now, I never tested it, but I think it's quite nice; prices for kits and assembled boards are very good (~20 EUR). The tiny arduino board may be also quite useful. The downside is, that it has no origin MIDI-support and uses its own language and software (based on processing). I don't know if it's possible to develop more complex programs on this thing... and somehow I got mixed feelings about it; maybe it's because I started programming with Macromedia Director/LINGO and I learned some years ago, that it makes no sense for me to put all my effords into such a specialized custom language and software environment. Just my 2c though... I haven't found no advantage until now, that would have made me think about switching from MBHP to Arduino :) best regards, Michael

yes. Just look at the pin names printed on the boards and compare to the pin names printed on the Core and see on the backside where the traces go. best regards, Michael

Hi japanesepotato, and welcome to the mb-forums :) You have not mentioned what application you like to use for your project, but I assume it will be the Midibox64/e, right? Then the answer can be found on the mb64/e page: http://www.ucapps.de/mbhp/mbhp_midibox64e.gif Have you seen SmashTVs PCB-overview pages? They are excellent (just like his PCBs ;) ) I expect you also have a DIN from him, so check out this page: http://www.avishowtech.com/mbhp/mbhp_dinR4.html and the core: http://www.avishowtech.com/mbhp/mbhp_coreR4d.html and here is the overview: http://www.avishowtech.com/mbhp/info.html You can simply roll over the first 3-D image and it tells you what's below your mouse-cursor. Best regards, Michael

Hi, noch ein kleiner allgemeingültiger Tipp zu den LEDs, ich kann mir das nämlich auch nie merken mit den langen und kurzen Beinchen: wenn du ein Multimeter hast (was man unbedingt haben muss!), dann solltest da auch ein Prüfmodus drin sein, meistens mit einem Schall oder Diodenzeichen versehen. Das piepst einfach, wenn Strom geleitet wird. Nachdem eine LED eine Diode ist und den Strom nur in eine Richtung durchlässt, kannst du einfach das rote und schwarze Kabel an die Beinchen halten, wenn's piept ist's richtig so (rot = plus), wenn nicht, dann andersrum ;D Gruß, Michael