Re: Pull Request Process
Hi Andrew, On Wed, Nov 29, 2023 at 3:27 AM Andrew O'Mahony wrote: > > Hello, > > I've just joined the group and would like to just make sure I > understand the patching process: > > I have cloned the code into my own repo, made my changes, and can > generate a pull request. > > Do I put the pull request in this group? Do I need a specific subject line? You can either send your PR to this mailing list or as the majority of us does, send a patch using the "git send-email" command [1]. [1] https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/ Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] FT4232: show mode for both C and D channels
On Tue, Aug 29, 2023 at 10:51 AM wrote:
>
> From: Yegor Yefremov
>
> ---
> src/ftdi.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/ftdi.c b/src/ftdi.c
> index 0a7fb27..e16816e 100644
> --- a/src/ftdi.c
> +++ b/src/ftdi.c
> @@ -3881,6 +3881,13 @@ int ftdi_eeprom_decode(struct ftdi_context *ftdi, int
> verbose)
> channel_mode[eeprom->channel_b_type],
> (eeprom->channel_b_driver)?" VCP":"",
> (eeprom->high_current_b)?" High Current IO":"");
> +if (ftdi->type == TYPE_4232H)
> +{
> +fprintf(stdout,"Channel C has Mode UART%s\n",
> +(eeprom->channel_c_driver)?" VCP":"");
> +fprintf(stdout,"Channel D has Mode UART%s\n",
> +(eeprom->channel_d_driver)?" VCP":"");
> +}
> if (((ftdi->type == TYPE_BM) || (ftdi->type == TYPE_2232C)) &&
> eeprom->use_usb_version)
> fprintf(stdout,"Use explicit USB Version
> %04x\n",eeprom->usb_version);
Btw, should we also show channel B driver option for FT2232C?
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
FT4232: Legacy port name and PnP fields
As stated here [1], ft_prog doesn't add these fields when programming the default values. But when I use their C# bindings and initialize my eeprom variable as FTDI.FT4232H_EEPROM_STRUCTURE eeprom = new FTDI.FT4232H_EEPROM_STRUCTURE() I get all these fields programmed for the FT4232 chip. What would be the best solution to write these fields on demand? [1] http://developer.intra2net.com/git/?p=libftdi;a=blob;f=src/ftdi.c;h=0a7fb274dd927d45615bbd26c11e950155164e46;hb=HEAD#l3118 Regards, Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: EEPROM: calculate user_data_addr
On Thu, Aug 3, 2023 at 11:18 AM Yegor Yefremov wrote: > > On Tue, Aug 1, 2023 at 11:44 AM Yegor Yefremov > wrote: > > > > On Mon, Jul 31, 2023 at 1:53 PM Yegor Yefremov > > wrote: > > > > > > I want to write ca. 25 bytes as user data (my FTDI chips are FT2232, > > > FT4232 and FTX). What is my strategy to calculate the user_data_addr? > > > > > > If I set EEPROM defaults via ftdi_eeprom_initdefaults() providing only > > > the product string. Then I perform ftdi_eeprom_build() and use its > > > return value to calculate the user_data_addr like: eeprom->size - > > > user_area_size > > > > > > But this doesn't work as with 128 byte EEPROM (FT2232/4232), the > > > free_end is 26 and thus I get: > > > > > > "Warning, user data overlaps the strings area!" > > > > > > How should EEWriteUserArea() look like in libftdi1? > > > > > > And what about returning an error instead of printing a warning when > > > the user data overlaps with the strings or generated data? > > > > After adding debug output, I can see that free_start for the > > TYPE_2232C chip is at 0x15 and free_end at 0x16. And this doesn't make > > much sense as it is much smaller than user_area_size value. > > > > According to the Application Note AN_121 [1], the user area starts > > after the SerialNumber string (at least for the 128 bytes EEPROMs, > > 256 and 512 bytes EEPROM have another approach). Unfortunately, I > > still cannot find the user area description for the FT-X series. > > > > FT_71 for the D2XX.dll describes the following routines handling > > the user area: > > > > FT_EE_UASize() > > FT_EE_UARead() > > FT_EE_UAWrite() > > > > This would be useful to have them in libftdi. > > > > [1] > > https://www.ftdichip.com/Documents/AppNotes/AN_121_FTDI_Device_EEPROM_User_Area_Usage.pdf > > [2] > > https://ftdichip.com/wp-content/uploads/2020/08/D2XX_Programmers_GuideFT_71.pdf > > I have sent two patches [1], [2] that fix the issue for me. The > question is, whether we should spare the byte after "output[i & > eeprom_size_mask] = eeprom->is_not_pnp" for better alignment. Variable > naming and return value of eeprom_build() should be also reworked to > correspond to the FTDI's application note. > > What do you think about it? > > [1] http://developer.intra2net.com/mailarchive/html/libftdi/2023/msg00018.html > [2] http://developer.intra2net.com/mailarchive/html/libftdi/2023/msg00019.html I finally found FTX memory layout [1] in AN_201. It differs much from the one with an external EEPROM. Compared to the latter, it has fixed areas. For the first implementation, it will be sufficient to implement User Area 1. [1] https://ftdichip.com/wp-content/uploads/2020/08/AN_201_FT-X-MTP-Memory-Configuration.pdf#page=7 -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: EEPROM: calculate user_data_addr
On Tue, Aug 1, 2023 at 11:44 AM Yegor Yefremov wrote: > > On Mon, Jul 31, 2023 at 1:53 PM Yegor Yefremov > wrote: > > > > I want to write ca. 25 bytes as user data (my FTDI chips are FT2232, > > FT4232 and FTX). What is my strategy to calculate the user_data_addr? > > > > If I set EEPROM defaults via ftdi_eeprom_initdefaults() providing only > > the product string. Then I perform ftdi_eeprom_build() and use its > > return value to calculate the user_data_addr like: eeprom->size - > > user_area_size > > > > But this doesn't work as with 128 byte EEPROM (FT2232/4232), the > > free_end is 26 and thus I get: > > > > "Warning, user data overlaps the strings area!" > > > > How should EEWriteUserArea() look like in libftdi1? > > > > And what about returning an error instead of printing a warning when > > the user data overlaps with the strings or generated data? > > After adding debug output, I can see that free_start for the > TYPE_2232C chip is at 0x15 and free_end at 0x16. And this doesn't make > much sense as it is much smaller than user_area_size value. > > According to the Application Note AN_121 [1], the user area starts > after the SerialNumber string (at least for the 128 bytes EEPROMs, > 256 and 512 bytes EEPROM have another approach). Unfortunately, I > still cannot find the user area description for the FT-X series. > > FT_71 for the D2XX.dll describes the following routines handling > the user area: > > FT_EE_UASize() > FT_EE_UARead() > FT_EE_UAWrite() > > This would be useful to have them in libftdi. > > [1] > https://www.ftdichip.com/Documents/AppNotes/AN_121_FTDI_Device_EEPROM_User_Area_Usage.pdf > [2] > https://ftdichip.com/wp-content/uploads/2020/08/D2XX_Programmers_GuideFT_71.pdf I have sent two patches [1], [2] that fix the issue for me. The question is, whether we should spare the byte after "output[i & eeprom_size_mask] = eeprom->is_not_pnp" for better alignment. Variable naming and return value of eeprom_build() should be also reworked to correspond to the FTDI's application note. What do you think about it? [1] http://developer.intra2net.com/mailarchive/html/libftdi/2023/msg00018.html [2] http://developer.intra2net.com/mailarchive/html/libftdi/2023/msg00019.html Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: EEPROM: calculate user_data_addr
On Mon, Jul 31, 2023 at 1:53 PM Yegor Yefremov wrote: > > I want to write ca. 25 bytes as user data (my FTDI chips are FT2232, > FT4232 and FTX). What is my strategy to calculate the user_data_addr? > > If I set EEPROM defaults via ftdi_eeprom_initdefaults() providing only > the product string. Then I perform ftdi_eeprom_build() and use its > return value to calculate the user_data_addr like: eeprom->size - > user_area_size > > But this doesn't work as with 128 byte EEPROM (FT2232/4232), the > free_end is 26 and thus I get: > > "Warning, user data overlaps the strings area!" > > How should EEWriteUserArea() look like in libftdi1? > > And what about returning an error instead of printing a warning when > the user data overlaps with the strings or generated data? After adding debug output, I can see that free_start for the TYPE_2232C chip is at 0x15 and free_end at 0x16. And this doesn't make much sense as it is much smaller than user_area_size value. According to the Application Note AN_121 [1], the user area starts after the SerialNumber string (at least for the 128 bytes EEPROMs, 256 and 512 bytes EEPROM have another approach). Unfortunately, I still cannot find the user area description for the FT-X series. FT_71 for the D2XX.dll describes the following routines handling the user area: FT_EE_UASize() FT_EE_UARead() FT_EE_UAWrite() This would be useful to have them in libftdi. [1] https://www.ftdichip.com/Documents/AppNotes/AN_121_FTDI_Device_EEPROM_User_Area_Usage.pdf [2] https://ftdichip.com/wp-content/uploads/2020/08/D2XX_Programmers_GuideFT_71.pdf Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
EEPROM: calculate user_data_addr
I want to write ca. 25 bytes as user data (my FTDI chips are FT2232, FT4232 and FTX). What is my strategy to calculate the user_data_addr? If I set EEPROM defaults via ftdi_eeprom_initdefaults() providing only the product string. Then I perform ftdi_eeprom_build() and use its return value to calculate the user_data_addr like: eeprom->size - user_area_size But this doesn't work as with 128 byte EEPROM (FT2232/4232), the free_end is 26 and thus I get: "Warning, user data overlaps the strings area!" How should EEWriteUserArea() look like in libftdi1? And what about returning an error instead of printing a warning when the user data overlaps with the strings or generated data? Regards, Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: ftdi_eeprom: setting cha_vcp=false has no effect on generated eeprom binary
Hi Thomas, On Sat, May 16, 2020 at 9:53 PM Yegor Yefremov wrote: > > Hi Thomas, > > On Thu, May 14, 2020 at 11:21 PM Thomas Jarosch > wrote: > > > > Hi Yegor, > > > > You wrote on Mon, Apr 13, 2020 at 11:32:47PM +0200: > > > I think the decoding of boolean bit fields all need to be changed > > > to "!!(bit test)", so the in memory value will truely be one or zero. > > > > > > Then we can apply changes like this everywhere: > > > > > > -if ( eeprom->high_current_b == HIGH_CURRENT_DRIVE) > > > +if (eeprom->high_current_b) > > > output[0x01] |= HIGH_CURRENT_DRIVE; > > > > I've bit the bullet and fixed all eeprom boolean bit fields on the branch > > > > origin/ftdi-eeprom-fix-bitflag-handling > > > > > > @Yegor: I would appreciate it if you could review it. > > I triple reviewed it on my side not to break anything, > > but may be I missed something *fingers crossed* > > So far it looks goods to me aside from a typo in the last commit log: > > "On TYPE_R 00.3 set mean D2XX, on other devices VCP" -> s/mean/means > > I'll try to make a test with FT-X chip and let you know my results. The tests with FTX were successful. Regards, Yegor > > > > > > Additionally I've seen that the handling of the VCP driver field > > for TYPE_R chips was not inverted properly, see the extra commit. > > > > > > A colleague recently recommended a new code diff tool to me called "delta": > > https://github.com/dandavison/delta > > > > Here's how I run it: > > > > git diff origin/master..origin/ftdi-eeprom-fix-bitflag-handling \ > > |delta --dark --keep-plus-minus-markers > > > > > > It makes reading subtle code changes more obvious to me. > > Never heard about delta but I like its approach. Thanks. It would be > great if tig would have this functionality. > > Cheers, > Yegor > > > Cheers, > > Tom -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: ftdi_eeprom: setting cha_vcp=false has no effect on generated eeprom binary
Hi Thomas, On Thu, May 14, 2020 at 11:21 PM Thomas Jarosch wrote: > > Hi Yegor, > > You wrote on Mon, Apr 13, 2020 at 11:32:47PM +0200: > > I think the decoding of boolean bit fields all need to be changed > > to "!!(bit test)", so the in memory value will truely be one or zero. > > > > Then we can apply changes like this everywhere: > > > > -if ( eeprom->high_current_b == HIGH_CURRENT_DRIVE) > > +if (eeprom->high_current_b) > > output[0x01] |= HIGH_CURRENT_DRIVE; > > I've bit the bullet and fixed all eeprom boolean bit fields on the branch > > origin/ftdi-eeprom-fix-bitflag-handling > > > @Yegor: I would appreciate it if you could review it. > I triple reviewed it on my side not to break anything, > but may be I missed something *fingers crossed* So far it looks goods to me aside from a typo in the last commit log: "On TYPE_R 00.3 set mean D2XX, on other devices VCP" -> s/mean/means I'll try to make a test with FT-X chip and let you know my results. > > > Additionally I've seen that the handling of the VCP driver field > for TYPE_R chips was not inverted properly, see the extra commit. > > > A colleague recently recommended a new code diff tool to me called "delta": > https://github.com/dandavison/delta > > Here's how I run it: > > git diff origin/master..origin/ftdi-eeprom-fix-bitflag-handling \ > |delta --dark --keep-plus-minus-markers > > > It makes reading subtle code changes more obvious to me. Never heard about delta but I like its approach. Thanks. It would be great if tig would have this functionality. Cheers, Yegor > Cheers, > Tom -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: Build python bindings for multiple python versions
Hi Åke, no that I know of, but you can do this sequentially like in this Debian package [1]. For each build, just specify the required paths to the related Python version. [1] https://sources.debian.org/src/libftdi1/1.4-2/debian/rules/ Yegor On Sun, Apr 5, 2020 at 12:07 PM Åke Rehnman wrote: > > Hello all, > > are there any provisions for building the python bindings for both > python 2.7 and 3.6 version at the same time? > > BR > > /Ake > > > -- > libftdi - see http://www.intra2net.com/en/developer/libftdi for details. > To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com > -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] Ignore tags file
Hi Thomas, On Fri, Feb 7, 2020 at 4:57 PM Yegor Yefremov wrote: > > Hi Thomas, > > On Fri, Feb 7, 2020 at 4:50 PM Thomas Jarosch > wrote: > > > > Hi Yegor, > > > > You wrote on Thu, Feb 06, 2020 at 02:51:27PM +0100: > > > Any plans for 1.5-rc1? > > > > yesterday :D > > > > I'm in the middle of an update release crunch period, it will be done by > > March. > > (Microsoft will auto-enable LDAP request signing via a Windows update > > in March, so my employer's product must be ready for it). > > Sounds very important and complicated :-) > > > After that sounds good, it's about time! I made a note about it. > > I'm trying to add libftdi1 to Buildroot's CI infrastructure. So that > we can spot different sorts of problems earlier than the users :-) FYI: libftdi1 is already covered in BR's CI [1]. [1] https://git.busybox.net/buildroot/tree/support/testing/tests/package/test_libftdi1.py Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] Ignore tags file
Hi Thomas, On Fri, Feb 7, 2020 at 4:50 PM Thomas Jarosch wrote: > > Hi Yegor, > > You wrote on Thu, Feb 06, 2020 at 02:51:27PM +0100: > > Any plans for 1.5-rc1? > > yesterday :D > > I'm in the middle of an update release crunch period, it will be done by > March. > (Microsoft will auto-enable LDAP request signing via a Windows update > in March, so my employer's product must be ready for it). Sounds very important and complicated :-) > After that sounds good, it's about time! I made a note about it. I'm trying to add libftdi1 to Buildroot's CI infrastructure. So that we can spot different sorts of problems earlier than the users :-) A nice weekend to you too! Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] Ignore tags file
Hi Thomas, On Thu, Feb 6, 2020 at 2:41 PM Thomas Jarosch wrote: > > Hi Yegor, > > You wrote on Thu, Feb 06, 2020 at 02:37:09PM +0100: > > From: Yegor Yefremov > > > > Signed-off-by: Yegor Yefremov > > --- > > .gitignore | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/.gitignore b/.gitignore > > index d05881d..98a50e9 100644 > > --- a/.gitignore > > +++ b/.gitignore > > @@ -51,3 +51,6 @@ CMakeFiles > > # Misc. binaries > > *.dylib > > opt > > + > > +# ctags > > +tags > > applied :) Thanks. Any plans for 1.5-rc1? Regards, Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] Fix typos
On Mon, Jan 20, 2020 at 5:57 PM Thomas Jarosch wrote: > > Hi Yegor, > > You wrote on Thu, Jan 16, 2020 at 08:44:48AM +0100: > > > From: Yegor Yefremov > > > > > > Signed-off-by: Yegor Yefremov > > > --- > > > cmake/FindConfuse.cmake | 2 +- > > > examples/async.c| 4 ++-- > > > examples/serial_test.c | 2 +- > > > examples/stream_test.c | 4 ++-- > > > ftdipp/CMakeLists.txt | 2 +- > > > ftdipp/ftdi.cpp | 2 +- > > > > I have found out that both ftdipp/ftdi.cpp and ftdipp/ftdi.hpp are > > UTF-8 encoded. How can we fix this? > > I've applied your patch, thanks a lot. > > Is there a problem with UTF-8 encoded files? Does some tool complain? git send-email pointed me to the fact that the patch was UTF-8 coded. That's all. Yegor > I don't mind UTF-8 too much, in fact I embrace it > to keep umlauts or other non-ASCII chars intact. > > Cheers, > Thomas > > -- > libftdi - see http://www.intra2net.com/en/developer/libftdi for details. > To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com > -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] Fix typos
Hi Thomas,
On Thu, Jan 16, 2020 at 8:42 AM wrote:
>
> From: Yegor Yefremov
>
> Signed-off-by: Yegor Yefremov
> ---
> cmake/FindConfuse.cmake | 2 +-
> examples/async.c| 4 ++--
> examples/serial_test.c | 2 +-
> examples/stream_test.c | 4 ++--
> ftdipp/CMakeLists.txt | 2 +-
> ftdipp/ftdi.cpp | 2 +-
I have found out that both ftdipp/ftdi.cpp and ftdipp/ftdi.hpp are
UTF-8 encoded. How can we fix this?
Yegor
> python/examples/cbus.py | 2 +-
> src/CMakeLists.txt | 2 +-
> src/ftdi.c | 2 +-
> src/ftdi_i.h| 6 +++---
> 10 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/cmake/FindConfuse.cmake b/cmake/FindConfuse.cmake
> index ab25eef..f6af7d5 100644
> --- a/cmake/FindConfuse.cmake
> +++ b/cmake/FindConfuse.cmake
> @@ -6,7 +6,7 @@
> # CONFUSE_INCLUDE_DIR - where to find confuse.h
> # CONFUSE_INCLUDE_DIRS - confuse includes
> # CONFUSE_LIBRARY - where to find the Confuse library
> -# CONFUSE_LIBRARIES - aditional libraries
> +# CONFUSE_LIBRARIES - additional libraries
> # CONFUSE_ROOT_DIR - root dir (ex. /usr/local)
>
>
> #=
> diff --git a/examples/async.c b/examples/async.c
> index 18989c1..241bb7f 100644
> --- a/examples/async.c
> +++ b/examples/async.c
> @@ -3,7 +3,7 @@
> This program is distributed under the GPL, version 2
> */
>
> -/* This programm switches to MPSSE mode, and sets and then reads back
> +/* This program switches to MPSSE mode, and sets and then reads back
> * the high byte 3 times with three different values.
> * The expected read values are hard coded in ftdi_init
> * with 0x00, 0x55 and 0xaa
> @@ -167,7 +167,7 @@ int main(int argc, char **argv)
> }
> }
> if (i < 1) {
> -printf("Async read unsuccessfull\n");
> +printf("Async read unsuccessful\n");
> }
> }
> printf("Read %02x %02x %02x\n", data[0], data[1], data[2]);
> diff --git a/examples/serial_test.c b/examples/serial_test.c
> index 289dd97..0631504 100644
> --- a/examples/serial_test.c
> +++ b/examples/serial_test.c
> @@ -134,7 +134,7 @@ int main(int argc, char **argv)
> *
> * TODO: Make these parameters settable from the command line
> *
> - * Parameters are choosen that sending a continous stream of 0x55
> + * Parameters are chosen that sending a continuous stream of 0x55
> * should give a square wave
> *
> */
> diff --git a/examples/stream_test.c b/examples/stream_test.c
> index 43abea9..10e0977 100644
> --- a/examples/stream_test.c
> +++ b/examples/stream_test.c
> @@ -10,7 +10,7 @@
> * 3* uint32_t dont_care
> *
> * After start, data will be read in streaming until the program is aborted
> - * Progess information wil be printed out
> + * Progress information will be printed out
> * If a filename is given on the command line, the data read will be
> * written to that file
> *
> @@ -52,7 +52,7 @@ usage(const char *argv0)
> "[-n] don't check for special block structure\n"
> "\n"
> "If some filename is given, write data read to that file\n"
> - "Progess information is printed each second\n"
> + "Progress information is printed each second\n"
> "Abort with ^C\n"
> "\n"
> "Options:\n"
> diff --git a/ftdipp/CMakeLists.txt b/ftdipp/CMakeLists.txt
> index a9e3418..fac5bcc 100644
> --- a/ftdipp/CMakeLists.txt
> +++ b/ftdipp/CMakeLists.txt
> @@ -14,7 +14,7 @@ include_directories(${Boost_INCLUDE_DIRS})
> # Shared library
> add_library(ftdipp1 SHARED ${cpp_sources})
>
> -math(EXPR VERSION_FIXUP "${MAJOR_VERSION} + 1")# Compatiblity with
> previous releases
> +math(EXPR VERSION_FIXUP "${MAJOR_VERSION} + 1")# Compatibility with
> previous releases
> set_target_properties(ftdipp1 PROPERTIES VERSION
> ${VERSION_FIXUP}.${MINOR_VERSION}.0 SOVERSION 3)
>
> # Prevent clobbering each other during the build
> diff --git a/ftdipp/ftdi.cpp b/ftdipp/ftdi.cpp
> index dd777be..f82b865 100644
> --- a/ftdipp/ftdi.cpp
> +++ b/ftdipp/ftdi.cpp
> @@ -1,5 +1,5 @@
> /***
> - ftdi.cpp - C++ wraper for libftdi
> + ftdi.cpp - C++ wrapper for libftdi
> ---
> begin: Mon Oct 13 2008
> cop
Re: [PATCH] libftdi: pass eeprom strings as const
On Tue, Jan 7, 2020 at 5:18 PM Dan Dedrick wrote:
>
> These strings are not modified and it doesn't make sense that they ever
> would be. Setting these as const ensures that they will not be modified
> and allows const strings to be passed in without special manipulation.
>
> Specifically a call like the following will fail to compile:
> ftdi_eeprom_set_strings(&ftdi, "foo", "bar", "abc123");
>
> The error will look something like this:
> error: ISO C++ forbids converting a string constant to ‘char*’
> [-Werror=write-strings]
> ---
> src/ftdi.c | 4 ++--
> src/ftdi.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/ftdi.c b/src/ftdi.c
> index 988a9f1..9495fb5 100644
> --- a/src/ftdi.c
> +++ b/src/ftdi.c
> @@ -2724,8 +2724,8 @@ int ftdi_eeprom_initdefaults(struct ftdi_context *ftdi,
> char * manufacturer,
> return 0;
> }
>
> -int ftdi_eeprom_set_strings(struct ftdi_context *ftdi, char * manufacturer,
> -char * product, char * serial)
> +int ftdi_eeprom_set_strings(struct ftdi_context *ftdi, const char *
> manufacturer,
> +const char * product, const char * serial)
> {
> struct ftdi_eeprom *eeprom;
>
> diff --git a/src/ftdi.h b/src/ftdi.h
> index 8fcf719..7addeb9 100644
> --- a/src/ftdi.h
> +++ b/src/ftdi.h
> @@ -544,8 +544,8 @@ extern "C"
> char *manufacturer, int mnf_len,
> char *product, int prod_len,
> char *serial, int serial_len);
> -int ftdi_eeprom_set_strings(struct ftdi_context *ftdi, char *
> manufacturer,
> -char * product, char * serial);
> +int ftdi_eeprom_set_strings(struct ftdi_context *ftdi, const char *
> manufacturer,
> +const char * product, const char * serial);
>
> int ftdi_usb_open(struct ftdi_context *ftdi, int vendor, int product);
> int ftdi_usb_open_desc(struct ftdi_context *ftdi, int vendor, int
> product,
> --
> 2.7.4
Good catch.
Regards,
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] swig: improve indentation
Hi Thomas,
I've tested the patch with my software and so far everything seems to
be working.
What is your schedule for a new release?
Cheers,
Yegor
On Thu, Aug 22, 2019 at 3:48 PM Yegor Yefremov
wrote:
>
> Hi Thomas,
>
> this patch is only compile tested.
>
> Regards,
> Yegor
>
> On Thu, Aug 22, 2019 at 3:47 PM wrote:
> >
> > From: Yegor Yefremov
> >
> > Fixes -Wmisleading-indentation warnings.
> > ---
> > python/ftdi1.i | 14 --
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/python/ftdi1.i b/python/ftdi1.i
> > index f397f84..8b179f9 100644
> > --- a/python/ftdi1.i
> > +++ b/python/ftdi1.i
> > @@ -92,7 +92,12 @@ char * str2charp_size(PyObject* pyObj, int * size)
> > %enddef
> > %feature("autodoc", ftdi_read_data_docstring) ftdi_read_data;
> > %typemap(in,numinputs=1) (unsigned char *buf, int size) %{ $2 =
> > PyInt_AsLong($input);$1 = (unsigned char*)malloc($2*sizeof(char)); %}
> > -%typemap(argout) (unsigned char *buf, int size) %{ if(result<0) $2=0;
> > $result = SWIG_Python_AppendOutput($result, charp2str((char*)$1, $2));
> > free($1); %}
> > +%typemap(argout) (unsigned char *buf, int size) %{
> > +if(result<0)
> > +$2=0;
> > +$result = SWIG_Python_AppendOutput($result, charp2str((char*)$1,
> > $2));
> > +free($1);
> > +%}
> > int ftdi_read_data(struct ftdi_context *ftdi, unsigned char *buf, int
> > size);
> > %clear (unsigned char *buf, int size);
> >
> > @@ -132,7 +137,12 @@ char * str2charp_size(PyObject* pyObj, int * size)
> > %clear int* value;
> >
> > %typemap(in,numinputs=1) (unsigned char *buf, int size) %{ $2 =
> > PyInt_AsLong($input);$1 = (unsigned char*)malloc($2*sizeof(char)); %}
> > -%typemap(argout) (unsigned char *buf, int size) %{ if(result<0) $2=0;
> > $result = SWIG_Python_AppendOutput($result, charp2str((char*)$1, $2));
> > free($1); %}
> > +%typemap(argout) (unsigned char *buf, int size) %{
> > +if(result<0)
> > +$2=0;
> > +$result = SWIG_Python_AppendOutput($result, charp2str((char*)$1,
> > $2));
> > +free($1);
> > +%}
> > int ftdi_get_eeprom_buf(struct ftdi_context *ftdi, unsigned char *
> > buf, int size);
> > %clear (unsigned char *buf, int size);
> >
> > --
> > 2.17.0
> >
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] swig: improve indentation
Hi Thomas,
this patch is only compile tested.
Regards,
Yegor
On Thu, Aug 22, 2019 at 3:47 PM wrote:
>
> From: Yegor Yefremov
>
> Fixes -Wmisleading-indentation warnings.
> ---
> python/ftdi1.i | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/python/ftdi1.i b/python/ftdi1.i
> index f397f84..8b179f9 100644
> --- a/python/ftdi1.i
> +++ b/python/ftdi1.i
> @@ -92,7 +92,12 @@ char * str2charp_size(PyObject* pyObj, int * size)
> %enddef
> %feature("autodoc", ftdi_read_data_docstring) ftdi_read_data;
> %typemap(in,numinputs=1) (unsigned char *buf, int size) %{ $2 =
> PyInt_AsLong($input);$1 = (unsigned char*)malloc($2*sizeof(char)); %}
> -%typemap(argout) (unsigned char *buf, int size) %{ if(result<0) $2=0;
> $result = SWIG_Python_AppendOutput($result, charp2str((char*)$1, $2));
> free($1); %}
> +%typemap(argout) (unsigned char *buf, int size) %{
> +if(result<0)
> +$2=0;
> +$result = SWIG_Python_AppendOutput($result, charp2str((char*)$1,
> $2));
> +free($1);
> +%}
> int ftdi_read_data(struct ftdi_context *ftdi, unsigned char *buf, int
> size);
> %clear (unsigned char *buf, int size);
>
> @@ -132,7 +137,12 @@ char * str2charp_size(PyObject* pyObj, int * size)
> %clear int* value;
>
> %typemap(in,numinputs=1) (unsigned char *buf, int size) %{ $2 =
> PyInt_AsLong($input);$1 = (unsigned char*)malloc($2*sizeof(char)); %}
> -%typemap(argout) (unsigned char *buf, int size) %{ if(result<0) $2=0;
> $result = SWIG_Python_AppendOutput($result, charp2str((char*)$1, $2));
> free($1); %}
> +%typemap(argout) (unsigned char *buf, int size) %{
> +if(result<0)
> +$2=0;
> +$result = SWIG_Python_AppendOutput($result, charp2str((char*)$1,
> $2));
> +free($1);
> +%}
> int ftdi_get_eeprom_buf(struct ftdi_context *ftdi, unsigned char * buf,
> int size);
> %clear (unsigned char *buf, int size);
>
> --
> 2.17.0
>
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: SWIG: Python: compiler warnings
On Tue, Aug 6, 2019 at 10:43 AM Thomas Jarosch
wrote:
>
> Hi Yegor,
>
> You wrote on Mon, Aug 05, 2019 at 03:46:16PM +0200:
> > I get following compiler warnings when compiling libftdi Python
> > bindings with gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1):
> >
> > Scanning dependencies of target _ftdi1
> > [ 22%] Building C object
> > python/CMakeFiles/_ftdi1.dir/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c.o
> > /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:
> > In function ‘_wrap_read_data’:
> > /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:3842:3:
> > warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
> >if(result<0) arg3=0; resultobj =
> > SWIG_Python_AppendOutput(resultobj, charp2str((char*)arg2, arg3));
> > free(arg2);
> >^~
> > /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:3842:24:
> > note: ...this statement, but the latter is misleadingly indented as if
> > it were guarded by the ‘if’
> >if(result<0) arg3=0; resultobj =
> > SWIG_Python_AppendOutput(resultobj, charp2str((char*)arg2, arg3));
> > free(arg2);
> > ^
> > /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:
> > In function ‘_wrap_get_eeprom_buf’:
> > /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:4084:3:
> > warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
> >if(result<0) arg3=0; resultobj =
> > SWIG_Python_AppendOutput(resultobj, charp2str((char*)arg2, arg3));
> > free(arg2);
> >^~
> > /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:4084:24:
> > note: ...this statement, but the latter is misleadingly indented as if
> > it were guarded by the ‘if’
> >if(result<0) arg3=0; resultobj =
> > SWIG_Python_AppendOutput(resultobj, charp2str((char*)arg2, arg3));
> > free(arg2);
> > ^
> >
> > The code looking wired indeed i.e. either without parenthesis or
> > indentation.
>
> indeed, this auto-generated code looks very hard to read. May be there is an
> option in SWIG to output "beautified" code, it will be the same on the machine
> level anyway.
>
> I also quickly grepped for "charp2":
> ftdi1.i:inline PyObject* charp2str(const char *v_, long len)
>
> so it should be in the generated code.
The code in question is not auto-generated. It is part of the python.ftdi1.i.
%typemap(argout) (unsigned char *buf, int size) %{ if(result<0) $2=0;
$result = SWIG_Python_AppendOutput($result, charp2str((char*)$1, $2));
free($1); %}
> On a different note, I'm back in libftdi business after guiding a mass scale
> kernel upgrade from 3.14 to 4.19 on way too many different machines.
> Let's try to put out a libftdi release in August finally.
This would be great!
Btw I have an issue, I mentioned in this e-mail [1]. Are you using buildroot?
So far I could find a qemu target in buildroot where I can easily
change the compiler and test whether I can import ftdi1. So far I have
following combinations:
GCC 7.x external toolchain: failure
GCC 8x built via buildroot: failure
GCC 5.x built via buildroot: OK
Buildroot uses SWIG 3.0.12.
A defconfig for the failed import:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
BR2_SYSTEM_DHCP="eth0"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="vexpress-v2p-ca9"
BR2_PACKAGE_PYTHON=y
BR2_PACKAGE_LIBFTDI1=y
BR2_PACKAGE_LIBFTDI1_PYTHON_BINDINGS=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
BR2_PACKAGE_HOST_QEMU=y
BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
[1] http://developer.intra2net.com/mailarchive/html/libftdi/2019/msg00038.html
Cheers,
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
SWIG: Python: compiler warnings
I get following compiler warnings when compiling libftdi Python bindings with gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1): Scanning dependencies of target _ftdi1 [ 22%] Building C object python/CMakeFiles/_ftdi1.dir/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c.o /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c: In function ‘_wrap_read_data’: /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:3842:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if(result<0) arg3=0; resultobj = SWIG_Python_AppendOutput(resultobj, charp2str((char*)arg2, arg3)); free(arg2); ^~ /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:3842:24: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ if(result<0) arg3=0; resultobj = SWIG_Python_AppendOutput(resultobj, charp2str((char*)arg2, arg3)); free(arg2); ^ /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c: In function ‘_wrap_get_eeprom_buf’: /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:4084:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if(result<0) arg3=0; resultobj = SWIG_Python_AppendOutput(resultobj, charp2str((char*)arg2, arg3)); free(arg2); ^~ /home/user/Documents/versioned/libftdi/build/python/CMakeFiles/_ftdi1.dir/ftdi1PYTHON_wrap.c:4084:24: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ if(result<0) arg3=0; resultobj = SWIG_Python_AppendOutput(resultobj, charp2str((char*)arg2, arg3)); free(arg2); ^ The code looking wired indeed i.e. either without parenthesis or indentation. Regards, Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: Python bindings - final solution
On Thu, Feb 7, 2019 at 9:13 PM Berni Joss wrote: > > Both python bindings for libftdi 1.2 and 1.4 work fine for me with python > 2.7. > From your message it is not clear what your specific issue is, so it is not > easy to provide more useful information :-) > > On Thu, Feb 7, 2019 at 3:51 PM Mgr. Martin Pecka wrote: >> >> There is a problem with the python bindings for libftdi. >> >> Several sources [1, 2] say that to use python bindings with Python 2, >> libftdi has to be in version 1.0 <= libftdi <= 1.2, whereas to work with >> Python 3, it has to be >= 1.3. >> >> That's quite unfortunate. Is there a possibility to resolve this issue so >> that a single version of libftdi would be usable in both Python 2 and Python >> 3? >> >> People were reporting [3, 4, 5] even your own examples in repo fail to run >> in version 1.3+. >> >> So far, I filed an Ubuntu packaging issue [6] to provide both version 1.2 >> and 1.4, but I think it has a pretty low probability to get resolved... >> >> Thanks you for helping resolve this unfortunate issue. >> >> [1] >> https://github.com/adafruit/Adafruit_Python_GPIO/issues/61#issuecomment-363477104 >> [2] >> https://github.com/adafruit/Adafruit_Python_GPIO/issues/50#issuecomment-363479708 >> [3] >> http://developer.intra2net.com/git/?p=libftdi;a=blob;f=python/examples/complete.py;h=d949fcaf86203f5b184af59072f9004797084672;hb=HEAD >> [4] >> http://developer.intra2net.com/mailarchive/html/libftdi/2018/msg00081.html >> [5] >> http://developer.intra2net.com/mailarchive/html/libftdi/2018/msg8.html >> [6] https://bugs.launchpad.net/ubuntu/+source/libftdi1/+bug/1815049 I have a strange behavoir/error when importing ftdy in Python 2.7: File "usr/lib/python2.7/importlib/__init__.py", line 37, in import_module ImportError: /usr/lib/python2.7/site-packages/_ftdi1.so: undefined symbol: str2charp_size Systeminfo: Python 2.7.16, SWIG 3.0.12/4.0.0, gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) libftdi: master branch Any idea? Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: libftdi license
On Tue, Jun 4, 2019 at 5:22 PM Thomas Jarosch wrote: > > Hello Yegor, > > You wrote on Tue, Jun 04, 2019 at 02:09:24PM +0200: > > > > some files in libftdi mention additional licenses: src/ftdi_stream.c > > > > (MIT), cmake/UseLibFTDI1.cmake (LGPL 2.1) etc. > > > > > > > > Could you reflect all this in the LICENSE file like dropbear does [1]? > > > > > > > > It would be also great if the project can provide a file containing > > > > all copyright information that is needed for a FOSS compliance > > > > (attribution). > > > > > > > > Have you already used such tools as FOSSology [2] or scancode [3]? > > > > > > > > [1] https://github.com/mkj/dropbear/blob/master/LICENSE > > > > [2] https://www.fossology.org/ > > > > [3] https://github.com/nexB/scancode-toolkit > > > > > > See our discussion on the BR mailing list: > > > http://lists.busybox.net/pipermail/buildroot/2019-May/251173.html > > > > > > FYI: https://spdx.org/ids-how > > > > FYI: I have found this really interesting paper about license > > compliance for FOSS projects [1]. In the light of [2] FOSS compliance > > is getting more and more important. And for now it means a lot of > > manual work :-( > > > > [1] > > https://www.linuxfoundation.org/publications/2018/03/license-scanning-compliance-programs-foss-projects/ > > [2] > > https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering > > thanks for the links! This is something that needs addressing in the long run, > so far I still have "putting out a new release at all" on my TODO list ^^ > > I didn't use any of the mentioned tools myself yet. > > Is this something you care about right now and want to work on? > Or should I just add it to the TODO list? It is interesting for the future. I'll try to contribute too. > Regarding license compliance: I recently tried to get the linux kernel > source code for my Pocketbook ebook reader, it was a PITA. > You can sometimes be lucky if vendors release source code at all. I think it depends on the country this device is sold as also whether you want to take legal steps :-) Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: libftdi license
On Wed, May 29, 2019 at 1:01 PM Yegor Yefremov wrote: > > Hello Thomas, > > some files in libftdi mention additional licenses: src/ftdi_stream.c > (MIT), cmake/UseLibFTDI1.cmake (LGPL 2.1) etc. > > Could you reflect all this in the LICENSE file like dropbear does [1]? > > It would be also great if the project can provide a file containing > all copyright information that is needed for a FOSS compliance > (attribution). > > Have you already used such tools as FOSSology [2] or scancode [3]? > > [1] https://github.com/mkj/dropbear/blob/master/LICENSE > [2] https://www.fossology.org/ > [3] https://github.com/nexB/scancode-toolkit See our discussion on the BR mailing list: http://lists.busybox.net/pipermail/buildroot/2019-May/251173.html FYI: https://spdx.org/ids-how Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
libftdi license
Hello Thomas, some files in libftdi mention additional licenses: src/ftdi_stream.c (MIT), cmake/UseLibFTDI1.cmake (LGPL 2.1) etc. Could you reflect all this in the LICENSE file like dropbear does [1]? It would be also great if the project can provide a file containing all copyright information that is needed for a FOSS compliance (attribution). Have you already used such tools as FOSSology [2] or scancode [3]? [1] https://github.com/mkj/dropbear/blob/master/LICENSE [2] https://www.fossology.org/ [3] https://github.com/nexB/scancode-toolkit Thanks, Best regards, Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: Issues reading EEPROM on FT2232HL and FT232HL
On Mon, Oct 29, 2018 at 11:37 AM Yegor Yefremov
wrote:
>
> I have two devices one with FT2232HL and the other with FT232HL. lsusb output
>
> Bus 001 Device 003: ID 0403:6010
>
> and
>
> Bus 001 Device 003: ID 0403:6014
>
> I'm trying to decode EEPROM with this Python code:
>
> import ftdi1 as ftdi
>
> VID_FTDI = 0x0403
> PID_FTDI_FT232H = 0x6014
> PID_FTDI_FT2232H = 0x6010
> PID_FTDI_FT4232H = 0x6011
> PID_FTDI_FT_X = 0x6015
>
>
> def read():
> """Read FTDI."""
> # initialize FTDI library
> context = ftdi.new()
> if context is None:
> print("Failed to initialize libftdi1")
> return False
>
> # find all FTDI chips
> rc, devlist = ftdi.usb_find_all(context, VID_FTDI, PID_FTDI_FT2232H)
> if rc <= 0:
> print("No FTDI chips found")
> return False
>
> curnode = devlist
> while curnode is not None:
> if ftdi.usb_open_dev(context, curnode.dev) != 0:
> print("Failed to open FTDI device")
> return False
>
> # read eeprom
> eeprom_addr = 1
> rc, eeprom_val = ftdi.read_eeprom_location(context, eeprom_addr)
> if 0 != rc:
> print("Failed to read FTDI EEPROM location")
> return False
>
> print("EEPROM location: {}".format(eeprom_val))
>
> rc = ftdi.read_eeprom(context)
> if rc < 0:
> print("Failed to read EEPROM")
> return False
>
> rc = ftdi.eeprom_decode(context, 1)
> if rc < 0:
> print("Failed to decode EEPROM")
> return False
>
> # select next FTDI device
> curnode = curnode.next
>
> return True
>
>
> read()
>
> This is the output:
>
> # python test.py
> EEPROM location: -1
> Checksum Error:
> Failed to decode EEPROM
>
> Any idea? The same code has no problems with either FT4232H or FTX
> chips. EEPROM is AT93C46D connected the same way as on the FT4232H
> devices (16-bit mode ORG). I can also see the signals on oscilloscope.
>
> What does location == -1 mean? FTDI cannot detect EEPROM?
>
> Has anyone successfully used both FT2232HL and FT232HL with libftdi1?
I've tried eeprom tool from examples folder and it turned out, that
EEPROM was empty. It seems like there is no way to detect whether the
EEPROM is empty or the data is corrupted?
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Issues reading EEPROM on FT2232HL and FT232HL
I have two devices one with FT2232HL and the other with FT232HL. lsusb output
Bus 001 Device 003: ID 0403:6010
and
Bus 001 Device 003: ID 0403:6014
I'm trying to decode EEPROM with this Python code:
import ftdi1 as ftdi
VID_FTDI = 0x0403
PID_FTDI_FT232H = 0x6014
PID_FTDI_FT2232H = 0x6010
PID_FTDI_FT4232H = 0x6011
PID_FTDI_FT_X = 0x6015
def read():
"""Read FTDI."""
# initialize FTDI library
context = ftdi.new()
if context is None:
print("Failed to initialize libftdi1")
return False
# find all FTDI chips
rc, devlist = ftdi.usb_find_all(context, VID_FTDI, PID_FTDI_FT2232H)
if rc <= 0:
print("No FTDI chips found")
return False
curnode = devlist
while curnode is not None:
if ftdi.usb_open_dev(context, curnode.dev) != 0:
print("Failed to open FTDI device")
return False
# read eeprom
eeprom_addr = 1
rc, eeprom_val = ftdi.read_eeprom_location(context, eeprom_addr)
if 0 != rc:
print("Failed to read FTDI EEPROM location")
return False
print("EEPROM location: {}".format(eeprom_val))
rc = ftdi.read_eeprom(context)
if rc < 0:
print("Failed to read EEPROM")
return False
rc = ftdi.eeprom_decode(context, 1)
if rc < 0:
print("Failed to decode EEPROM")
return False
# select next FTDI device
curnode = curnode.next
return True
read()
This is the output:
# python test.py
EEPROM location: -1
Checksum Error:
Failed to decode EEPROM
Any idea? The same code has no problems with either FT4232H or FTX
chips. EEPROM is AT93C46D connected the same way as on the FT4232H
devices (16-bit mode ORG). I can also see the signals on oscilloscope.
What does location == -1 mean? FTDI cannot detect EEPROM?
Has anyone successfully used both FT2232HL and FT232HL with libftdi1?
Regards,
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: libftdi code contribution
Hi Heinrich, On Fri, Jun 1, 2018 at 7:42 AM, Heinrich du Toit wrote: > Hi > > > > Is it possible to contribute to libftdi code base somehow? > > How would you submit code? Is there a guide somewhere? > The procedure is almost the same in every OSS project. Clone libftdi repository using git. Create a branch: git checkout -b my-fix Make your changes and commit them: git commit -as Then export your patch: git format-patch -1 -o outgoing After this just send it via git send-email: git send-email --to= outgoing/*.patch That's all. Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] CMake: move options to a dedicated file
Hi Thomas, sorry for delay. On Mon, Feb 5, 2018 at 11:36 PM, Thomas Jarosch wrote: > Hi Yegor, > > On 01/03/2018 01:46 PM, Yegor Yefremov wrote: >> Also disable all options having extra dependencies. >> >> If an option is selected makes its dependencies as REQUIRED. > > thanks for the big patch. It's almost merged :) > > What needs a bit of discussion is the change in default behavior: > > The old cmake script was "best effort": If you f.e. had libconfuse > installed, ftdi_eeprom was automatically build. > > With the new way of doing things, ftdi_eeprom needs to be enabled upon > request. This changes user expectations that have grown over many years. > > Do you think we can re-enable ftdi_eeprom > and the python bindings by default? > Not sure how widespread the C++ wrapper is used. You're right ftdi_eeprom should be enabled by default. Python bindings have more dependencies so I would let it OFF by default. > What about having libconfuse / boost library detection > in CMakeOptions.txt to set the default values? I'm using libftdi in the Buildroot context. In this case it is important/desired to have predictable, reproducible builds. If I configure the option FTDI_EEPROM as OFF, then I expect that I get no ftdi_eeprom binary even if I have libconfuse. Another approach would be NOT to define FTDI_EEPROM as an option, but just as a variable, that depends on whether libconfuse could be found or not. In this case the behavior is controlled externally through the development environment. But I'm more for the first variant. As for Boost as long as it is mostly interesting for testing, it is a more a matter of configuring the CI server. Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Erasing FT230X eeprom
How do I erase FT230X eeprom? According to a comment in src/ftdi.c
following chips will be excluded:
This is not supported on FT232R/FT245R according to the MProg manual from FTDI.
But the I see following code snippet:
if ((ftdi->type == TYPE_R) || (ftdi->type == TYPE_230X))
{
ftdi->eeprom->chip = 0;
return 0;
}
Should the comment be changed or erasing is still not implemented?
Regards,
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
[PATCH] CMake: move options to a dedicated file
Also disable all options having extra dependencies.
If an option is selected makes its dependencies as REQUIRED.
Signed-off-by: Yegor Yefremov
---
CMakeLists.txt | 62 ---
CMakeOptions.txt | 8 +++
examples/CMakeLists.txt| 98
ftdi_eeprom/CMakeLists.txt | 63 ++--
ftdipp/CMakeLists.txt | 91 +-
python/CMakeLists.txt | 120 -
test/CMakeLists.txt| 41
7 files changed, 209 insertions(+), 274 deletions(-)
create mode 100644 CMakeOptions.txt
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 66abe4c..71857d0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -16,6 +16,8 @@ cmake_minimum_required(VERSION 2.6 FATAL_ERROR)
add_definitions(-Wall)
+include(CMakeOptions.txt)
+
# Debug build
message("-- Build type: ${CMAKE_BUILD_TYPE}")
if(${CMAKE_BUILD_TYPE} STREQUAL Debug)
@@ -26,8 +28,10 @@ endif(${CMAKE_BUILD_TYPE} STREQUAL Debug)
find_package ( USB1 REQUIRED )
include_directories ( ${LIBUSB_INCLUDE_DIR} )
-# Find Boost (optional package)
-find_package(Boost)
+# Find Boost
+if (FTDIPP OR BUILD_TESTS)
+ find_package( Boost REQUIRED )
+endif()
# Set components
set(CPACK_COMPONENTS_ALL sharedlibs staticlibs headers)
@@ -46,8 +50,6 @@ set(CPACK_COMPONENT_SHAREDLIBS_GROUP "Development")
set(CPACK_COMPONENT_STATICLIBS_GROUP "Development")
set(CPACK_COMPONENT_HEADERS_GROUP"Development")
-option ( STATICLIBS "Build static libraries" ON )
-
# guess LIB_SUFFIX, don't take debian multiarch into account
if ( NOT DEFINED LIB_SUFFIX )
if( CMAKE_SYSTEM_NAME MATCHES "Linux"
@@ -113,18 +115,8 @@ add_custom_target(dist
| bzip2 > ${CMAKE_BINARY_DIR}/${ARCHIVE_NAME}.tar.bz2
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR})
-# Tests
-option ( BUILD_TESTS "Build unit tests with Boost Unit Test framework" ON )
-
-# Documentation
-option ( DOCUMENTATION "Generate API documentation with Doxygen" ON )
-
-
-find_package ( Doxygen )
-if ( DOCUMENTATION AND DOXYGEN_FOUND )
-
- # Find doxy config
- message(STATUS "Doxygen found.")
+if ( DOCUMENTATION )
+ find_package ( Doxygen REQUIRED)
# Copy doxy.config.in
set(top_srcdir ${CMAKE_SOURCE_DIR})
@@ -140,19 +132,25 @@ if ( DOCUMENTATION AND DOXYGEN_FOUND )
)
add_custom_target(docs ALL DEPENDS ${CMAKE_BINARY_DIR}/doc/html/index.html)
-
- message(STATUS "Generating API documentation with Doxygen")
-else(DOCUMENTATION AND DOXYGEN_FOUND)
- message(STATUS "Not generating API documentation")
-endif(DOCUMENTATION AND DOXYGEN_FOUND)
+endif ()
add_subdirectory(src)
-add_subdirectory(ftdipp)
+if ( FTDIPP )
+ add_subdirectory(ftdipp)
+endif ()
+if ( PYTHON_BINDINGS )
add_subdirectory(python)
-add_subdirectory(ftdi_eeprom)
-add_subdirectory(examples)
+endif ()
+if ( FTDI_EEPROM )
+ add_subdirectory(ftdi_eeprom)
+endif ()
+if ( EXAMPLES )
+ add_subdirectory(examples)
+endif ()
add_subdirectory(packages)
-add_subdirectory(test)
+if ( BUILD_TESTS )
+ add_subdirectory(test)
+endif ()
# PkgConfig
set(prefix ${CMAKE_INSTALL_PREFIX})
@@ -191,7 +189,7 @@ list ( APPEND LIBFTDI_LIBRARIES ${LIBUSB_LIBRARIES} )
set ( LIBFTDI_STATIC_LIBRARY ftdi1.a )
set ( LIBFTDI_STATIC_LIBRARIES ${LIBFTDI_STATIC_LIBRARY} )
list ( APPEND LIBFTDI_STATIC_LIBRARIES ${LIBUSB_LIBRARIES} )
-if (FTDI_BUILD_CPP)
+if ( FTDIPP )
set ( LIBFTDIPP_LIBRARY ftdipp1 )
set ( LIBFTDIPP_LIBRARIES ${LIBFTDIPP_LIBRARY} )
list ( APPEND LIBFTDIPP_LIBRARIES ${LIBUSB_LIBRARIES} )
@@ -238,7 +236,15 @@ install ( FILES
DESTINATION ${LIBFTDI_CMAKE_CONFIG_DIR}
)
+include(CPack)
+message (STATUS "Summary of build options:
-
-include(CPack)
+ Build static libs: ${STATICLIBS}
+ Build C++ bindings: ${FTDIPP}
+ Build Python bindings: ${PYTHON_BINDINGS}
+ Build ftdi_eeprom: ${FTDI_EEPROM}
+ Build examples: ${EXAMPLES}
+ Build tests: ${BUILD_TESTS}
+ Build API documentation: ${DOCUMENTATION}
+")
diff --git a/CMakeOptions.txt b/CMakeOptions.txt
new file mode 100644
index 000..43a9d3d
--- /dev/null
+++ b/CMakeOptions.txt
@@ -0,0 +1,8 @@
+option ( STATICLIBS "Build static libraries" ON )
+option ( BUILD_TESTS "Build unit tests with Boost Unit Test framework" OFF )
+option ( DOCUMENTATION "Generate API documentation with Doxygen" OFF )
+option ( EXAMPLES "Build example programs" ON )
+option ( FTDIPP "Build C++ binding library libftdi1++" OFF )
+option ( FTDI_EEPROM "Build ftdi_eeprom" OFF )
+option ( PYTHON_BINDINGS "Build python bindings via swig" OFF )
+option ( LINK_PYTHON_LIBRARY "Link against python libraries" OFF )
diff --git a/examples/CMakeLists.txt b/examples/CMakeLists.txt
ind
Re: [PATCH] cmake: use the standard CMake flag to drive the shared object build
On Thu, Dec 28, 2017 at 3:32 PM, Thomas Jarosch wrote: > Hi Yegor and Samuel, > > On Saturday, 23 December 2017 21:45:11 CET Yegor Yefremov wrote: >> Forget about the STATICLIBS related patch, as libftdi1 creates both >> dynamic and static libs at once. > > alright, I already noted down to check the git history of libftdi > why we did it that way in the first place. I would only break > backward compatibility if there's a good reason for it. > So I can skip this now - less work is always appreciated :) > > > Regarding the other patches: > > 0002-cmake-fix-FindUSB1.cmake.patch: > > This seems to break the build of the unit test on my Fedora 26 box: > > " > CMake Error: CMake can not determine linker language for target: test_libftdi1 > CMake Error: Cannot determine link language for target "test_libftdi1". > -- Generating done > " > > > > I tried the 0003-cmake-do-not-check-for-g-when-FTDIPP-is-disabled.patch > independently, but it breaks the build of the unit test, too. > Also it introduces a variable "FTDIPP" without a corresponding cmake option? test/CMakeLists.txt also needs proejct option with CXX language. FTDIPP is an option introduced in a03fea794af90cd97514f35f212691f8b5b3700d. Btw what about creating a file CMakeOptions.txt and placing all options there as for example nghttp2 package does [1]? Then we would only include directories, if corresponding options are set. CMakeOptions.txt will be early included in the CMakeLists.txt. [1] https://github.com/nghttp2/nghttp2/blob/master/CMakeOptions.txt > Please look into those patches again to ensure the unit test > is still buildable and the default behavior doesn't change. Thanks! > > I'll soon be on a short vacation (lots of 34c3 presentations to watch...), > so there'll be a small delay until I can look into this. > > Cheers, > Thomas > -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] cmake: use the standard CMake flag to drive the shared object build
On Fri, Dec 15, 2017 at 3:19 PM, Yegor Yefremov
wrote:
> Hello Thomas,
>
> On Fri, Dec 15, 2017 at 3:09 PM, wrote:
>> From: Samuel Martin
>>
>> Remove the STATICLIBS CMake option (and the code handling it) and let
>> the standard CMake flags drive the shared object build.
>>
>> Build shared library:
>> cmake -DBUILD_SHARED_LIBS=ON
>>
>> Build static library:
>> cmake -DBUILD_SHARED_LIBS=OFF
>>
>> Signed-off-by: Samuel Martin
>> Signed-off-by: Yegor Yefremov
>> ---
>> CMakeLists.txt| 2 --
>> ftdipp/CMakeLists.txt | 15 +--
>> src/CMakeLists.txt| 13 +
>> 3 files changed, 2 insertions(+), 28 deletions(-)
>>
>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>> index 66abe4c..6ed4363 100644
>> --- a/CMakeLists.txt
>> +++ b/CMakeLists.txt
>> @@ -46,8 +46,6 @@ set(CPACK_COMPONENT_SHAREDLIBS_GROUP "Development")
>> set(CPACK_COMPONENT_STATICLIBS_GROUP "Development")
>> set(CPACK_COMPONENT_HEADERS_GROUP"Development")
>>
>> -option ( STATICLIBS "Build static libraries" ON )
>> -
>> # guess LIB_SUFFIX, don't take debian multiarch into account
>> if ( NOT DEFINED LIB_SUFFIX )
>>if( CMAKE_SYSTEM_NAME MATCHES "Linux"
>> diff --git a/ftdipp/CMakeLists.txt b/ftdipp/CMakeLists.txt
>> index 27fbe8d..1dd0881 100644
>> --- a/ftdipp/CMakeLists.txt
>> +++ b/ftdipp/CMakeLists.txt
>> @@ -23,8 +23,7 @@ if (FTDIPP)
>> set(FTDI_BUILD_CPP True PARENT_SCOPE)
>> message(STATUS "Building libftdi1++")
>>
>> -# Shared library
>> -add_library(ftdipp1 SHARED ${cpp_sources})
>> +add_library(ftdipp1 ${cpp_sources})
>>
>> math(EXPR VERSION_FIXUP "${MAJOR_VERSION} + 1")# Compatiblity with
>> previous releases
>> set_target_properties(ftdipp1 PROPERTIES VERSION
>> ${VERSION_FIXUP}.${MINOR_VERSION}.0 SOVERSION 3)
>> @@ -41,18 +40,6 @@ if (FTDIPP)
>>LIBRARY DESTINATION lib${LIB_SUFFIX}
>>ARCHIVE DESTINATION lib${LIB_SUFFIX}
>> )
>> -
>> -# Static library
>> -if ( STATICLIBS )
>> - add_library(ftdipp1-static STATIC ${cpp_sources})
>> - set_target_properties(ftdipp1-static PROPERTIES OUTPUT_NAME "ftdipp1")
>> - set_target_properties(ftdipp1-static PROPERTIES CLEAN_DIRECT_OUTPUT 1)
>> -
>> - install ( TARGETS ftdipp1-static
>> -ARCHIVE DESTINATION lib${LIB_SUFFIX}
>> -COMPONENT staticlibs
>> - )
>> -endif ()
>>
>> install ( FILES ${cpp_headers}
>>DESTINATION include/${PROJECT_NAME}
>> diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
>> index 9fd86a6..501d4a8 100644
>> --- a/src/CMakeLists.txt
>> +++ b/src/CMakeLists.txt
>> @@ -21,7 +21,7 @@ configure_file(ftdi_version_i.h.in
>> "${CMAKE_CURRENT_BINARY_DIR}/ftdi_version_i.h
>> set(c_sources ${CMAKE_CURRENT_SOURCE_DIR}/ftdi.c
>> ${CMAKE_CURRENT_SOURCE_DIR}/ftdi_stream.c CACHE INTERNAL "List of c sources"
>> )
>> set(c_headers ${CMAKE_CURRENT_SOURCE_DIR}/ftdi.h CACHE INTERNAL "List
>> of c headers" )
>>
>> -add_library(ftdi1 SHARED ${c_sources})
>> +add_library(ftdi1 ${c_sources})
>>
>> math(EXPR VERSION_FIXUP "${MAJOR_VERSION} + 1")# Compatiblity with
>> previous releases
>> set_target_properties(ftdi1 PROPERTIES VERSION
>> ${VERSION_FIXUP}.${MINOR_VERSION}.0 SOVERSION 2)
>> @@ -38,17 +38,6 @@ install ( TARGETS ftdi1
>>ARCHIVE DESTINATION lib${LIB_SUFFIX}
>> )
>>
>> -if ( STATICLIBS )
>> - add_library(ftdi1-static STATIC ${c_sources})
>> - target_link_libraries(ftdi1-static ${LIBUSB_LIBRARIES})
>> - set_target_properties(ftdi1-static PROPERTIES OUTPUT_NAME "ftdi1")
>> - set_target_properties(ftdi1-static PROPERTIES CLEAN_DIRECT_OUTPUT 1)
>> - install ( TARGETS ftdi1-static
>> -ARCHIVE DESTINATION lib${LIB_SUFFIX}
>> -COMPONENT staticlibs
>> - )
>> -endif ()
>> -
>> install ( FILES ${c_headers}
>>DESTINATION include/${PROJECT_NAME}
>>COMPONENT headers
>> --
>> 2.11.0
>
> There are two more patches in Buildroot [1], that we would like to see
> upstream. Should Samuel or I resend them or can you take them from BR
> git repo?
>
> Thanks.
>
> [1] https://git.busybox.net/buildroot/tree/package/libftdi1
Forget about the STATICLIBS related patch, as libftdi1 creates both
dynamic and static libs at once.
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] cmake: use the standard CMake flag to drive the shared object build
Hello Thomas,
On Fri, Dec 15, 2017 at 3:09 PM, wrote:
> From: Samuel Martin
>
> Remove the STATICLIBS CMake option (and the code handling it) and let
> the standard CMake flags drive the shared object build.
>
> Build shared library:
> cmake -DBUILD_SHARED_LIBS=ON
>
> Build static library:
> cmake -DBUILD_SHARED_LIBS=OFF
>
> Signed-off-by: Samuel Martin
> Signed-off-by: Yegor Yefremov
> ---
> CMakeLists.txt| 2 --
> ftdipp/CMakeLists.txt | 15 +--
> src/CMakeLists.txt| 13 +
> 3 files changed, 2 insertions(+), 28 deletions(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 66abe4c..6ed4363 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -46,8 +46,6 @@ set(CPACK_COMPONENT_SHAREDLIBS_GROUP "Development")
> set(CPACK_COMPONENT_STATICLIBS_GROUP "Development")
> set(CPACK_COMPONENT_HEADERS_GROUP"Development")
>
> -option ( STATICLIBS "Build static libraries" ON )
> -
> # guess LIB_SUFFIX, don't take debian multiarch into account
> if ( NOT DEFINED LIB_SUFFIX )
>if( CMAKE_SYSTEM_NAME MATCHES "Linux"
> diff --git a/ftdipp/CMakeLists.txt b/ftdipp/CMakeLists.txt
> index 27fbe8d..1dd0881 100644
> --- a/ftdipp/CMakeLists.txt
> +++ b/ftdipp/CMakeLists.txt
> @@ -23,8 +23,7 @@ if (FTDIPP)
> set(FTDI_BUILD_CPP True PARENT_SCOPE)
> message(STATUS "Building libftdi1++")
>
> -# Shared library
> -add_library(ftdipp1 SHARED ${cpp_sources})
> +add_library(ftdipp1 ${cpp_sources})
>
> math(EXPR VERSION_FIXUP "${MAJOR_VERSION} + 1")# Compatiblity with
> previous releases
> set_target_properties(ftdipp1 PROPERTIES VERSION
> ${VERSION_FIXUP}.${MINOR_VERSION}.0 SOVERSION 3)
> @@ -41,18 +40,6 @@ if (FTDIPP)
>LIBRARY DESTINATION lib${LIB_SUFFIX}
>ARCHIVE DESTINATION lib${LIB_SUFFIX}
> )
> -
> -# Static library
> -if ( STATICLIBS )
> - add_library(ftdipp1-static STATIC ${cpp_sources})
> - set_target_properties(ftdipp1-static PROPERTIES OUTPUT_NAME "ftdipp1")
> - set_target_properties(ftdipp1-static PROPERTIES CLEAN_DIRECT_OUTPUT 1)
> -
> - install ( TARGETS ftdipp1-static
> -ARCHIVE DESTINATION lib${LIB_SUFFIX}
> -COMPONENT staticlibs
> - )
> -endif ()
>
> install ( FILES ${cpp_headers}
>DESTINATION include/${PROJECT_NAME}
> diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
> index 9fd86a6..501d4a8 100644
> --- a/src/CMakeLists.txt
> +++ b/src/CMakeLists.txt
> @@ -21,7 +21,7 @@ configure_file(ftdi_version_i.h.in
> "${CMAKE_CURRENT_BINARY_DIR}/ftdi_version_i.h
> set(c_sources ${CMAKE_CURRENT_SOURCE_DIR}/ftdi.c
> ${CMAKE_CURRENT_SOURCE_DIR}/ftdi_stream.c CACHE INTERNAL "List of c sources" )
> set(c_headers ${CMAKE_CURRENT_SOURCE_DIR}/ftdi.h CACHE INTERNAL "List of
> c headers" )
>
> -add_library(ftdi1 SHARED ${c_sources})
> +add_library(ftdi1 ${c_sources})
>
> math(EXPR VERSION_FIXUP "${MAJOR_VERSION} + 1")# Compatiblity with
> previous releases
> set_target_properties(ftdi1 PROPERTIES VERSION
> ${VERSION_FIXUP}.${MINOR_VERSION}.0 SOVERSION 2)
> @@ -38,17 +38,6 @@ install ( TARGETS ftdi1
>ARCHIVE DESTINATION lib${LIB_SUFFIX}
> )
>
> -if ( STATICLIBS )
> - add_library(ftdi1-static STATIC ${c_sources})
> - target_link_libraries(ftdi1-static ${LIBUSB_LIBRARIES})
> - set_target_properties(ftdi1-static PROPERTIES OUTPUT_NAME "ftdi1")
> - set_target_properties(ftdi1-static PROPERTIES CLEAN_DIRECT_OUTPUT 1)
> - install ( TARGETS ftdi1-static
> -ARCHIVE DESTINATION lib${LIB_SUFFIX}
> -COMPONENT staticlibs
> - )
> -endif ()
> -
> install ( FILES ${c_headers}
>DESTINATION include/${PROJECT_NAME}
>COMPONENT headers
> --
> 2.11.0
There are two more patches in Buildroot [1], that we would like to see
upstream. Should Samuel or I resend them or can you take them from BR
git repo?
Thanks.
[1] https://git.busybox.net/buildroot/tree/package/libftdi1
Regards,
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: Configuring CBUSX_CLK24
On Fri, Apr 21, 2017 at 9:49 AM, Thomas Jarosch
wrote:
> Hello Yegor,
>
> On Friday, 21 April 2017 09:42:27 CEST Yegor Yefremov wrote:
>> # reset FTDI device
>> if ftdi.usb_reset(context) != 0:
>> print("Failed to reset FTDI device")
>> return False
>
> sorry, missed that part yesterday.
>
>> # close FTDI device
>> if ftdi.usb_close(context) != 0:
>> print("Failed to close FTDI device")
>> return False
>>
>> > Thought ftdi_usb_open() calls that internally anyway.
>>
>> Original FTDI API has two functions:
>>
>> FT_ResetDevice and FT_CyclePort. The latter is suitable for my case:
>>
>> "The effect of this function is the same as disconnecting then
>> reconnecting the device from USB. Possible use of this function is
>> situations where a fatal error has occurred and it is difficult, or
>> not possible, to recover without unplugging and replugging the USB
>> cable. This function can also be used after reprogramming the EEPROM
>> to force the FTDI device to read the new EEPROM contents which would
>> otherwise require a physical disconnect-reconnect."
>>
>> Though this routine is marked as "Windows (2000 and later) ".
>>
>> Any idea?
>
> may be this helps:
>
> https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line
>
> Source for the short program:
> http://marc.info/?l=linux-usb&m=121459435621262&w=2
It works. Thanks.
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: Configuring CBUSX_CLK24
Hi Thomas,
On Thu, Apr 20, 2017 at 6:17 PM, Thomas Jarosch
wrote:
> Hi Yegor,
>
> On Tuesday, 18 April 2017 11:47:50 CEST Yegor Yefremov wrote:
>> I'm configuring FTX ftdi.CBUS_FUNCTION_0 to ftdi.CBUSX_CLK24 in Linux
>> (ARM machine). After this ttyUSB0 gets disconnected, I can either
>> rebind it or reload the FTDI drive. Everything as expected. The
>> problem is, that I get 24MHz output only if I really reboot my ARM
>> machine.
>>
>> How can I activate 24MHz without rebooting?
>>
>> My code snippet for programming 24MHz:
>>
>> if ftdi.set_eeprom_value(context, ftdi.CBUS_FUNCTION_0, ftdi.CBUSX_CLK24) !=
>> 0: print("Failed to set CBUS_FUNCTION_0")
>> return False
>>
>> # prepare EEPROM buffer for writing
>> if ftdi.eeprom_build(context) < 0:
>> print("Failed to build EEPROM")
>> return False
>>
>> # finally write EEPROM
>> if ftdi.write_eeprom(context) != 0:
>> print("Failed to write EEPROM")
>> return False
>>
>> # close FTDI device
>> if ftdi.usb_close(context) != 0:
>> print("Failed to close FTDI device")
>> return False
>
> do you really need to reboot the host
> or does re-plugging the device also help?
Re-plugging is not possible as FTDI chip is soldered, i.e. part of the
whole device.
> Did you try to call ftdi_usb_reset() after flashing?
Yes.
# prepare EEPROM buffer for writing
if ftdi.eeprom_build(context) < 0:
print("Failed to build EEPROM")
return False
# finally write EEPROM
if ftdi.write_eeprom(context) != 0:
print("Failed to write EEPROM")
return False
# reset FTDI device
if ftdi.usb_reset(context) != 0:
print("Failed to reset FTDI device")
return False
# close FTDI device
if ftdi.usb_close(context) != 0:
print("Failed to close FTDI device")
return False
> Thought ftdi_usb_open() calls that internally anyway.
Original FTDI API has two functions:
FT_ResetDevice and FT_CyclePort. The latter is suitable for my case:
"The effect of this function is the same as disconnecting then
reconnecting the device from USB. Possible use of this function is
situations where a fatal error has occurred and it is difficult, or
not possible, to recover without unplugging and replugging the USB
cable. This function can also be used after reprogramming the EEPROM
to force the FTDI device to read the new EEPROM contents which would
otherwise require a physical disconnect-reconnect."
Though this routine is marked as "Windows (2000 and later) ".
Any idea?
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Configuring CBUSX_CLK24
I'm configuring FTX ftdi.CBUS_FUNCTION_0 to ftdi.CBUSX_CLK24 in Linux
(ARM machine). After this ttyUSB0 gets disconnected, I can either
rebind it or reload the FTDI drive. Everything as expected. The
problem is, that I get 24MHz output only if I really reboot my ARM
machine.
How can I activate 24MHz without rebooting?
My code snippet for programming 24MHz:
if ftdi.set_eeprom_value(context, ftdi.CBUS_FUNCTION_0, ftdi.CBUSX_CLK24) != 0:
print("Failed to set CBUS_FUNCTION_0")
return False
# prepare EEPROM buffer for writing
if ftdi.eeprom_build(context) < 0:
print("Failed to build EEPROM")
return False
# finally write EEPROM
if ftdi.write_eeprom(context) != 0:
print("Failed to write EEPROM")
return False
# close FTDI device
if ftdi.usb_close(context) != 0:
print("Failed to close FTDI device")
return False
Regards,
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
MinGW toolchain warnings
Hi Thomas, compiling libftdi with mingw toolchain produces following warnings: [ 29%] Building C object examples/CMakeFiles/stream_test.dir/stream_test.c.obj /home/user/Documents/versioned/libftdi/examples/stream_test.c: In function ‘readCallback’: /home/user/Documents/versioned/libftdi/examples/stream_test.c:86:89: warning: unknown conversion type character ‘l’ in format [-Wformat=] fprintf(stderr, "Skip %7d blocks from 0x%08x to 0x%08x at blocks %10llu\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:86:36: warning: too many arguments for format [-Wformat-extra-args] fprintf(stderr, "Skip %7d blocks from 0x%08x to 0x%08x at blocks %10llu\n", ^~ /home/user/Documents/versioned/libftdi/examples/stream_test.c:86:89: warning: unknown conversion type character ‘l’ in format [-Wformat=] fprintf(stderr, "Skip %7d blocks from 0x%08x to 0x%08x at blocks %10llu\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:86:36: warning: too many arguments for format [-Wformat-extra-args] fprintf(stderr, "Skip %7d blocks from 0x%08x to 0x%08x at blocks %10llu\n", ^~ /home/user/Documents/versioned/libftdi/examples/stream_test.c:101:89: warning: unknown conversion type character ‘l’ in format [-Wformat=] fprintf(stderr, "Skip %7d blocks from 0x%08x to 0x%08x at blocks %10llu\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:101:36: warning: too many arguments for format [-Wformat-extra-args] fprintf(stderr, "Skip %7d blocks from 0x%08x to 0x%08x at blocks %10llu\n", ^~ /home/user/Documents/versioned/libftdi/examples/stream_test.c:101:89: warning: unknown conversion type character ‘l’ in format [-Wformat=] fprintf(stderr, "Skip %7d blocks from 0x%08x to 0x%08x at blocks %10llu\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:101:36: warning: too many arguments for format [-Wformat-extra-args] fprintf(stderr, "Skip %7d blocks from 0x%08x to 0x%08x at blocks %10llu\n", ^~ /home/user/Documents/versioned/libftdi/examples/stream_test.c: In function ‘main’: /home/user/Documents/versioned/libftdi/examples/stream_test.c:250:39: warning: unknown conversion type character ‘l’ in format [-Wformat=] fprintf(stderr,"%d errors of %llu blocks (%Le), %d (%Le) blocks skipped\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:250:51: warning: unknown conversion type character ‘L’ in format [-Wformat=] fprintf(stderr,"%d errors of %llu blocks (%Le), %d (%Le) blocks skipped\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:250:57: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long long unsigned int’ [-Wformat=] fprintf(stderr,"%d errors of %llu blocks (%Le), %d (%Le) blocks skipped\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:250:61: warning: unknown conversion type character ‘L’ in format [-Wformat=] fprintf(stderr,"%d errors of %llu blocks (%Le), %d (%Le) blocks skipped\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:250:23: warning: too many arguments for format [-Wformat-extra-args] fprintf(stderr,"%d errors of %llu blocks (%Le), %d (%Le) blocks skipped\n", ^~~ /home/user/Documents/versioned/libftdi/examples/stream_test.c:250:39: warning: unknown conversion type character ‘l’ in format [-Wformat=] fprintf(stderr,"%d errors of %llu blocks (%Le), %d (%Le) blocks skipped\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:250:51: warning: unknown conversion type character ‘L’ in format [-Wformat=] fprintf(stderr,"%d errors of %llu blocks (%Le), %d (%Le) blocks skipped\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:250:57: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long long unsigned int’ [-Wformat=] fprintf(stderr,"%d errors of %llu blocks (%Le), %d (%Le) blocks skipped\n", ^ /home/user/Documents/versioned/libftdi/examples/stream_test.c:250:61: warning: unknown conversion type character ‘L’ in format [-Wformat=] fprintf(stderr,"%d errors of %llu blocks (%Le), %d (%L
Re: [PATCH] cbus.py: remove unnecessary semicolons
Hi Thomas, On Wed, Feb 22, 2017 at 9:56 AM, Thomas Jarosch wrote: > Hi Yegor, > > On Tuesday, 24 January 2017 15:14:57 CET yegorsli...@googlemail.com wrote: >> From: Yegor Yefremov >> >> --- >> python/examples/cbus.py | 26 +- >> 1 file changed, 13 insertions(+), 13 deletions(-) > > applied, thanks! any plans for the new release? Regards, Yegor -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
Re: [PATCH] Fix checksum calculation for big endian systems
On Wed, Jun 8, 2016 at 11:52 AM, wrote:
> From: Yegor Yefremov
>
> During checksum calculation in ftdi_eeprom_build() a 16-bit value
> will be read directly from EEPROM (FT230X devices only):
>
> ftdi_read_eeprom_location(ftdi, i, &data)
>
> 'data' is little endian, so the bytes must be swapped on a big-endian
> system. Introduce related macro swap_short() and add endianess detection
> to CMakeLists.txt.
> ---
> CMakeLists.txt | 7 +++
> src/ftdi.c | 2 +-
> src/ftdi_i.h | 5 +
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index ce122ff..3cb2f3f 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -22,6 +22,13 @@ if(${CMAKE_BUILD_TYPE} STREQUAL Debug)
> add_definitions(-DDEBUG)
> endif(${CMAKE_BUILD_TYPE} STREQUAL Debug)
>
> +# check, if he system is big endian or little endian
> +include(TestBigEndian)
> +test_big_endian(BIGENDIAN)
> +if(${BIGENDIAN})
> + add_definitions(-DBIGENDIAN)
> +endif(${BIGENDIAN})
> +
> # find libusb
> find_package ( USB1 REQUIRED )
> include_directories ( ${LIBUSB_INCLUDE_DIR} )
> diff --git a/src/ftdi.c b/src/ftdi.c
> index f5d263c..f516538 100644
> --- a/src/ftdi.c
> +++ b/src/ftdi.c
> @@ -3239,7 +3239,7 @@ int ftdi_eeprom_build(struct ftdi_context *ftdi)
> fprintf(stderr, "Reading Factory Configuration Data
> failed\n");
> i = 0x50;
> }
> -value = data;
> +value = swap_short(data);
> }
> else {
> value = output[i*2];
> diff --git a/src/ftdi_i.h b/src/ftdi_i.h
> index cf2ac78..a9ab3a6 100644
> --- a/src/ftdi_i.h
> +++ b/src/ftdi_i.h
> @@ -141,3 +141,8 @@ struct ftdi_eeprom
> int release_number;
> };
>
> +#if BIGENDIAN
> +#define swap_short(val) ((val >> 8) | (val << 8))
> +#else
> +#define swap_short(val) (val)
> +#endif
> --
> 2.1.4
This patch should be replaced by this one:
http://developer.intra2net.com/mailarchive/html/libftdi/2016/msg00068.html
Yegor
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
