TK.

[quote]i ve downloaded the mpasm2gpasm.pl script but i don t really understand what to do with it, not even if it is necessary[/quote] Haha! No, you don't need this script to get gpasm running ;) Installing the GPUTILS package is sufficient, but it seems that the installation wasn't successfull. The message [code]make: gpasm: Command not found[/code] tells you, that the command shell cannot find "gpasm" (which is part of the gputils package) How did you install the package, and could it be, that you overlooked more error or warning messages? Best Regards, Thorsten. [/code]

Is it working now? Best Regards, Thorsten.

I tried it (change in synch behaviour when song mode is active is already available under http://svnmios.midibox.org/trunk/apps/sequencers/midibox_seq_v3/src/seq_core.inc), but faced unexpected conceptional issues with the way how song and phrase mode is implemented. E.g., phrase mode is just "not song" mode. It isn't possible to provide loops within phrases without redefining the user interface. The purpose of phrase mode is to quickly select a set of patterns (and mixer map), but not to run the song sequencer... More relevant is the way, how the sequencer handles song entries. On each transition, it either changes the pattern, or it disables the pattern. There is no possibility to tell the sequencer, that a newly selected pattern shouldn't be touched. This wasn't required in the past, and therefore hasn't been considered in the concept... So, some extensive changes would be required to get your "quick idea" working, which could cost me one or two days - some effort I don't want to spend so long I don't need such a feature by myself. Note that your idea wasn't straightforward, and a (german) "Bastelloesung" anyhow, this just assures my oppinion, that there should be better solutions - still waiting for the perfect idea which only requires two or three extra assembler instructions! ;) Best Regards, Thorsten.

Yes, really great idea! :) Btw: the midibox_sid wiki page is totally outdated, there are a lot of references to MIDIbox SID V1 related pages, and no references to the new stuff. So, it could be confusing for newbies. Best Regards, Thorsten.

When I say "crash", I mean: anything can happen I won't reply anymore before you've fixed the CAN connection. Best Regards, Thorsten.

Yes, of course, otherwise the CAN bus won't work, and the MBSID application could crash. You are using MIDIbox SID V2, and it runs on a PIC18F4685, no? Best Regards, Thorsten.

It's strange that it shows up in the main menu without an entry in CS_MENU_TABLE_L_ROOT - or did you forget to mention this? Maybe the ID values are not matching with the order in CS_MENU_TABLES_L anymore? Best Regards, Thorsten.

Hi Andy, merging MIDI streams is already possible with the integrated router (see http://www.ucapps.de/midibox_seq_manual.html) Best Regards, Thorsten.

So, issue 3a) of http://www.ucapps.de/midibox_sid_manual_ki.html Sinesurfer: just three days ago I warned about the old MIOS Studio version in the 808 forum! ;-) Best Regards, Thorsten.

The voltages are fine, and if you hear the testtone you are almost done :) Maybe it's one of the issues listed here? http://www.ucapps.de/midibox_sid_manual_ki.html It could be related to 3a) 3b) 3c) or 7) Best Regards, Thorsten.

Well, thats the big advantage of the bit-banging method, because you can copy the MIOS_IIC* routines into your application, (rename the functions and variables to avoid label collisions), and assign different pins to SDA and SCL See also the source code http://svnmios.midibox.org/trunk/mios/mios_iic.inc You will notice, that the code is very small, biggest part of the file is the documentation ;) The number of IIC busses is only limited by the number of free pins - the integrated peripheral doesn't provide such a flexibility (thats another reason why I ommited it...) Best Regards, Thorsten.

It isn't really an CPU architectural issue, it's more a side effect caused by the way how GPIO SFRs are handled. The same issue exists for 8051 derivatives with single-cycle execution, and so far I remember also for AVRs. It doesn't exist in microcontrollers which insert wait cycles during a read access, or which handle masked RMW operations internally in the GPIO stage. It's one of the first things you will notice when toggling a pin as fast as possible with "bsf/bcf" instructions - the pin won't toggle due to the FF at the input stage. You have to insert a NOP (or a more useful instruction) between bsf/bcf --- or you have to write into LATx instead of PORTx (if available) However, modern controllers always provide a seperate IN and OUT register for GPIOs :) Best Regards, Thorsten.

. o O ( und schon wieder ein MBSEQ Anwender mit diesem Problem ) Danke fuer den Input! Somit scheint Seppoman's Vorschlag wohl wirklich weiterzuhelfen :) Gruss, Thorsten.

Clever!!! Gruss, Thorsten.

I re-created the group, therefore it's probably working now :) Best Regards, Thorsten.

Fortunately not - the menu handling doesn't require navigation buttons. Pages are selected directly via ALT+<gp button> and EDIT/SONG/PATTERN/MUTE buttons Best Regards, Thorsten.

See also: http://svnmios.midibox.org/trunk/apps/sequencers/midibox_seq_v3/src/j5_dout.inc (which can be optimized, yes... it's quite old. And it's better to use PROD[LH] as temporary registers than MIOS_PARAMETER[12]) The official j5_dout module will get a C wrapper, similar to this module: http://svnmios.midibox.org/trunk/modules/iic_midi So that it can be used by asm and C programs.... Best Regards, Thorsten.

But the MIOS based IIC access methods are working very stable since years, why should the internal peripheral work better? There are several reasons, why I'm not using it (also historic reasons...) - one reason is, that the I2C pins can change between PIC derivatives, and mostly allocated by other useful functions. So, I don't see any reason,w hy using the înternal SPI! Best Regards, Thorsten.

Using the bitbanging method was a design decition, which cannot be changed anymore. However, why do you need multi master support? Best Regards, Thorsten.

Thats strange, because according to your "user permissions" overview, you should be able to reply. Does anybody notice similar issues in the past? Best Regards, Thorsten.

The first beta version can be downloaded from the bottom of this page (press refresh button of your browser if you don't see the .zip package): http://www.ucapps.de/midibox808.html It's already working quite stable, and I had some fun with it. You *must* try out this: - press&hold EDIT button - select LC/MC/HC tracks - change to random page with ALT+GP button 12 - press one of the GP buttons to generate random patterns until it sounds nice - change to progression page with ALT+GP button 7 - press GP button 5 (Fwd: 5) and 11 (JBack: 3) - enjoy the sequence, and don't forget to switch between A and B section MIDIbox SEQ V3 users who want to evaluate the firmware can upload the setup_808_mbseqv3_hardware.hex firmware. The default pattern setup outputs MIDI events at Channel #10 (General MIDI drum map is used) Please read the warning about Mixer BankSticks if your one isn't connected to CS2! Best Regards, Thorsten.

Theoretically this is possible by switching the four data lines of the SRIO chain (RC/SC/DI/DO, Vss and Vdd can be shared between the core modules), because they are "hot-pluggable". So, you could use the same encoders, buttons and LEDs for both cores. Sharing a LCD is not so easy, on the other hand you could left it out for MB808, or you could connect a small 2x16 LCD to the MB808 core (which makes sense for people who prefer a direct visual feedback when handling menu pages - like me) Best Regards, Thorsten.

Due to this "power-up behaviour", it could make sense to handle the error flags (FERR and OERR) correctly - once integrated into your small test loop, check again if RCIF is still flagged after RCREG readout. FERR: whenever set, it should be cleared by software OERR: whenever set, disable the receiver with CREN=0, thereafter enable it again (CREN=1). Overrun errors should be notified somehow by your program, e.g. a LED could lit - very useful for debugging. Best Regards, Thorsten.

Btw.: it wasn't the first time where you mixed Tx with Rx, see also the TRISC initialisation: // 10001110 (C7 = TX input, C6 = RX output, C<5,4> outputs, C<3,1> inputs, C0 output) TRISC = 0x8E; [/code] RC7 is the Rx input, and not Tx output (however, the TRISC configuration itself is ok) My statement "SN75176 is powered by the Tx line" was wrong, and therefore confusing. I overlooked the connection to Vdd. The schematic is very hard to read on my screen! :-( Btw.: a pull-device doesn't make much sense on an output pin. ;) You are writing, that Rx is low when no transmitter is connected to the bus. But the required idle level of Rx is high! A low level will be detected as a start bit, and if it is permanently low, the UART will receive multiple bytes with frame error (FERR flag set) due to the missing stop bit. RCIF will be set as well in such cases, this matches with your observations? If this doesn't make sense to you, just have a look into the PIC datasheet, e.g. search for the "Asynchronous transmission" diagram (figure number depends on datasheet version, it is figure 16-2 of DS39564B) Since it isn't clear to me, if your schematic and/or descriptions about observations are complete and correct, I will stop speculations and wait for an answer ;) Best Regards, Thorsten. P.S.: please doublecheck, if the Rx terminal is connected to pin RC7 of the PIC, and not RC6