This N°9

cocerning bitshift, I only found this in the SDCC-manual:

here it is: this@this-laptop:~$ sdcc -v SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.7.0 #4 818 (Jan 18 2008) (UNIX) this one I already tried, makes no difference. I'dont exactly know where notify is called, but I think it's from a timer - callback, not from the main-loop? This could make the difference. could be. I'll study the sdcc-manual once more, there are specials about passing parameters to functions etc. I could imagine that bit-shifts have special things to take are about too. ok, i start with the current, woking version: ; ; Starting pCode block S_main__preset_store code _preset_store: ; .line 162; main.c void preset_store(unsigned char num) __wparam{ MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x00, POSTDEC1 MOVFF r0x01, POSTDEC1 MOVFF r0x02, POSTDEC1 MOVFF r0x03, POSTDEC1 MOVFF r0x04, POSTDEC1 MOVWF r0x00 ; .line 163; main.c unsigned int addr = num; CLRF r0x01 ; .line 164; main.c addr <<= 6; RRCF r0x01, F RRCF r0x00, F RRCF r0x01, F RRCF r0x00, F RRCF r0x01, W ANDLW 0xc0 XORWF r0x00, W XORWF r0x00, F XORWF r0x00, W MOVWF r0x01 ; .line 165; main.c MIOS_BANKSTICK_WritePage(addr, current_preset); MOVLW HIGH(_current_preset) MOVWF r0x03 MOVLW LOW(_current_preset) MOVWF r0x02 MOVLW 0x80 MOVWF r0x04 MOVF r0x04, W MOVWF POSTDEC1 MOVF r0x03, W MOVWF POSTDEC1 MOVF r0x02, W MOVWF POSTDEC1 MOVF r0x01, W MOVWF POSTDEC1 MOVF r0x00, W CALL _MIOS_BANKSTICK_WritePage MOVLW 0x04 ADDWF FSR1L, F MOVFF PREINC1, r0x04 MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN your first proposition (Debug - Output: num==6 -> addr==64): NOT working: ; ; Starting pCode block S_main__preset_store code _preset_store: ; .line 170; main.c void preset_store(unsigned char num) __wparam{ MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x00, POSTDEC1 MOVFF r0x01, POSTDEC1 MOVFF r0x02, POSTDEC1 MOVFF r0x03, POSTDEC1 MOVFF r0x04, POSTDEC1 MOVWF r0x00 ; .line 171; main.c unsigned int addr = (((unsigned int)num) << 6); // parentheses added here CLRF r0x01 RRCF r0x01, W MOVWF r0x03 RRCF r0x02, W MOVWF r0x02 RRCF r0x03, F RRCF r0x02, F RRCF r0x03, W ANDLW 0xc0 XORWF r0x02, W XORWF r0x02, F XORWF r0x02, W MOVWF r0x03 ; .line 177; main.c MIOS_BANKSTICK_WritePage(addr, current_preset); MOVLW HIGH(_current_preset) MOVWF r0x01 MOVLW LOW(_current_preset) MOVWF r0x00 MOVLW 0x80 MOVWF r0x04 MOVF r0x04, W MOVWF POSTDEC1 MOVF r0x01, W MOVWF POSTDEC1 MOVF r0x00, W MOVWF POSTDEC1 MOVF r0x03, W MOVWF POSTDEC1 MOVF r0x02, W CALL _MIOS_BANKSTICK_WritePage MOVLW 0x04 ADDWF FSR1L, F MOVFF PREINC1, r0x04 MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN your second proposition (Debug - Output: num==6 -> addr==348): this one works only if I have the debug code uncommented (!). the funny thing is, that the debug output is correct too. If the shift would appear after passing the value, this would not be the case. so this one WORKS: ; ; Starting pCode block S_main__preset_store code _preset_store: ; .line 170; main.c void preset_store(unsigned char num) __wparam{ MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x00, POSTDEC1 MOVFF r0x01, POSTDEC1 MOVFF r0x02, POSTDEC1 MOVFF r0x03, POSTDEC1 MOVFF r0x04, POSTDEC1 MOVWF r0x00 ; .line 171; main.c unsigned int addr = ((unsigned char)num); MOVFF r0x00, r0x01 CLRF r0x02 ; .line 172; main.c MIOS_LCD_Clear(); CALL _MIOS_LCD_Clear ; .line 173; main.c MIOS_LCD_CursorSet(0); MOVLW 0x00 CALL _MIOS_LCD_CursorSet ; .line 174; main.c MIOS_LCD_PrintBCD2(num); MOVF r0x00, W CALL _MIOS_LCD_PrintBCD2 ; .line 175; main.c MIOS_LCD_PrintCString(" - "); MOVLW UPPER(__str_0) MOVWF POSTDEC1 MOVLW HIGH(__str_0) MOVWF POSTDEC1 MOVLW LOW(__str_0) CALL _MIOS_LCD_PrintCString MOVLW 0x02 ADDWF FSR1L, F ; .line 176; main.c MIOS_LCD_PrintBCD5((addr << 6));// parentheses here RRCF r0x02, W MOVWF r0x03 RRCF r0x00, W MOVWF r0x00 RRCF r0x03, F RRCF r0x00, F RRCF r0x03, W ANDLW 0xc0 XORWF r0x00, W XORWF r0x00, F XORWF r0x00, W MOVWF r0x03 MOVF r0x03, W MOVWF POSTDEC1 MOVF r0x00, W CALL _MIOS_LCD_PrintBCD5 INCF FSR1L, F ; .line 177; main.c MIOS_BANKSTICK_WritePage((addr << 6), current_preset);// parentheses here MOVLW HIGH(_current_preset) MOVWF r0x02 MOVLW LOW(_current_preset) MOVWF r0x01 MOVLW 0x80 MOVWF r0x04 MOVF r0x04, W MOVWF POSTDEC1 MOVF r0x02, W MOVWF POSTDEC1 MOVF r0x01, W MOVWF POSTDEC1 MOVF r0x03, W MOVWF POSTDEC1 MOVF r0x00, W CALL _MIOS_BANKSTICK_WritePage MOVLW 0x04 ADDWF FSR1L, F MOVFF PREINC1, r0x04 MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN ..while this one is NOT working!! : ; ; Starting pCode block S_main__preset_store code _preset_store: ; .line 170; main.c void preset_store(unsigned char num) __wparam{ MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x00, POSTDEC1 MOVFF r0x01, POSTDEC1 MOVFF r0x02, POSTDEC1 MOVFF r0x03, POSTDEC1 MOVFF r0x04, POSTDEC1 MOVWF r0x00 ; .line 171; main.c unsigned int addr = ((unsigned char)num); CLRF r0x01 ; .line 177; main.c MIOS_BANKSTICK_WritePage((addr << 6), current_preset);// parentheses here RRCF r0x01, W MOVWF r0x03 RRCF r0x02, W MOVWF r0x02 RRCF r0x03, F RRCF r0x02, F RRCF r0x03, W ANDLW 0xc0 XORWF r0x02, W XORWF r0x02, F XORWF r0x02, W MOVWF r0x03 MOVLW HIGH(_current_preset) MOVWF r0x01 MOVLW LOW(_current_preset) MOVWF r0x00 MOVLW 0x80 MOVWF r0x04 MOVF r0x04, W MOVWF POSTDEC1 MOVF r0x01, W MOVWF POSTDEC1 MOVF r0x00, W MOVWF POSTDEC1 MOVF r0x03, W MOVWF POSTDEC1 MOVF r0x02, W CALL _MIOS_BANKSTICK_WritePage MOVLW 0x04 ADDWF FSR1L, F MOVFF PREINC1, r0x04 MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN the typecast on assign nor the parentheses on passing make any difference. this one works again: ; ; Starting pCode block S_main__preset_store code _preset_store: ; .line 170; main.c void preset_store(unsigned char num) __wparam{ MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x00, POSTDEC1 MOVFF r0x01, POSTDEC1 MOVFF r0x02, POSTDEC1 MOVFF r0x03, POSTDEC1 MOVFF r0x04, POSTDEC1 MOVWF r0x00 ; .line 171; main.c unsigned int addr = num; MOVFF r0x00, r0x01 CLRF r0x02 ; .line 172; main.c MIOS_LCD_Clear(); CALL _MIOS_LCD_Clear ; .line 173; main.c MIOS_LCD_CursorSet(0); MOVLW 0x00 CALL _MIOS_LCD_CursorSet ; .line 174; main.c MIOS_LCD_PrintBCD2(num); MOVF r0x00, W CALL _MIOS_LCD_PrintBCD2 ; .line 175; main.c MIOS_LCD_PrintCString(" - "); MOVLW UPPER(__str_0) MOVWF POSTDEC1 MOVLW HIGH(__str_0) MOVWF POSTDEC1 MOVLW LOW(__str_0) CALL _MIOS_LCD_PrintCString MOVLW 0x02 ADDWF FSR1L, F ; .line 176; main.c MIOS_LCD_PrintBCD5(addr << 6);// parentheses here RRCF r0x02, W MOVWF r0x03 RRCF r0x00, W MOVWF r0x00 RRCF r0x03, F RRCF r0x00, F RRCF r0x03, W ANDLW 0xc0 XORWF r0x00, W XORWF r0x00, F XORWF r0x00, W MOVWF r0x03 MOVF r0x03, W MOVWF POSTDEC1 MOVF r0x00, W CALL _MIOS_LCD_PrintBCD5 INCF FSR1L, F ; .line 177; main.c MIOS_BANKSTICK_WritePage(addr << 6, current_preset);// parentheses here MOVLW HIGH(_current_preset) MOVWF r0x02 MOVLW LOW(_current_preset) MOVWF r0x01 MOVLW 0x80 MOVWF r0x04 MOVF r0x04, W MOVWF POSTDEC1 MOVF r0x02, W MOVWF POSTDEC1 MOVF r0x01, W MOVWF POSTDEC1 MOVF r0x03, W MOVWF POSTDEC1 MOVF r0x00, W CALL _MIOS_BANKSTICK_WritePage MOVLW 0x04 ADDWF FSR1L, F MOVFF PREINC1, r0x04 MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN ...and this one is NOT working: ; ; Starting pCode block S_main__preset_store code _preset_store: ; .line 170; main.c void preset_store(unsigned char num) __wparam{ MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x00, POSTDEC1 MOVFF r0x01, POSTDEC1 MOVFF r0x02, POSTDEC1 MOVFF r0x03, POSTDEC1 MOVFF r0x04, POSTDEC1 MOVWF r0x00 ; .line 171; main.c unsigned int addr = num; CLRF r0x01 ; .line 177; main.c MIOS_BANKSTICK_WritePage(addr << 6, current_preset);// parentheses here RRCF r0x01, W MOVWF r0x03 RRCF r0x02, W MOVWF r0x02 RRCF r0x03, F RRCF r0x02, F RRCF r0x03, W ANDLW 0xc0 XORWF r0x02, W XORWF r0x02, F XORWF r0x02, W MOVWF r0x03 MOVLW HIGH(_current_preset) MOVWF r0x01 MOVLW LOW(_current_preset) MOVWF r0x00 MOVLW 0x80 MOVWF r0x04 MOVF r0x04, W MOVWF POSTDEC1 MOVF r0x01, W MOVWF POSTDEC1 MOVF r0x00, W MOVWF POSTDEC1 MOVF r0x03, W MOVWF POSTDEC1 MOVF r0x02, W CALL _MIOS_BANKSTICK_WritePage MOVLW 0x04 ADDWF FSR1L, F MOVFF PREINC1, r0x04 MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN one more.. this is not working : ; ; Starting pCode block S_main__preset_store code _preset_store: ; .line 163; main.c void preset_store(unsigned char num) __wparam{ MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x00, POSTDEC1 MOVFF r0x01, POSTDEC1 MOVFF r0x02, POSTDEC1 MOVFF r0x03, POSTDEC1 MOVFF r0x04, POSTDEC1 MOVWF r0x00 ; .line 164; main.c unsigned int addr = num; CLRF r0x01 ; .line 166; main.c MIOS_BANKSTICK_WritePage((addr <<= 6), current_preset); RRCF r0x01, W MOVWF r0x03 RRCF r0x02, W MOVWF r0x02 RRCF r0x03, F RRCF r0x02, F RRCF r0x03, W ANDLW 0xc0 XORWF r0x02, W XORWF r0x02, F XORWF r0x02, W MOVWF r0x03 MOVLW HIGH(_current_preset) MOVWF r0x01 MOVLW LOW(_current_preset) MOVWF r0x00 MOVLW 0x80 MOVWF r0x04 MOVF r0x04, W MOVWF POSTDEC1 MOVF r0x01, W MOVWF POSTDEC1 MOVF r0x00, W MOVWF POSTDEC1 MOVF r0x03, W MOVWF POSTDEC1 MOVF r0x02, W CALL _MIOS_BANKSTICK_WritePage MOVLW 0x04 ADDWF FSR1L, F MOVFF PREINC1, r0x04 MOVFF PREINC1, r0x03 MOVFF PREINC1, r0x02 MOVFF PREINC1, r0x01 MOVFF PREINC1, r0x00 MOVFF PREINC1, FSR2L RETURN so It looks like the bitshift needs to be on a separate line.. I let it be your job to interpret the asm..

I propose this one (german): http://www.reset.ch/

ok, I found it: it's about the building of the storage-address. wrong use of bitshift leads to interesting results (different if I call the same code from Tick or from DIN_Notify...): this works not (I inserted some LCD code to get a debug output): void preset_store(unsigned char num) __wparam{ unsigned int addr = ((unsigned int)num) << 6; //unsigned int addr = num*64; MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0); MIOS_LCD_PrintBCD2(num); MIOS_LCD_PrintCString(" - "); MIOS_LCD_PrintBCD5(addr); MIOS_BANKSTICK_WritePage(addr, current_preset); } output for num==10 when I call it in DIN_NotifyToggle: 10 - 64 and for calls from Tick: 10 - 0 this one works: void preset_store(unsigned char num) __wparam{ unsigned int addr = num; addr <<= 6; MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0); MIOS_LCD_PrintBCD2(num); MIOS_LCD_PrintCString(" - "); MIOS_LCD_PrintBCD5(addr); MIOS_BANKSTICK_WritePage(addr, current_preset); } 10 - 640 2 - 128 etc. but this works NOT!!: void preset_store(unsigned char num) __wparam{ unsigned int addr = num; //addr <<= 6; MIOS_BANKSTICK_WritePage(addr << 6, current_preset); } finally, this variant works: void preset_store(unsigned char num) __wparam{ unsigned int addr = num; addr <<= 6; MIOS_BANKSTICK_WritePage(addr, current_preset); } it took me hours to come to this ;-)

hi, I have some question concerning bankstick MIOS_Bankstick_WritePage: - does the function return immediately and the 64 bytes are written in background, or do I have to check for a flag or something until I can call the function again? is the MIOS_BOX_STAT.BS_AVAILABLE the magic flag which I have to poll after each writepage? why I'am asking: In my application I have a current_preset - array (size 64 bytes) and a function that writes it to the stick with MIOS_BANKSTICK_WritePage. If I write the preset to any preset-storage-address (preset_num << 6), everything works fine. But if I call the same store-function in a loop to init all the 16 presets on the stick, I get very strange results.. I do this in the main-loop (USER_Tick). if I just init one preset, all works fine again. - what's the point about the 'verifiy' - option, when/what for do I need it or not? is the verify for writepage done for every byte, or do I just get an error when the whole content is equal? thanks, this

my wiring is already fixed. I'll do the doc improvement when I finished the midi-mapper and write documentation to it. no, I don't request a flag for my private use. It was just a proposition to avoid others running into the same confusion, it was more a proposition for the new ARM based MIOS. ok, this is a strong argument. I give up :-) besides, I don't want to fall on your nerves.. thanks for help & info, this

ok, I understand. It makes sense to have the MSB represent the highest PIN value on both DIN and DOUT. But if the bits would be pushed out left-to-right (MSB first) instead of right-to-left, the SR 0 would be the last register in the chain physically. This way the D0 - D7 taging would match the pin-number on software side, also the MSB-LSB story and the order of the bytes in the array would stay the same. J3 - J6 on the schematics/boards do not imply so strong that this reflects the order of the single registers on software level, and plugs are changed more quickly than single wires. I think the IC's have this setup because one normally sends data left-to-right and also receives it left to right (sending the first bit/byte of a file first, and also receive it first). sorry to be so picky, it's just a proposition. compatibility problems: maybe a MIOS-flag for the orientation of the push-out? ok, as soon as I have some time I'll do this. right now I'am occupied with the MIDI-mapper hardware/software. I'll document this project anyway, so I'll do the DIN/DOUT table update then.

ok, I'll do this update on the wiki. @TK just for my understanding: what you do on software level is that you have all the bytes in a array from 0 to x and push them out from LSB x to MSB 0, and you read them (DIN) from MSB 0 to LSB x, right? this makes sense in view of the resulting swap-effect. what I was missing was a fat hint on this effect, for example on the very entry page of the DOUT module. I built the hardware before I could test it (missing plugs), and so I now had to change all the wiring to correct the effect. I'll do this info update on the wiki, and maybe if it's done someone who has write access adds a good visible hint on the DOUT page on ucapps.de. thanks for the help, this

I'am glad to read this. I now had a look at the datasheets of the SN74HC165 / 595, to get clear what is happening on hardware and software level (maybe someone else finds this info usefull): in the sheets the IN/OUT pins are A-H, this reflects D0-D7 (smashTV boards / circuit layouts), O 0-O7 / I0-I7 (circuit layouts) DIN chain hardware-level: CORE <- R1::qH <- R1::H <- R1 <- R1::G ..... R2::qH <- R2::H etc. so the first bit read is DIN1::I7, I suppose this goes to the MSB on software level. DOUT chain hardware-level: CORE -> R1::SER -> R1::A -> R1::B -> R1::C ..... R2::SER -> R2::A etc. so the first bit pushed out goes to DOUTlast::D7, the last pushed bit goes to DOUT1::D0 what I don't understand is what is happening on software level. Suppose the Byte is pushed out LSB -> MSB (right to left), and the input stream goes to MSB - > LSB (left to right)? ..and PIN 0 is always reflected @LSB (SRGet/SRSet)? Quite confusing. If somebody can give me the answers, I will put this infos to a table that gives a clear overview for others with the same questions. I attached the two datasheets. SN74HC595.pdf SN74HC165.pdf SN74HC595.pdf SN74HC165.pdf

problem solved.... me idiot made a shortcut with the mounting screws for the little bankstick-bord.. but the DOUT-issue still remains.

hmm... I think no. I just disconnected the SRIO boards, the problem stays. the DOUT-issue is not a malfunction in this way, it's just kind of confusing.. the test app works as expected, only the MSB/LSB of the DOUT-registers are swapped. the single registers appear in the right order.. and with the ribbon cable wiring you have very few pontential wiring bug sources :-) I'll check the Bankstick wiring, maybe some solder-bridge or something (as I already had on a core PCB this mornig..) some more pics..

hello, I try to connect a bank stick to IIC-port and a character LCD to J15. When the Bankstick is not connected, everything runs fine, if the stick is connected, the LCD won't work anymore, but the application is running normal. I did not yet check if Bankstick reads/writes work. Is it a problem to have a bankstick and character LCD connected at the same time? PIN 28 of the PIC is used for both IIC and LCD port. What is its function? thanks, this

hi all, I have a strange problem (or question) concerning the pin-numbering of DOUT's. I builded a testing board to test IO pins. The DIN works fine, PIN-numbering as expected. I use 10wire ribbon cables and DIL headers with smashTV's PCB's, one DIN and one DOUT board are connected to the core. I wrote a simple program that just displays the DIN-pin (pressed button) and switches the pin with the same number DOUT. The strange thing is, that the DOUT registers seem to have swapped LSB/MSB: DOUT 0 -> DOUT 7 DOUT 1 -> DOUT 6 .. DOUT 7 -> DOUT 1 .. DOUT 8 -> DOUT 15 .. DOUT 15 -> DOUT 8 I checked the wiring back and forth, even checked the datasheet of the stuffed registers (SN74HC595N), where the outputs are numbered A-H, and the forward output is H'. nothing explains this behaviour. my only explanation is, that the registers seem to assign the bits from H-A, not to A-H, which looks very strange to me. has somebody experienced something similar? or any explanation? I could handle this in software, but I would like to know what is going down there. wiring is: LED 0 -> J3::D0 LED 1 -> J3::D1 ... LED 8 -> J4::D0 etc. DIN::J1 -> DOUT::J1 -> CORE::J8/J9 (10wire ribbon cable, DIL headers) thanks in advance, this

maybe the optimizer changes this to if ((pin >= 1) && (pin <= 5)) group = 1; else if (pin == 7) group = 2; or if (pin >= 1){ if (pin == 7) group = 2; else if (pin <= 5) group = 1; } which would make sense. or it makes a switch construct out of it. check the sdcc-manual, it tells you something about flow changes. loops like for($i=0;$i<8;$i++) ... will be reversed by the optimizer (topdown instead of bottom-up) when some conditions are given. this makes the condition check smaller. you get the same flow-changed-warning then.

@stryd_one thanks for your help, I will check the pointer issue, and hope I'll soon receive my plugs so I can test the application. I documented the whole hardware-building with my camera, so I'll make a detailed doc for hardware and software as well, and hope that somebody else will find the device usefull :-) UPDATE: fixed the pointer bug. current_preset is a struct-array. an array variable is already a pointer to the first element, so no address-operator needed at all..

oh, you just found a bug in my code... I'am used from pascal/delphi to use @ as address-operator, in c it's &.. shame on me.. thank you! I could not test the app until now, because I wait for some DIL pin header. your newer compiler seems to be less "tolerant".. I'll update mine. I originally put it in there.. somebody moved it out there. and you now move it in again. *ärger* anyway. please let it reside in processing now, because this is the matching category. and how did you move it? did you use "svn move"? because I could not commit my working copy after you moved the folder. I guess with "svn move" the client will be informed about the move if it commits the moved folder? I'am a kubuntu user, and I had to set the env var $MIOS_SHELL to point to bash. this@this-laptop:/bin$ echo $MIOS_SHELL /bin/bash my /bin/sh is a link to dash: this@this-laptop:/bin$ ls -l sh lrwxrwxrwx 1 root root 4 2008-09-04 04:58 sh -> dash this@this-laptop:~/mios/trunk/apps/processing/midi_mapper$ sh --version sh: Illegal option -- don't worry about the nazi ;) I solved this for me, I use no passphrase at all. just do sh-keygen -p -t dsa enter your old passphrase, then just leave the new passphrase empty. the key stays the same 8)

here my toolchain-info: bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) make --version GNU Make 3.81 sed --version GNU sed Version 4.1.5 sdcc --version SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.7.0 #4818 (Jan 18 2008) (UNIX) gpasm --version gpasm-0.13.4 beta are you sure you did not mess something up in the code on copy? this errors make no sense to me. the version I posted has a comment line on line 66, line 71 is empty.. 66: //------------------------------------------ 67: 68: void store_preset(unsigned char num) __wparam{ 69: MIOS_BANKSTICK_WritePage(num*64, @current_preset); 70: } 71: 72: void load_preset(unsigned char num) __wparam{ the app is in the repository in trunk/apps/midi_mapper/ if you want to check if this compliles with your toolchain. I just commited a version that compiles with no problem for me. by the way: is it normal that svn has delays of several seconds for every action? (commit, checkout, update etc.). for ex. if I 'svn commit', it takes about 10 seconds until It starts submiting.

ok, here's the code you nazi ;D : // $Id: main.c 333 2008-05-10 20:49:56Z tk $ /* * MIDI-Box Channel-Mapper * * ========================================================================== * * Copyright (C) 2008 Matthias Mächler (maechler@mm-computing.ch) * Licensed for personal non-commercial use only. * All other rights reserved. * * ========================================================================== */ ///////////////////////////////////////////////////////////////////////////// // Include files ///////////////////////////////////////////////////////////////////////////// #include <cmios.h> #include <pic18fregs.h> ///////////////////////////////////////////////////////////////////////////// // Application specific ///////////////////////////////////////////////////////////////////////////// //each set bit of inputs/outputs assigns an channel to the bus (lsb = channel 0, msb = channel 16) struct midi_bus{ unsigned int inputs; unsigned int outputs; }; //--constants-- //--1 tick = 52.428ms; 20 ticks = ca. 1 sec-- //time that the user has to hold the preset/bus button down to init all presets/all buses #define init_request_ticks 60 //time that all the 16 value-leds will flash after a init #define init_ledflash_ticks 7 const unsigned int int_bit_ormask[16] = { 0x0001,0x0002,0x0004,0x0008, 0x0010,0x0020,0x0040,0x0080, 0x0100,0x0200,0x0400,0x0800, 0x1000,0x2000,0x4000,0x8000 }; //--current state-- unsigned char current_screen_num=0;//0:prs;1:bus;2:in;3:out;stored at 0x00 in EEPROM unsigned char current_preset_num=0;//stored at 0x01 of EEPROM unsigned char current_bus_num=0;//stored at 0x02 of EEPROM struct midi_bus current_preset[16];//stored in Bank Stick after change signed char midi_inout_map[16][16];//map the input-> output relations for faster msg forwarding const unsigned int dummyb = 30000000; //--timer-- unsigned char timer_ticks_count=0; //------------------------------------------ //----------application functions----------- //------------------------------------------ void store_preset(unsigned char num) __wparam{ MIOS_BANKSTICK_WritePage(num*64, @current_preset); } void load_preset(unsigned char num) __wparam{ unsigned char bus,chn_in,chn_out,i; MIOS_BANKSTICK_ReadPage(num*64, @current_preset); //extraxt midi_inout_map for(bus=0;bus<16;bus++){ for(chn_in=0;chn_in<16;chn_in++){ if(current_preset[bus].inputs & int_bit_ormask[chn_in]){ i=0; for(chn_out=0;chn_out<16;chn_out++){ if(current_preset[bus].outputs & int_bit_ormask[chn_out]) midi_inout_map[chn_in][i++] = chn_out; } midi_inout_map[chn_in][i] = -1;//terminate list } } } } void screen_init(void) __wparam{ //set bitmask for screen button MIOS_DOUT_SRSet(0x00,MIOS_HLP_GetBitORMask(current_screen_num)); //clear value screen MIOS_DOUT_SRSet(0x01,0x00); MIOS_DOUT_SRSet(0x02,0x00); switch(current_screen_num){ case 0://preset screen if(current_preset_num < 8) MIOS_DOUT_SRSet(0x01,MIOS_HLP_GetBitORMask(current_screen_num)); else MIOS_DOUT_SRSet(0x02,MIOS_HLP_GetBitORMask(current_screen_num-8)); break; case 1://bus screen if(current_bus_num < 8) MIOS_DOUT_SRSet(0x01,MIOS_HLP_GetBitORMask(current_bus_num)); else MIOS_DOUT_SRSet(0x02,MIOS_HLP_GetBitORMask(current_bus_num-8)); break; case 2://inputs screen MIOS_DOUT_SRSet(0x01,(unsigned char)(current_preset[current_bus_num].inputs & 0x00ff)); MIOS_DOUT_SRSet(0x02,(unsigned char)(current_preset[current_bus_num].inputs >>8 & 0x00ff)); break; case 3://outputs screen MIOS_DOUT_SRSet(0x01,(unsigned char)(current_preset[current_bus_num].outputs & 0x00ff)); MIOS_DOUT_SRSet(0x02,(unsigned char)(current_preset[current_bus_num].outputs >>8 & 0x00ff)); } } //inits and stores the current preset. bus0:in_ch,out_ch0;bus1:in_ch1,out_ch1;.. void preset_init(void) __wparam{ unsigned char i; for(i=0;i<16;i++){ current_preset[i].inputs = current_preset[i].outputs = int_bit_ormask[i]; midi_inout_map[i][0]=i; midi_inout_map[i][0]=-1;//terminate } store_preset(current_preset_num); } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS after startup to initialize the // application ///////////////////////////////////////////////////////////////////////////// void Init(void) __wparam{ MIOS_SRIO_UpdateFrqSet(1); // ms MIOS_SRIO_NumberSet(3);//need 20 inputs / outputs MIOS_SRIO_DebounceSet(10); MIOS_BANKSTICK_CtrlSet(0x00);//stick 0, verify enabled //load last application state current_screen_num = MIOS_EEPROM_Read(0x00); current_preset_num = MIOS_EEPROM_Read(0x01); current_bus_num = MIOS_EEPROM_Read(0x02); load_preset(current_preset_num); //init screen screen_init(); } ///////////////////////////////////////////////////////////////////////////// // This function is periodically called by MIOS. The frequency has to be // initialized with MIOS_Timer_Set ///////////////////////////////////////////////////////////////////////////// void Timer(void) __wparam{ unsigned char i; if(++timer_ticks_count >= init_request_ticks){ if(timer_ticks_count == init_request_ticks){ preset_init();//inits the current preset if(!current_screen_num){//page is preset.. for(i=0;i<16;i++)//inits all presets on bankstick(store reset preset) store_preset(i); } else//page is bank so.. store_preset(current_preset_num);//store the current (reset) preset //flash! MIOS_DOUT_SRSet(0x01,0xff); MIOS_DOUT_SRSet(0x02,0xff); } else if(timer_ticks_count >= init_request_ticks+init_ledflash_ticks){ MIOS_TIMER_Stop();//stops the init request countdown screen_init(); } } } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a MIDI byte has been received ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyReceivedByte(unsigned char byte) __wparam{ //this function forwards all system messages to the output static unsigned char fx_status = 0; if(byte >= 0xf0){//system status byte MIOS_MIDI_TxBufferPut(byte); //determine status switch(byte){ case 0xf1://midi timecode case 0xf3://songselect fx_status = 1; break; case 0xf2://songposition pointer fx_status = 2; break; case 0xf0://sysex, forward until 0xf7 fx_status = 0xff; break; default://applies also on 0xf7! fx_status = 0; } } else if(fx_status){ MIOS_MIDI_TxBufferPut(byte); if(fx_status!=0xff) fx_status--; } } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a complete MIDI event has been received ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam{ unsigned char i; unsigned char evnt_type = evnt0 & 0xf0; unsigned char in_chn = evnt0 & 0x0f; unsigned char evnt2_send = !(evnt_type == 0xc0 || evnt_type == 0xd0); for(i=0;i<16 && midi_inout_map[in_chn][i]!=-1;i++){ MIOS_MIDI_TxBufferPut(evnt_type+midi_inout_map[in_chn][i]); MIOS_MIDI_TxBufferPut(evnt1); if(evnt2_send) MIOS_MIDI_TxBufferPut(evnt2); } } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when an button has been toggled // pin_value is 1 when button released, and 0 when button pressed ///////////////////////////////////////////////////////////////////////////// void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam{ unsigned char i,chn_out,chn_in,value; MIOS_TIMER_Stop();//stops the init request countdown if(pin_value) return;//button up, nothing more to do if(pin > 7){ value = pin - 8; switch(current_screen_num){ case 0://preset screen current_preset_num = value; load_preset(current_preset_num); MIOS_EEPROM_Write(0x01,current_preset_num); break; case 1://bus screen current_bus_num = value; MIOS_EEPROM_Write(0x02,current_bus_num); break; case 2://input screen if (MIOS_DIN_PinGet(0x02)){//set/unset input chanel current_preset[current_bus_num].inputs = current_preset[current_bus_num].inputs==int_bit_ormask[value] ? 0x0000 :int_bit_ormask[value]; } else{//add/remove input chanel current_preset[current_bus_num].inputs = (current_preset[current_bus_num].inputs & int_bit_ormask[value])? (current_preset[current_bus_num].inputs ^ int_bit_ormask[value]): (current_preset[current_bus_num].inputs | int_bit_ormask[value]); } //assign the bus's output channels to new input channel on the map i=0; for(chn_out=0;chn_out<16;chn_out++){ if(current_preset[current_bus_num].outputs & int_bit_ormask[chn_out])//this is a bus output midi_inout_map[value][i++] = chn_out; } midi_inout_map[value][i] = -1; break; case 3://output screen if (MIOS_DIN_PinGet(0x03)){//set/unset output chanel current_preset[current_bus_num].outputs = (current_preset[current_bus_num].outputs==int_bit_ormask[value]) ? 0x0000 :int_bit_ormask[value]; } else{//add/remove output chanel current_preset[current_bus_num].outputs = (current_preset[current_bus_num].outputs & int_bit_ormask[value])? (current_preset[current_bus_num].outputs ^ int_bit_ormask[value]): (current_preset[current_bus_num].outputs | int_bit_ormask[value]); } //assign the outputchannels to the bus's input-channels on the map for(chn_in=0;chn_in<16;chn_in++){ if(current_preset[current_bus_num].inputs & int_bit_ormask[chn_in]){//this is a bus input i=0; for(chn_out=0;chn_out<16;chn_out++){ if(current_preset[current_bus_num].outputs & int_bit_ormask[chn_out])//this is a bus output midi_inout_map[chn_in][i++] = chn_out; } midi_inout_map[chn_in][i] = -1; } } break; } } else if(pin < 4){ current_screen_num = pin; MIOS_EEPROM_Write(0x00, current_screen_num); if(pin < 2){//start init request countdown timer_ticks_count = 0; MIOS_TIMER_Init(0x03,0xffff); } } screen_init(); } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when the display content should be // initialized. Thats the case during startup and after a temporary message // has been printed on the screen ///////////////////////////////////////////////////////////////////////////// void DISPLAY_Init(void) __wparam{ } ///////////////////////////////////////////////////////////////////////////// // This function is called in the mainloop when no temporary message is shown // on screen. Print the realtime messages here ///////////////////////////////////////////////////////////////////////////// void DISPLAY_Tick(void) __wparam{ } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS in the mainloop when nothing else is to do ///////////////////////////////////////////////////////////////////////////// void Tick(void) __wparam{ } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a MIDI event has been received // which has been specified in the MIOS_MPROC_EVENT_TABLE ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyFoundEvent(unsigned entry, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam{ } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a MIDI event has not been completly // received within 2 seconds ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyTimeout(void) __wparam{ } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS before the shift register are loaded ///////////////////////////////////////////////////////////////////////////// void SR_Service_Prepare(void) __wparam{ } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS after the shift register have been loaded ///////////////////////////////////////////////////////////////////////////// void SR_Service_Finish(void) __wparam{ } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when an encoder has been moved // incrementer is positive when encoder has been turned clockwise, else // it is negative ///////////////////////////////////////////////////////////////////////////// void ENC_NotifyChange(unsigned char encoder, char incrementer) __wparam{ } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a pot has been moved ///////////////////////////////////////////////////////////////////////////// void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam{ } I get this output on compiling: this@this-laptop:~/mios/trunk/apps/midi_mapper$ make rm -rf _output/* rm -rf _output rm -rf *.cod *.map *.lst rm -rf *.hex mkdir -p _output /bin/bash /home/this/mios/trunk/bin/mios-gpasm -c -p p18f452 -I./src -I /home/this/mios/trunk/include/asm -I /home/this/mios/trunk/include/share -I /home/this/mios/trunk/modules/app_lcd/dummy -DDEBUG_MODE=0 -DSTACK_HEAD=0x37f -DSTACK_IRQ_HEAD=0x33f -I /home/this/mios/trunk/modules/mios_wrapper /home/this/mios/trunk/modules/mios_wrapper/mios_wrapper.asm -o _output/mios_wrapper.o /bin/bash /home/this/mios/trunk/bin/mios-gpasm -c -p p18f452 -I./src -I /home/this/mios/trunk/include/asm -I /home/this/mios/trunk/include/share -I /home/this/mios/trunk/modules/app_lcd/dummy -DDEBUG_MODE=0 /home/this/mios/trunk/modules/app_lcd/dummy/app_lcd.asm -o _output/app_lcd.o /bin/bash /home/this/mios/trunk/bin/mios-sdcc -c -mpic16 -p18f452 --fommit-frame-pointer --optimize-goto --optimize-cmp --disable-warning 85 --obanksel=2 -I./src -I /home/this/mios/trunk/include/c -I /home/this/mios/trunk/include/share -DDEBUG_MODE=0 main.c -o _output/main.o /home/this/mios/trunk/bin/mios-gpasm modifies _output/main.asm, result in _output/main__mios-gpasm-tmp.asm gplink -s /home/this/mios/trunk/etc/lkr/p18f452.lkr -m -o project.hex /home/this/mios/trunk/lib/libsdcc.lib /home/this/mios/trunk/lib/pic18f452.lib _output/mios_wrapper.o _output/app_lcd.o _output/main.o gplink: lst.c:187: write_src: Assertion `data & 0x80000000' failed. make: *** [project.hex] Aborted make: *** Datei »project.hex« wird gelöscht this@this-laptop:~/mios/trunk/apps/midi_mapper$ I don't use the const (line 56). so it seems more to matter where in the codespace the const is placed ? gplink: lst.c:187: write_src: Assertion `data & 0x80000000' failed. 0x80'000'000 is muchmuch over the limits of the codespace, so maybe the overflow makes the linker think it has to place the const there? the asm code at the end of the asm file: ; ; Starting pCode block for Ival code _int_bit_ormask: DB 0x01, 0x00, 0x02, 0x00, 0x04, 0x00, 0x08, 0x00, 0x10, 0x00, 0x20, 0x00 DB 0x40, 0x00, 0x80, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x04, 0x00, 0x08 DB 0x00, 0x10, 0x00, 0x20, 0x00, 0x40, 0x00, 0x80 ; ; Starting pCode block for Ival _dummyb: DB 0x80, 0xc3 ; Statistics: ; code size: 3620 (0x0e24) bytes ( 2.76%) ; 1810 (0x0712) words ; udata size: 320 (0x0140) bytes (25.00%) ; access size: 22 (0x0016) bytes end strange: if I put the const before my 16xint array const, it compiles without assertion. then the asm code looks like this: ; ; Starting pCode block for Ival code _dummyb: DB 0x80, 0xc3 ; ; Starting pCode block for Ival _int_bit_ormask: DB 0x01, 0x00, 0x02, 0x00, 0x04, 0x00, 0x08, 0x00, 0x10, 0x00, 0x20, 0x00 DB 0x40, 0x00, 0x80, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x04, 0x00, 0x08 DB 0x00, 0x10, 0x00, 0x20, 0x00, 0x40, 0x00, 0x80 ; Statistics: ; code size: 3620 (0x0e24) bytes ( 2.76%) ; 1810 (0x0712) words ; udata size: 320 (0x0140) bytes (25.00%) ; access size: 22 (0x0016) bytes end I can see no difference except of the position of the data.. the whole story with 31000000 except of 30000000 works again: ; ; Starting pCode block for Ival code _int_bit_ormask: DB 0x01, 0x00, 0x02, 0x00, 0x04, 0x00, 0x08, 0x00, 0x10, 0x00, 0x20, 0x00 DB 0x40, 0x00, 0x80, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x04, 0x00, 0x08 DB 0x00, 0x10, 0x00, 0x20, 0x00, 0x40, 0x00, 0x80 ; ; Starting pCode block for Ival _dummyb: DB 0xc0, 0x05 ; Statistics: ; code size: 3620 (0x0e24) bytes ( 2.76%) ; 1810 (0x0712) words ; udata size: 320 (0x0140) bytes (25.00%) ; access size: 22 (0x0016) bytes end uuuuh.. 3000000 is the magic number ??? yes, my toolchain is ok. I was just not so clearly aware of the difference from c to c++. but I'am currently reading more about it.

yeah, actually a mini or nano is cheaper. if there is enough space, this would be the better choice. pico itx: ca. 220 euro (CPU onboard) micro itx (17x17cm): ca 130-200 euro (CPU onboard) DC-DC adapter (input 12VDC): ca. 50 euro + RAM / heatsink / fan

DSP: there is even a pico-itx-board, which is ca. 10x7.2 cm in size: http://www.mini-itx.com/reviews/pico-itx/default.asp?page=1 http://www.via.com.tw/en/initiatives/spearhead/pico-itx/ via technical white paper is attached to the post. a usb-drive could serve as system-drive. link to midi-box via usb-midi or ethernet or something else. pico-itx_form_factor.pdf

I don't have so much experience with C, but during a period with no regular job, I read a book about the language, and made my notes like a proper student ;D so I can refer them now, thats very usefull. also I'am familar with the syntax from writing in PHP and JavaScript. There is still some stuff that confuses me, but what I like about C: it seems to be weird, but in the end it is very consequent.

I'dont know which part of the sdcc manual stryd_one is referencing, but I found some interesting stuff about functions / parameters / structures in the manual's chapter '8.2 ANSI-Compliance': so if you want to pass a structure variable to a function, it's only correct to declare it as a pointer (as Narwhal said), and copy the struct manually field by field if you need to work with a local copy of the data (which I think will not be necessary in most cases).

hi alexander, first you have to know that an array variable in C is nothing else than a pointer to the data of the array. if you address an element in the array, the compiler just shifts this pointer according to the field size. It's just a smarter way of dereferencing a pointer. the compiler also knows the field type and can handle it accordingly then. I think this happens: because you have a union, there are two possibilities for the compiler to handle the passing of your var to the function: as three-bytes-data or as an array variable, which is a pointer. the optimizer finds that you just use the array type in your function and decides to pass it as a pointer, which makes sense because less data will be put on the function stack. In my eyes this is just an optimazation hint, and nothing is wrong with your code. as long as you just read the data, there is no problem with that. If you would write, you would just change the original data, because your array var is a pointer to the data. It's a bit weired in conjunctin with the union thing, e.g. what would happen if you do both in the function, writing to the single fields and the array fields? maybe then the compiler would copy the data, and the array-dereference would point to the copied data then? there are other optimizations like this, which will cause the compiler to throw a warning: this is from the sdcc manual (I attached it to the post). I also found this about passing arrays to functions in c++: http://www.itee.uq.edu.au/~comp2303/Leslie_C_ref/C/SYNTAX/functions.html I believe that passing arrays as data to functions is not part the concept of C, because function parameters will be hold on the the stack, which is limited. so for bigger data amounts you would pass a pointer anyway. I think I should study this passing issue a bit deeper too. correction: by default sdcc does not push the params/vars in a function to the stack. therefore functions are by default non-reentrant. to write a function that you can call recursively, you need to declare the function with the keyword __reentrant (sdcc manual 3.7 Parameters & local variables). also check chapter 8.2 ANSI Compliance. sdccman.pdf

ok, that's what you need to do: -take any application or a fresh and empty c skelleton. -add (one of) these lines to the body of main.c: const unsigned int dummy = 20000000;//no error on compiling const unsigned int dummy = 30000000;//but.. this causes a linker error: that's all. besides I think this isn't an issue that is worth making much mess about it. It's not an error, it would be just interesting *why* the linker throws an error. I'am sure there is a good reason for it. If you are too busy, just forget it.

All that work demonstrates that you've kinda missed my point - I expected the language to take care of this, without my interaction, without writing extra code, without messing around, etc. It doesn't. No problem! I just kinda assumed that it would be 'smarter' than it is. I think the target of C is to have a language that is more "human" than asm, but enough close to the machine to generate fast code. therefore too much overhead would not do it any good. I expected the language to take care of this how should the language "now" what you want to do if you don't tell it ? but C++ is very powerfull, you could for example write your own operator, that gives you the msb of an int as result. you can write operators like objects. I never did this, but I think this is a very powerfull feature. you can even "overload" operators, e.g. if you want to simply add two strings with "+", you can overload the "+" operator and write a routine to process the string-addition. all other types will be handled still in the native manner. check it out.. I hope this input is usefull for you ;)