Jelle Geerts

Show:

What's happening?

  • Comment: initialization issue

    Maarten, I apologize deeply for this bug report. The hexadecimal to binary converter I was using had a bug. The binary file didn't include the null terminator, but with another converter program it is now included and the sample code works fine. Again, sorry! Jelle.

    2009-10-01 01:16:15 UTC in Small Device C Compiler

  • Comment: initialization issue

    In sample.rst I see '.ascii "hello, world"' and at the next line '.db 0x00', as expected. The hex file also contains the null terminator.

    2009-09-30 22:17:44 UTC in Small Device C Compiler

  • Comment: initialization issue

    Oh, perhaps I should add that the first 12 bytes ("hello, world") of the string can correctly be read inside the function test(). Just the zero byte doesn't seem to be there (which is why I thought something could be wrong with the initialization).

    2009-09-30 20:55:09 UTC in Small Device C Compiler

  • Comment: initialization issue

    It does stop indeed, that is the point of this bug report.

    2009-09-30 20:44:10 UTC in Small Device C Compiler

  • initialization issue

    1. For sample code, please see the 'sample.c' attachment. 2. sdcc -mmcs51 --model-small -c src\sample.c 3. SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.2 #5492 (Aug 17 2009) (MINGW32) 4. I think I may have found an issue regarding the initialization code used for the 8051 target. The issue did not appear when using the Keil uVision dev environment, which is why...

    2009-09-30 17:34:54 UTC in Small Device C Compiler

  • Comment: code generation bug

    Good point. I had a hunch something was going on because of the odd memory map result for --model-medium. Perhaps I can hook up an LCD (for which I'd only need to write to P0) to display test info. If we can only access internal xdata using DPTR, is it still possible to get --model-medium to work (albeit with some changes to SDCC, perhaps)? Not that I really need --model-medium, but still.

    2009-09-26 20:29:04 UTC in Small Device C Compiler

  • Comment: code generation bug

    I've ran a test to create memory maps (see the map.c attachment). The thing is, even with --model-medium, 0xfd80 was writable, but only up till 0xfeff (instead of the usual 0xff7f). I'll attach the test (C version + generated assembly) that I used to determine which memory was writable. Also, I don't think I should modify crtxinit.asm before knowing more about whether we can get MOVX...

    2009-09-25 22:45:03 UTC in Small Device C Compiler

  • Comment: code generation bug

    Typo, that --medium-large in my last comment should be --model-large.

    2009-09-25 10:25:47 UTC in Small Device C Compiler

  • Comment: code generation bug

    Forgot to specify --xram-loc. But even if I am going to specify it correctly, it might not work because --model-medium (and --medium-large?) are not supported by SDCC on my device (at least at this moment)?.

    2009-09-25 10:24:26 UTC in Small Device C Compiler

  • Comment: code generation bug

    Maarten, I'm using the TUSB3210 which has an 8052 MCU. It does have internal XDATA, which isn't disabled by default. Also, I have not defined _XPAGE. If you want to have a look at the data manual of the device, see: http://www.tusb3210.com/Download/tusb3210.pdf HTH, Jelle.

    2009-09-25 08:41:29 UTC in Small Device C Compiler

About Me

  • 2006-04-04 (4 years ago)
  • 1494267
  • bughunter2 (My Site)
  • Jelle Geerts

Send me a message