This N°9

I confirm that following code works as expected with sdcc build #5274: void shift_test(unsigned int addr){ MIOS_LCD_PrintBCD5(addr);//->display shows 1280 } void DISPLAY_Init(void) __wparam{ unsigned int addr = 20; MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0x00); shift_test(addr << 6); } void shift_test(unsigned char addr){ MIOS_LCD_PrintBCD5(addr << 6);//->display shows 1280 } void DISPLAY_Init(void) __wparam{ unsigned char addr = 20; MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0x00); shift_test(addr); } void shift_test(unsigned char num){ unsigned int addr = num << 6; MIOS_LCD_PrintBCD5(addr);//->display shows 1280 } void DISPLAY_Init(void) __wparam{ unsigned char num = 20; MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0x00); shift_test(num); }

allright, allright, peace! ;) and thanks four your instructions. how is this done the best way? just use the search form? I removed the index_test, and will port the DINOUT-table to the new wiki format. fogive me, where did you post this? which forum thread are you refering? Which name(space) to choose for din & dout pintable? would ":mbhp:module:din_dout_pintable" be a good choice?

I missed this question. I just tested build #5274 on my kubuntu system, all works well. Added the confirmation to the bug report. I'll run a test on this issue right now. thanks, this

guess I found the door to the new wiki: http://www.midibox.org/dokuwiki/doku.php?id=new_wiki_layout

ok, I'am fixing the stuff, but I found other (old) sind, for ex. on the page index_test, which links back to the dout_module_digital_out - page: * [[LCD Module (Liquid Crystal Display)|LCD Module]] - Liquid Crystal Display * [[AOUT Module (Analog Out)|AOUT Module]] - Analog Out to output Voltages (for Controls) looks like the other link on page "mbhp", THIS is a bad sytax! I don't like to be blamed for stuff that other before me screwed up!! :) UPDATE: also fixed links / dupes for aout_module_analog_out -> aout_module; on mbhp, LCD-link-to-nowhere -> lcd

I think this dupe story was not my fault, some "moebius" seems to have created this page:

hm... ok, to be honest, I never worked with docuwiki before, so before I screw it up even more: how did this happen? I can only remember that I - edited the page "din_dout_pintable" - added a comment to "dout_module" how and when did I create "dout_module_digital_output" ??? tell me a bit more about dupes. I must have missed this. where? besides, the strange random table-loosing-border behaviour seem to be a result of empty rows (<tr></tr>) generated. I will try to remove them on my next try.

because I 1. can't sleep 2. like so much to argue with stryd_one 3. always have to have the last word If it's not a makefile issue at all, why are you using the word makefile so often ??? :D It's (was) a makefile issue in this way, that the problem could only be detected by including the makefile in the problem-finding-process. Agree? If you beleive it or not, I'am able to read! And guess what, I read all the stuff that Raphael wrote too! ( :) ) Oh, I'am far away from doubting your competence... if I'm falling on your nerves too much, just hit me. currently I'm very happy with my 2.8.0 do you think the bitshifts-not-working-properly-in-some-context-for-example-in-expression-as-function-parameter-issue is worth reporting too? I'm not sure if this is a bug. (see begining of this thread) cheers, this

please be more specific I can't forget what I don't know.. ;) just found it.. besides this was not a not-knowing-the-syntax-related thing. check the difference: |||||| ||||||| it's not a nuclear reactor, it's just a wiki.. :D

hmm.. is frequent writer the next level after "member" ??? ok, I'll use the magic mail, if there is some way to give the programmer group upload access, I would be even happier :D :D :D :D :D

It did help... this was a Makefile - issue: http://sourceforge.net/tracker/?func=detail&atid=100599&aid=2308409&group_id=599

yes, I know.. this is because the table got kind of "radioactive", means it looked different every time I looked at it.. the spacer lines had not as many cells as the content lines. anyway, I removed the spacer lines totally now, because the SR num gives enough visible structure to the table. second I mixed up DOUT's DIN's on the first revisions, and had to correct that afterwards :)

yes, I tried with both firefox 2/3. the upload form should show up underneath the files on the right side in the Media-Files window, right? since I'am a child, I have a pathologically need to be as autonomious as possible.. :) no, just a joke, I simply would love if I could upload the stuff myself. What do I do if the magick email-address is sleeping, and I feel a burning desire to add/change some pics for my project documentation? I will upload no porn stuff, I promise

I try to document my midi-mapper on the wiki, and would also love to be able to upload files myself. Is this possible or do I have to use the magic email-address?

ok, now I updated the DIN / DOUT pin table on the wiki: http://www.midibox.org/dokuwiki/doku.php?id=din_dout_pintable @TK: I propose this one: "Please Note: in contrast to DIN boards, hardware pins are swapped for each SR. Pin D7/O7 reflects the lowest, D0/O0 the highest software-pin-value for each SR."

ok, I cooked the shit down, a can confirm that with 2.8.0 everthing works fine. 2.8.5, the latest snapshot, causes the problems. check this sample code (check code in init & read comments): // $Id: main.c 333 2008-05-10 20:49:56Z tk $ /* * MIOS SDCC Wrapper * * ========================================================================== * * Copyright (C) <year> <name> (<email>) * Licensed for personal non-commercial use only. * All other rights reserved. * * ========================================================================== */ ///////////////////////////////////////////////////////////////////////////// // Include files ///////////////////////////////////////////////////////////////////////////// #include <cmios.h> #include <pic18fregs.h> unsigned char current_preset[64]; const unsigned char current_preset_const[64]= { 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8, 8,8,8,8,8 }; ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS after startup to initialize the // application ///////////////////////////////////////////////////////////////////////////// void Init(void) __wparam{ unsigned int addr = 0x20; //the comments after the code lines apply with sdcc 2.8.4 / 2.8.5 -- //with sdcc 2.8.0 all the lines compile & link without any problems MIOS_BANKSTICK_WritePage(addr, (char*)current_preset);// -> linker error error: multiple sections using address 0 MIOS_BANKSTICK_WritePage(0x10, (char*)current_preset);// -> linker error error: multiple sections using address 0 MIOS_BANKSTICK_WritePage(addr,&(current_preset[0]));// -> linker error error: multiple sections using address 0 MIOS_BANKSTICK_WritePage(addr,0);//compiles & links MIOS_BANKSTICK_WritePage(addr,(char*)current_preset_const);//compiles and links. address to const in codespace } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS in the mainloop when nothing else is to do ///////////////////////////////////////////////////////////////////////////// void Tick(void) __wparam { } ///////////////////////////////////////////////////////////////////////////// // This function is periodically called by MIOS. The frequency has to be // initialized with MIOS_Timer_Set ///////////////////////////////////////////////////////////////////////////// void Timer(void) __wparam { } ///////////////////////////////////////////////////////////////////////////// // 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 when a complete MIDI event has been received ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __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 when a MIDI byte has been received ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyReceivedByte(unsigned char byte) __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 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 { } ///////////////////////////////////////////////////////////////////////////// // 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 made two release packages, one I compliled with 2.8.0, one with 2.8.5. so all that is needed to analyze the problem is included. The problem has nothing to do with bitshift-issues. It's interesting that when addressing a const array, the linker does not complain, but when addressing a variable 64-char-array, it throws the error. I removed everything that is not really necessary to cook down the problem. there is a 64 byte var array, and a 64 byte const array, all other stuff happens in function "init". I added a file named SHELL.txt to the failing release package which contains the shell output of the make-command. @stryd_one: I just commented the bug report with the files attached to this post. It now appears as follow-up to your bug-report on the sourceforge-site. I hope this will help.- test_sdcc.2.8.0.tar.bz2.zip test_sdcc.2.8.5.tar.bz2.zip test_sdcc.2.8.0.tar.bz2.zip test_sdcc.2.8.5.tar.bz2.zip

ok, so I will pack the test application with the modified lines and the comments and post it to the bug report. 2.8.4 is the compiler version that caused the linker error then.

no, this was with 2.8.4. now I'am a bit confused, because you write the code compliled & linked with 2.8.0 ? is there also a problem with 2.8.0 ?

Ok, I see. I think we should not mix up the bitshift - subject with the "error: multiple sections using address 0" subject. The latter appears also with no bitshift at all. MIOS_BANKSTICK_ReadPage(addr,current_preset);//-->error: multiple sections using address 0 MIOS_BANKSTICK_ReadPage(0x00,current_preset);//-->error: multiple sections using address 0 MIOS_BANKSTICK_ReadPage(addr,0);//-->error: multiple sections using address 0 MIOS_BANKSTICK_ReadPage(0x00,0);//-->no error, compliles and links It seems like the parameter passing (and all that follows) causes the problem. And maybe all the MIOS - environment is needed to reproduce the problem. I will take your test-application and make a distribution, which I can post as a standalone- package for the SDCC - developpers to (hopefully) reproduce the issue.

sorry, I don't understand this wording. If you explain it to me I'll do it :-)

I just tried to search on google for similar threads, and found this: http://osdir.com/ml/compilers.sdcc.user/2007-10/msg00030.html they talk about interrupt handlers, I did not read it really carefully, because I'am tired and have to to to bed, It's just a quick shot try, maybe there's some usefull info. In my example the error occurs on calling MIOS_BANKSTICK_ReadPage with some var param, so maybe there's something in the MIOS kernel that was accepted or ignored or interpreted differently by the older SDCC compiler?

maybe the SDCC 2.8.4 need another gputils dist?

@stryd_one I modified your testapp (just this line): MIOS_BANKSTICK_ReadPage(addr,current_preset);//-->error: multiple sections using address 0 MIOS_BANKSTICK_ReadPage(0x00,current_preset);//-->error: multiple sections using address 0 MIOS_BANKSTICK_ReadPage(addr,0);//-->error: multiple sections using address 0 MIOS_BANKSTICK_ReadPage(0x00,0);//-->no error, compliles and links the error occurs also if I never call "preset_storeb". I switched back from SDCC 2.8.4 to the official Kubuntu package 2.7.0, this one complies my app, and it works without problems on my MIDI-box.

I updated to the version 2.8.4 of SDCC, now I get the same error as you *arghhh*. besides, I have to do a typecast on passing the address of my array now: MIOS_BANKSTICK_ReadPage(addr,current_preset); --> main.c:105: error 78: incompatible types I have to write: MIOS_BANKSTICK_ReadPage(addr,(char*)current_preset); ...and the compiler option --optimize-goto is no more present in 2.8.4: at 1: warning 117: unknown compiler option '--optimize-goto' ignored At the base of your test-code, I will analyze what causes the "error: multiple sections using address 0" seems to be the linker that throws it: 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 at 1: warning 117: unknown compiler option '--optimize-goto' ignored 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 error: multiple sections using address 0 make: *** [project.hex] Fehler 1 If I can't fix it, I'll go back to the old SDCC that works for me..

yes, I know.. but currently I'm using the Ubuntu dist, and I'am lazy. I should build it from the source.. hm.. called from a flag? what's this? I'am really a asm-analphabet, you don't see anything that could explain this in the asm-code? you get this on compiling? I can compile your test-code without any problems.. maybe I shouldn't update my sdcc... :-) this@this-laptop:~/mios/trunk/apps/this_testapp$ 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_wrappe r /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 --oban ksel=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.li b _output/mios_wrapper.o _output/app_lcd.o _output/main.o some people could hate me for this property :-)