From: Johann G. <Joh...@gm...> - 2008-12-30 10:10:04
Attachments:
tusb-20081230.tar.gz
|
Hi! I've done some programming with the Texas Instruments TUSB2136 uC. It is an 8051 including 8kB code RAM with a USB full-speed peripheral and a two-port USB hub. The firmware can be downloaded via USB into a pristine chip so no extra programmer or JTAG hardware is required. The TUSB3210 is very similar except that it has a no built-in USB hub (but still is an USB peripheral). For the firmware I've developed header files, a little library for the timer, UART, I2C and USB functionality and several demo programs. For the PC software there is a demo program plus a versatile command line utility for working with pristine TUSB chips which implements all vendor requests of the ROM boot code (downloading the firmware, read and write the I2C EEPROM, ...). Please find attached the source code which I'm going to release under the terms of the LGPL (and one file under GPL). I ask you to review the work. I'll appreciate your feedback. Are you interested in incorporating the files to the SDCC sources? Bye Hansi |
From: Maarten B. <sou...@ds...> - 2008-12-31 16:43:39
|
Hello Hansi, I'm not sure what to do with the library. SDCC currently has almost no library code for 8051 derivatives and I'm not sure if we want to start to. Most library functionality can be found on the SDCC OKR, on www.8052.com or on the website of the manufacturer. But I'm just one vote so let's see what others have to say about it. The headers could be included and I'm glad you already used compiler.h. But I do not like anything I see in uctypes.h. NULL, bool and the int's are all already defined in stdlib.h, stdbool.h and stdint.h. Please use those. And when compiling with --std-c89 you cannot use // comments nor 'xdata'. Please use /* */ and __xdata instead. Personally, I am totally against function implementations in header files unless 'inline'd. But inline again is C99 only. Finally, are you sure the TUSB is completely 8052 compatible? Otherwise I'd prefer not to include 8052.h and copy the relevant portions only. Nevertheless, thank you for all the work you already put in it and making it available to the public. Happy New Year! Maarten > Hi! > > I've done some programming with the Texas Instruments TUSB2136 uC. It is > an 8051 including 8kB code RAM with a USB full-speed peripheral and a > two-port USB hub. The firmware can be downloaded via USB into a pristine > chip so no extra programmer or JTAG hardware is required. The TUSB3210 > is very similar except that it has a no built-in USB hub (but still is > an USB peripheral). > > For the firmware I've developed header files, a little library for the > timer, UART, I2C and USB functionality and several demo programs. For > the PC software there is a demo program plus a versatile command line > utility for working with pristine TUSB chips which implements all vendor > requests of the ROM boot code (downloading the firmware, read and write > the I2C EEPROM, ...). > > Please find attached the source code which I'm going to release under > the terms of the LGPL (and one file under GPL). I ask you to review the > work. I'll appreciate your feedback. > > Are you interested in incorporating the files to the SDCC sources? > > Bye > Hansi > > |
From: Borut R. <bor...@si...> - 2008-12-31 17:11:10
|
Hi Hansi, I have also a concern about the license you chosen: in the embedded world LGPL is equal to GPL: it doesn't allow to statically link the (L)GPL library with the closed source code. If you want to enable linking your library with the proprietary code I propose GPL+LE - GPL plus Library (or Runtime) Exception. See http://sdcc.sourceforge.net/wiki/index.php?page=Library+License+Selection. Borut Maarten Brock wrote: > Hello Hansi, > > I'm not sure what to do with the library. SDCC currently has almost > no library code for 8051 derivatives and I'm not sure if we want to > start to. Most library functionality can be found on the SDCC OKR, > on www.8052.com or on the website of the manufacturer. But I'm just > one vote so let's see what others have to say about it. > > The headers could be included and I'm glad you already used > compiler.h. But I do not like anything I see in uctypes.h. NULL, > bool and the int's are all already defined in stdlib.h, stdbool.h > and stdint.h. Please use those. > And when compiling with --std-c89 you cannot use // comments nor > 'xdata'. Please use /* */ and __xdata instead. > Personally, I am totally against function implementations in header > files unless 'inline'd. But inline again is C99 only. > > Finally, are you sure the TUSB is completely 8052 compatible? > Otherwise I'd prefer not to include 8052.h and copy the relevant > portions only. > > Nevertheless, thank you for all the work you already put in it and > making it available to the public. > > Happy New Year! > Maarten > > >> Hi! >> >> I've done some programming with the Texas Instruments TUSB2136 uC. It is >> an 8051 including 8kB code RAM with a USB full-speed peripheral and a >> two-port USB hub. The firmware can be downloaded via USB into a pristine >> chip so no extra programmer or JTAG hardware is required. The TUSB3210 >> is very similar except that it has a no built-in USB hub (but still is >> an USB peripheral). >> >> For the firmware I've developed header files, a little library for the >> timer, UART, I2C and USB functionality and several demo programs. For >> the PC software there is a demo program plus a versatile command line >> utility for working with pristine TUSB chips which implements all vendor >> requests of the ROM boot code (downloading the firmware, read and write >> the I2C EEPROM, ...). >> >> Please find attached the source code which I'm going to release under >> the terms of the LGPL (and one file under GPL). I ask you to review the >> work. I'll appreciate your feedback. >> >> Are you interested in incorporating the files to the SDCC sources? >> >> Bye >> Hansi >> >> >> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Dave M. <mc...@ne...> - 2008-12-31 18:34:37
|
On Dec 31, 2008, at 11:43 AM, Maarten Brock wrote: > I'm not sure what to do with the library. SDCC currently has almost > no library code for 8051 derivatives and I'm not sure if we want to > start to. Most library functionality can be found on the SDCC OKR, > on www.8052.com or on the website of the manufacturer. But I'm just > one vote so let's see what others have to say about it. Just chiming in with an opinion here. I'm very happy to hear about Hansi's library, and am looking forward to using it. I don't, however, think it should be distributed with SDCC. It is not a part of the compiler or the standard C library, so it shouldn't be distributed with it. It should definitely be made available, though...it sounds VERY useful! -Dave -- Dave McGuire Port Charlotte, FL |
From: Johann G. <Joh...@gm...> - 2009-01-11 16:06:15
Attachments:
tusb-20090111.tar.gz
|
Hi! Thanks for your valuable feedback. I'll put all three answers together to one EMail and answer at once. Am Mittwoch, den 31.12.2008, 17:43 +0100 schrieb Maarten Brock: > I'm not sure what to do with the library. SDCC currently has almost > no library code for 8051 derivatives and I'm not sure if we want to > start to. Most library functionality can be found on the SDCC OKR, > on www.8052.com or on the website of the manufacturer. But I'm just > one vote so let's see what others have to say about it. Am Mittwoch, den 31.12.2008, 13:34 -0500 schrieb Dave McGuire: > Just chiming in with an opinion here. I'm very happy to hear > about Hansi's library, and am looking forward to using it. I don't, > however, think it should be distributed with SDCC. It is not a part > of the compiler or the standard C library, so it shouldn't be > distributed with it. I have to admin that I didn't look very closely at the libraries supplied with SDCC but only remembered that there were some I2C routines for the Cypress EZ-USB. But I'm happy to ship my libraries with SDCC OKR or www.8052.com. I'll submit them as soon I've integrated your feedback. Am Mittwoch, den 31.12.2008, 18:11 +0100 schrieb Borut Razem: > I have also a concern about the license you chosen: in the embedded > world LGPL is equal to GPL: it doesn't allow to statically link the > (L)GPL library with the closed source code. If you want to enable > linking your library with the proprietary code I propose GPL+LE - GPL > plus Library (or Runtime) Exception. See > http://sdcc.sourceforge.net/wiki/index.php?page=Library+License+Selection. Thanks for this suggestion. I'll modify the library to GPL+LE. Am Mittwoch, den 31.12.2008, 17:43 +0100 schrieb Maarten Brock: > The headers could be included and I'm glad you already used > compiler.h. But I do not like anything I see in uctypes.h. NULL, > bool and the int's are all already defined in stdlib.h, stdbool.h > and stdint.h. Please use those. Using 'bool' as defined by stdbool.h as a bit makes problems when using functions with a bool return type and making a pointer to such a function. typedef bool (*BoolReturnFunc_t)(); bool TestFunc() { return true } void test() { BoolReturnFunc_t FuncPtr; FuncPtr = &TestFunc; // <-- error } gives the error error 35: '&' illegal operand , address of bit variable Probably this is just a bug report. I've modified all such functions to return an uint8_t. For all others I use bool and stdbool.h. I've also removed uctypes.h and use stdint.h everywhere. Thanks for the hint that all this is already prepared. :-) > And when compiling with --std-c89 you cannot use // comments nor > 'xdata'. Please use /* */ and __xdata instead. Is the possibility to compile with --std-c89 mandatory? I tried to compile with --std-c89 and it gives the warning warning 187: ISO C90 does not support flexible array members for an "open" array element of typedef struct { ... int Field[]; } name; How can I get rid of this warning? Everything else in the library I've changed to be --std-c89 compliant. > Personally, I am totally against function implementations in header > files unless 'inline'd. But inline again is C99 only. I'm too against implementations in .h files. Where did you find those? > Finally, are you sure the TUSB is completely 8052 compatible? > Otherwise I'd prefer not to include 8052.h and copy the relevant > portions only. Yes, the datasheet says: * Integrated 8052 Microcontroller With: - 256 × 8 RAM for Internal Data - 8K × 8 RAM Code Space Available for Downloadable Firmware From Host or I2C Port. - 512 × 8 Shared RAM Used for Data Buffers and Endpoint Descriptor Blocks (EDB) - Four 8052 GPIO Ports, Ports 0,1, 2, and 3 - Master I2C Controller for External Slave Device Access - Watchdog Timer So it is a real 8052 and not an 8051. Bye Hansi |
From: Maarten B. <sou...@ds...> - 2009-01-11 18:58:23
|
Hansi, > Am Mittwoch, den 31.12.2008, 17:43 +0100 schrieb Maarten Brock: > > The headers could be included and I'm glad you already used > > compiler.h. But I do not like anything I see in uctypes.h. NULL, > > bool and the int's are all already defined in stdlib.h, stdbool.h > > and stdint.h. Please use those. > > Using 'bool' as defined by stdbool.h as a bit makes problems when using > functions with a bool return type and making a pointer to such a > function. > > typedef bool (*BoolReturnFunc_t)(); > > bool TestFunc() { > return true > } > > void test() { > BoolReturnFunc_t FuncPtr; > FuncPtr = &TestFunc; // <-- error > } > > gives the error > error 35: '&' illegal operand , address of bit variable > > Probably this is just a bug report. I've modified all such functions to > return an uint8_t. For all others I use bool and stdbool.h. I agree that this is a bug, but it can easily be circumvented by removing '&'. You don't need to take the address of a function to turn it into a function pointer. E.g. FuncPtr = TestFunc; //should give no error > I've also removed uctypes.h and use stdint.h everywhere. Thanks for the > hint that all this is already prepared. :-) > > > And when compiling with --std-c89 you cannot use // comments nor > > 'xdata'. Please use /* */ and __xdata instead. > > Is the possibility to compile with --std-c89 mandatory? > > I tried to compile with --std-c89 and it gives the warning > warning 187: ISO C90 does not support flexible array members > for an "open" array element of > typedef struct { > ... > int Field[]; > } name; > How can I get rid of this warning? You can either use 'int Field[1];' or insert a pragma to ignore the warning. But if you think you need C99 functionality and document it in the comments I doubt it would be a problem. > Everything else in the library I've changed to be --std-c89 compliant. > > > Personally, I am totally against function implementations in header > > files unless 'inline'd. But inline again is C99 only. > > I'm too against implementations in .h files. Where did you find those? Huh? All functions in tusb3210.h are definitions! To make them prototypes everything between the curly braces {} should be removed and the braces themselves too. But I suggest to remove them completely from this file. > > Finally, are you sure the TUSB is completely 8052 compatible? > > Otherwise I'd prefer not to include 8052.h and copy the relevant > > portions only. > > Yes, the datasheet says: > > * Integrated 8052 Microcontroller With: > - 256 × 8 RAM for Internal Data > - 8K × 8 RAM Code Space Available for Downloadable Firmware From > Host > or I2C Port. > - 512 × 8 Shared RAM Used for Data Buffers and Endpoint Descriptor > Blocks (EDB) > - Four 8052 GPIO Ports, Ports 0,1, 2, and 3 > - Master I2C Controller for External Slave Device Access > - Watchdog Timer > > So it is a real 8052 and not an 8051. But have you verified every sfr and every bit in it? Is every peripheral of the 8052 present in this mcu and not missing any function? Nor enhanced? This summation does not convince me. Maarten |
From: Johann G. <Joh...@gm...> - 2009-04-07 14:15:01
Attachments:
tusb-20090407.tar.gz
|
Hi! Finally I come back to your suggestions. Am Sonntag, den 11.01.2009, 19:58 +0100 schrieb Maarten Brock: > Hansi, > > > Am Mittwoch, den 31.12.2008, 17:43 +0100 schrieb Maarten Brock: > > > The headers could be included and I'm glad you already used > > > compiler.h. But I do not like anything I see in uctypes.h. NULL, > > > bool and the int's are all already defined in stdlib.h, stdbool.h > > > and stdint.h. Please use those. > > > > Using 'bool' as defined by stdbool.h as a bit makes problems when using > > functions with a bool return type and making a pointer to such a > > function. > > > > typedef bool (*BoolReturnFunc_t)(); > > > > bool TestFunc() { > > return true > > } > > > > void test() { > > BoolReturnFunc_t FuncPtr; > > FuncPtr = &TestFunc; // <-- error > > } > > > > gives the error > > error 35: '&' illegal operand , address of bit variable > > > > Probably this is just a bug report. I've modified all such functions to > > return an uint8_t. For all others I use bool and stdbool.h. > > I agree that this is a bug, but it can easily be circumvented by > removing '&'. You don't need to take the address of a function to > turn it into a function pointer. E.g. > > FuncPtr = TestFunc; //should give no error Ok, I converted it back to a bool return type and removed the '&'. > > I've also removed uctypes.h and use stdint.h everywhere. Thanks for the > > hint that all this is already prepared. :-) > > > > > And when compiling with --std-c89 you cannot use // comments nor > > > 'xdata'. Please use /* */ and __xdata instead. > > > > Is the possibility to compile with --std-c89 mandatory? > > > > I tried to compile with --std-c89 and it gives the warning > > warning 187: ISO C90 does not support flexible array members > > for an "open" array element of > > typedef struct { > > ... > > int Field[]; > > } name; > > How can I get rid of this warning? > > You can either use 'int Field[1];' or insert a pragma to ignore the > warning. But if you think you need C99 functionality and document it > in the comments I doubt it would be a problem. Decided to compile everything with --std-c99 and added a comment to the respective file. > > Everything else in the library I've changed to be --std-c89 compliant. > > > > > Personally, I am totally against function implementations in header > > > files unless 'inline'd. But inline again is C99 only. > > > > I'm too against implementations in .h files. Where did you find those? > > Huh? All functions in tusb3210.h are definitions! To make them > prototypes everything between the curly braces {} should be removed > and the braces themselves too. But I suggest to remove them > completely from this file. Oops, I missed these. Ok, moved them to lib/usb.{c,h}. > > > Finally, are you sure the TUSB is completely 8052 compatible? > > > Otherwise I'd prefer not to include 8052.h and copy the relevant > > > portions only. > > > > Yes, the datasheet says: > > > > * Integrated 8052 Microcontroller With: > > - 256 × 8 RAM for Internal Data > > - 8K × 8 RAM Code Space Available for Downloadable Firmware From > > Host > > or I2C Port. > > - 512 × 8 Shared RAM Used for Data Buffers and Endpoint Descriptor > > Blocks (EDB) > > - Four 8052 GPIO Ports, Ports 0,1, 2, and 3 > > - Master I2C Controller for External Slave Device Access > > - Watchdog Timer > > > > So it is a real 8052 and not an 8051. > > But have you verified every sfr and every bit in it? Is every > peripheral of the 8052 present in this mcu and not missing any > function? Nor enhanced? This summation does not convince me. I'm not able to check this but there is a FAQ entry at TI's homepage http://focus.ti.com/lit/an/slla157/slla157.pdf which says > Can you tell us what micro controller it is based on? > Can you give us a > reference for it to make the memory addressing a bit easier? > > Mentor Graphics 8052. Try > www.intel.com/design/MCS51/MANUALS/272383.htm for reference. The user > is expected to be familiar with the 8052 MCU. So, I'm pretty confident this is a real 8052. Please find attached the current version. Bye Hansi |