Activity for Tom Li
-
Tom Li created ticket #3581
All functions are reentrant-unsafe on PIC14, ISR may cause memory corruption, need documentation
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. This is an error in the documentation. The name should start with the prefix "gr" and it must be in lower case, NOT the single letter "g". The documentation mistake has already been fixed back in 2005 in the TeX code, unfortunately the online web page version was never updated to reflect that.
-
This bug is a duplicate of https://sourceforge.net/p/mmtl/bugs/15/
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. This is an error in the documentation. The name should start with the prefix "gr" and it must be in lower case, NOT the single letter "g". The documentation mistake has already been fixed back in 2004 in the TeX code, unfortunately the online web page version was never updated to reflect that.
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. This is an error in the documentation. The name should start with the prefix "gr" and it must be in lower case, NOT the single letter "g". The documentation mistake has already been fixed back in 2004 in the source code, unfortunately the online web page version was never updated to reflect that.
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. This is an error in the documentation. The name should start with the prefix "gr" and it must be in lower case, NOT the single letter "g". The documentation mistake has already been fixed back in 2004, unfortunately the online web page version was never updated to reflect that.
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. This is an error in the documentation. The name should starts with lower case "gr" instead of the letter "g". The documentation mistake has already been fixed back in 2004, unfortunately the online web page version was never updated to reflect that.
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. Basically, MMTL's main field solver BEM calculates L and C by solving the mutual capacitance and mutual inductance of the transmission line using the Boundary Element Method. And speaking of R and G, the BEM solver does not consider the effect of dielectric loss or conductor loss when solving the fields, so G is out. Although it does try to calculate conductor...
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. At low frequencies, crosstalk increases linearly, but high frequencies, transmission line resonance effect starts to take over. MMTL calculates the crosstalk solely based on the mutual capacitance, mutual inductance, and propagation velocity, thus, resonance effects are completely neglected. This can be seen from the source code: bem/src/nmmtl_xtk_calculate.cpp....
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. At low frequencies, crosstalk increases linear-in-dB, but high frequencies, transmission line resonance effect starts to take over. MMTL calculates the crosstalk solely based on the mutual capacitance, mutual inductance, and propagation velocity, thus, resonance effects are completely neglected. This can be seen from the source code: bem/src/nmmtl_xtk_calculate.cpp....
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. At low frequencies, crosstalk increases linear-in-dB, but high frequencies, transmission line resonance effect starts to take over. MMTL calculates the crosstalk solely based on the mutual capacitance, mutual inductance, and propagation velocity, thus, resonance effects are completely neglected. This can be seen from the source code: bem/src/nmmtl_xtk_calculate.cpp....
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. At low frequencies, crosstalk increases linear-in-dB, but high frequencies, transmission line resonance effect starts to take over. MMTL calculates the crosstalk solely based on the mutual capacitance, mutual inductance, and propagation velocity, thus, resonance effects are completely neglected. This can be seen from the source code: bem/src/nmmtl_xtk_calculate.cpp....
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. At low frequencies, crosstalk increases linear-in-dB, but high frequencies, transmission line resonance effect starts to take over. MMTL calculates the crosstalk solely based on the mutual capacitance, mutual inductance, and propagation velocity, thus, resonance effects are completely neglected. This can be seen from the source code: bem/src/nmmtl_xtk_calculate.cpp....
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. At low frequencies, crosstalk increases linear-in-dB, but high frequencies, transmission line resonance effect starts to take over. MMTL calculates the crosstalk solely based on the mutual capacitance, mutual inductance, and propagation velocity, thus, resonance effects are completely neglected. This can be seen from the source code: bem/src/nmmtl_xtk_calculate.cpp....
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. At low frequencies, crosstalk increases linear-in-dB, but high frequencies, transmission line resonance effect starts to take over. MMTL calculates the crosstalk solely based on the mutual capacitance, mutual inductance, and propagation velocity, thus, resonance effects are completely neglected. This can be seen from the source code: bem/src/nmmtl_xtk_calculate.cpp....
-
I know this is an old thread and that the project is unmaintained. But as another user of TNT-MMTL, I think it's useful to answer this question. BEM can be invoked manually in the command-line by running the executable "bem" with the following command-line arguments: bem <filename> <c-seg> <p-seg> <filename> - name of the graphic file <c-seg> - number of contour segments <p-seg> - number of plane/dielectric segments <filename> is the xsctn file generated by MMTL, without the .xsctn extension name....
-
I just submitted a PIC patch a few days ago on adding support for new devices. Unfortunately it has no reviewer so far. The PIC targets look completely abandoned...
-
Calling Functions in ISR Corrupts the Stack, as SDCC Makes no Attempt to Preserve it
-
I found some information from Patch 303 (https://sourceforge.net/p/sdcc/patches/303/?page=2). It seems that the duplicate _main symbol was deliberately added. ~~~ // call main after initialization + (void)main; / otherwise the _main symbol is not declared / __asm PAGESEL _main GOTO _main ~~~ So, on some systems, _main symbol is not generated, but on Fedora, _main is generated twice.
-
I found some information from Patch 303 (https://sourceforge.net/p/sdcc/patches/303/?page=2). It seems that the duplicate _main symbol was deliberately added. ~~~ // call main after initialization + (void)main; / otherwise the _main symbol is not declared / __asm PAGESEL _main GOTO _main ~~~ So, on some systems, _main symbol was not getting generated, but on Fedora, _main was being generated twice.
-
I found some information from Patch 303 (https://sourceforge.net/p/sdcc/patches/303/?page=2). It seems that the duplicate _main symbol was deliberately added. // call main after initialization + (void)main; /* otherwise the _main symbol is not declared */ __asm PAGESEL _main GOTO _main So, on some systems, _main symbol was not getting generated, but on Fedora, _main was being generated twice.
-
Can confirm the bug still exists as of 2023. _main: ; 2 exit points ; .line 18; "bug1503.c" a(1); MOVLW 0x01 PAGESEL _a _a: ; .line 12; "bug1503.c" static void a(byte n) { MOVWF _v ; .line 13; "bug1503.c" b(); PAGESEL _b _b: ; .line 9; "bug1503.c" v = 2; MOVLW 0x02 MOVWF _v PAGESEL $ PAGESEL $ _00115_DS_: GOTO _00115_DS_ ; .line 22; "bug1503.c" } RETURN
-
This old bug should be closed as invalid. It's well known to all PIC programmers that 0x70 to 0x7F at the end of a memory bank is "common RAM" and these bytes are globally accessible from all banks. For example, SDCC currently uses it as a software stack STK00 to STK15 for passing arguments across different memory banks.
-
This old bug should be closed as invalid. It's well known to all PIC programmers that 0x70 to 0x7F at the end of a memory bank is "common RAM" and these bytes are globally accessible from all banks. For example, SDCC currently uses it as a software stack STK00 to STK15 for passing arguments.
-
I can no longer reproduce this bug from the current trunk. The old buggy assembly output was: ; .line 31; "bug01.c" if (at0x220) { BANKSEL _at0x220 MOVF (_at0x220 + 0),W IORWF (_at0x220 + 1),W BTFSC STATUS,2 GOTO _00106_DS_ And now the new assembly output is: ; .line 33; "bug01.c" if (at0x220) { MOVLW (_at0x220 + 0) BANKSEL r0x1001 MOVWF r0x1001 MOVF r0x1001,W BTFSC STATUS,2 GOTO _00106_DS_ This bug should be closed.
-
I can no longer reproduce this bug from the current trunk. The old buggy assembly output was: ; .line 31; "bug01.c" if (at0x220) { BANKSEL _at0x220 MOVF (_at0x220 + 0),W IORWF (_at0x220 + 1),W BTFSC STATUS,2 GOTO _00106_DS_ And now the new assembly output is: ; .line 33; "bug01.c" if (at0x220) { MOVLW (_at0x220 + 0) BANKSEL r0x1001 MOVWF r0x1001 MOVF r0x1001,W BTFSC STATUS,2 GOTO _00106_DS_ This bug should be closed.
-
I can no longer reproduce this bug from the current trunk. The old buggy assembly output was: ; .line 31; "bug01.c" if (at0x220) { BANKSEL _at0x220 MOVF (_at0x220 + 0),W IORWF (_at0x220 + 1),W BTFSC STATUS,2 GOTO _00106_DS_ And now the new assembly output is: ; .line 31; "bug01.c" if (at0x220) { BANKSEL _at0x220 MOVF (_at0x220 + 0),W IORWF (_at0x220 + 1),W BTFSC STATUS,2 GOTO _00106_DS_ This bug should be closed.
-
Final part of the patchset, contains PIC16F15325 and PIC16F15345 headers.
-
Second part of the patchset, contains main changes.
-
[RFC] Support "Doubly-Enhanced" PIC14 Cores, with examples of PIC16F15325/345
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header from XC8 into your project, as Microchip's copyright notice explicitly allows you...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header from XC8 into your project, as Microchip's copyright notice explicitly allows you...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header from XC8 into your project, as Microchip's copyright notice explicitly allows you...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header from XC8 into your project, as Microchip's copyright notice explicitly allows you...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header from XC8 into your project, as Microchip's copyright notice explicitly allows you...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header from XC8 into your project, as Microchip's copyright notice explicitly allows you...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header from XC8 into your project file, as Microchip's copyright notice explicitly allows...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header from XC8 into your project file, then you can include this file locally without...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header into your project file, then you can include this file locally without ever using...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header into your project file, then you can include this file locally without ever using...
-
I can confirm that there are clear signs that indicate the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header into your project file, then you can include this file locally without ever using...
-
I can confirm that there are clear signs that indicates the C headers in Microchip's XC8 compilers are officially free. The restrictive "only with authentic Microchip products" license has disappeared, and now only a 3-clause BSD-like license remains (Perhaps Oracle v. Google has finally taught their lawyers a lesson?) So, if you just want to release your project as 100% "fully open-source", just copy your MCU's header into your project file, then you can include this file locally without ever using...
-
Same documentation problem for PIC14. I wasted many hours trying to solve a memory corruption due to overflow caused by a lookup table array. Eventually I found the undocumented __data keyword was the solution, but it was only documented at the 8051 section. No sign or hint was given that it was even supported on the PIC14.
-
Same documentation problem for PIC14. I wasted many hours trying to solve a memory corruption due to overflow caused by a lookup table array. Eventually I found the undocumented __data keyword was the solution, but it was only documented at the 8051 section. No sign or hint that it was even supported on the PIC14.
-
This issue has already been previous reported on the mailing list in 2021. For a more detailed report, including workaround and assembly output, please see: https://sourceforge.net/p/sdcc/discussion/1865/thread/aa77f0a86a/
-
Can confirm. The project needs zlib but the configure script does not check it, making it possible for the build to fail half way.
-
Unfortunately, even running autoreconf cannot solve the symbol conflict problem. The official SDCC prebuild snapshots are currently the only functional builds on Fedora. There must be something wrong in the build system that must be investigated. P.S: The main project already enforces autoconf 2.71 in configure.ac but there are still autoconf 2.69 overrides in /support/sdbinutils/config/override.m4 and ./support/cpp/config/override.m4. Making it impossible to run autoreconf without manually commented...
-
Unfortunately, even running autoreconf cannot solve the symbol conflict problem. The official SDCC prebuild snapshots are currently the only functional build on Fedora. There must be something wrong in the build system that must be investigated. P.S: The main project already enforces autoconf 2.71 in configure.ac but there are still autoconf 2.69 overrides in /support/sdbinutils/config/override.m4 and ./support/cpp/config/override.m4. Making it impossible to run autoreconf without manually commented...
-
Mysteriously, I just found the problem doesn't exist in the official snapshot build. I suspect "libsdcc_a-idata.o" was incorrectly generated. Is it possible that an outdated autoconf output caused this problem? I'll try autoreconf and see...
-
Cannot build any PIC14 code: error: Duplicate symbol "_main" defined in "pic12f675test.o" and "libsdcc_a-idata.o".
-
Yes, I later realized that named labels are completely unsupported and it was not a bug. But even numerical labels were unusable, which was the actual bug. With this patch, at least numerical labels are usable, so I would say the problem is fixed.
-
Won't do again, thanks for the editor tip.
-
Thanks for your suggestion, I skimmed through src/SDCCgen.c, and made the following change, and the bug is indeed gone. diff -urp sdcc-src-20181016-10616/src/SDCCgen.c sdcc-src-20181016-10616.patch/src/SDCCgen.c --- sdcc-src-20181016-10616/src/SDCCgen.c 2018-10-25 12:05:23.405965581 +0800 +++ sdcc-src-20181016-10616.patch/src/SDCCgen.c 2018-10-25 12:06:36.748285936 +0800 @@ -237,6 +237,7 @@ genInline (iCode * ic) *bp = '\0'; ++bp; emitcode (begin, NULL); + genLine.lineCurr->isLabel = 1; begin = bp;...
-
I don't know how SDCC works, but I tried your suggestion and added some printf()s in isLabelDefinition() of src/SDCCpeeph.c, but it seems this function is working correctly and the bug is hidden in other logics. isLabelDefinition: ld l, #%3 false! isLabelDefinition: .db #0xc2 false! isLabelDefinition: %2: true! isLabelDefinition: ld l, #%4 false! isLabelDefinition: %1: true! isLabelDefinition: _inline_asm_label:: true! isLabelDefinition: $1: true! isLabelDefinition: .db 0x1234 false! isLabelDefinition:...
-
It's the bloody SourceForge editor again, destroying every single bug report.
-
Version SDCC : z80 3.8.1 #10616 (Linux) published under GNU General Public License (GPL) Issue Attempting to compile the following sample code, by calling sdcc -mz80 -o dw.ihx dw.c triggers a bug. The compiler will be confused by the dw 0x1234 instruction, and report the following error message... dw.c:13: info 218: z80instructionSize() failed to parse line node, assuming 999 bytes '.dw 0x1234' Analysis A quick code review finds z80instructionSize() in peep.c doesn't have any code to recongize the...
-
It should be noted that, labels like $1: must be used instead of label:, but both usage triggers the same bug.
-
z80instructionSize() failed to parse a label (e.g. '1$:', 'label:')
-
z80instructionSize() failed to parse '.dw 0x1243'
-
Why such useful patch is still not merged after 7 years?
-
Because SDCC had changed so much, it's not easy to update the ebuild used to build...
-
I'm a Gentoo user and unofficial dev. The true story is, that doesn't mean Gentoo...
-
Code Generator Internal Error When Use __sfr on Z80 If "--reserve-regs-iy" is Specified
-
currently, I am using a dirty hack diff -uprN /tmp/libticalcs2-1.1.8.orig/src/calc_84p.c...
-
Compiler Prints False Warning and Crashes in some cases when "if (cond1) { if (cond2) break; else return ptr; }" is in a loop
-
currently, I using a dirty hack diff -uprN /tmp/libticalcs2-1.1.8.orig/src/calc_84p.c...
-
currently, I using a dirty hack diff -uprN /tmp/libticalcs2-1.1.8.orig/src/calc_84p.c...
-
currently, I using a dirty hack diff -uprN /tmp/libticalcs2-1.1.8.orig/src/calc_84p.c...
-
currently, I using a dirty hack ``` diff -uprN /tmp/libticalcs2-1.1.8.orig/src/calc_84p.c...
-
currently, I using a dirty hack diff -uprN /tmp/libticalcs2-1.1.8.orig/src/calc_84p.c...
-
It's my first time to use SourceForge. I didn't know that SourceForge supports Markdown,...
-
It's my first time to use SourceForge. I didn't know that SourceForge supports Markdown,...
-
TiLP doesn't Latin (non-ASCII) chars correctly
1