You miss an important point, it is *NOT* the possible range of values
the *TYPE* may take on.
It is the range of values the **ACTUAL*DATA** might take on that is
important here.
It's much easier to make sure bugs are not introduced in the future to
make sure that things like printf respect
David Brownell wrote:
Update the Beagle setup:
- OMAP3530 updates:
* split ICEpick TAP enable support to its own file, for
reuse and eventually for storing other utility code
like emulation reset
* clean up, including labeling the tap as for DAP not
for the Cortex-A8 a
Xiaofan Chen wrote, On 06/19/2009 07:35 PM:
> Glad to hear that OpenOCD works with the libusb-win32/libftdi
> combination.
>
> As for the com port, if it is part of the device, then using libusb-win32
> device driver (as the driver of the whole USB composite device) will
> disable it. That is the
On Sat, 2009-06-20 at 11:13 +0800, Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 3:36 AM, Freddie Chopin wrote:
> > Anyway, about that "equal" performance with libftdi:
> > Tested with a ~29kB image on LPC2103 (upload to flash):
> >
> > libftdi:
> > > Start address 0x3c, load size 29640
> > > Tra
On Fri, Jun 19, 2009 at 3:36 AM, Freddie Chopin wrote:
> Anyway, about that "equal" performance with libftdi:
> Tested with a ~29kB image on LPC2103 (upload to flash):
>
> libftdi:
> > Start address 0x3c, load size 29640
> > Transfer rate: 6 KB/sec, 14820 bytes/write.
> ftd2xx:
> > Start address
On Sat, Jun 20, 2009 at 9:04 AM, Zach Welch wrote:
> The community would be well advised to avoid these risks: use libftdi.
I think it is not that difficult for people under Linux to use libftdi. But
it is certainly not so easy to do that under Windows.
Maybe a mini-howto will help for Windows us
On Fri, 2009-06-19 at 21:24 -0400, Duane Ellis wrote:
[snip]
> If we had to fix this, what would we do to fix this:
>
> Today - we do not have macros, or types like GDB/GCC/GAS.
> GDB for instance uses CORE_ADDR - and has infrastructure behind it.
[snip]
This point deserves emphasis. This is the
On Fri, 2009-06-19 at 21:35 -0400, Duane Ellis wrote:
> Rick Altherr wrote:
> > Rather than casting to int, should the printf's be using the PRI*
> > macros for uint32_t?
>
> To be clear, the "LOG_INFO()" format string is:
>
> LOG_INFO("U_tg = %d mV, U_aux = %d mV, U_tgpwr = %d mV, I_tgpwr = %d
On Fri, 2009-06-19 at 21:24 -0400, Duane Ellis wrote:
> Zach Welch wrote:
> > On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
> >
> >> duane> FYI - I committed several cygwin specific printf() warning fixes.
> >> duane>Simple cast to fix
> >> duane> these where causing "-Werror" fail
On Sat, Jun 20, 2009 at 9:04 AM, Zach Welch wrote:
> P.S. At least one technical solution does exist that would allow FTD2XX
> to be used with OpenOCD, without loading libftd2xx inside OpenOCD.
> However, I think developing this feature will cost much more than simply
> fixing any bugs and deficie
Rick Altherr wrote:
> Rather than casting to int, should the printf's be using the PRI*
> macros for uint32_t?
To be clear, the "LOG_INFO()" format string is:
LOG_INFO("U_tg = %d mV, U_aux = %d mV, U_tgpwr = %d mV, I_tgpwr = %d mA,
D1 = %d, Target power %s %s\n", \
Really, if that is *truly* w
zach> I am opposed to reverting the changes; I would rather
zach> we take some time to audit the code and fix the system
zach> to ensure we improve portability.
Agreed 100%
zach> In the same process, we could also fix
zach> up the 160 odd places where strtoul is
zach> used without sufficient er
Zach Welch wrote:
> On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
>
>> duane> FYI - I committed several cygwin specific printf() warning fixes.
>> duane>Simple cast to fix
>> duane> these where causing "-Werror" failures on cygwin.
>>
>> zach> I was just about to post some patches
A-yup. :)
On Fri, 2009-06-19 at 18:13 -0700, Rick Altherr wrote:
> Rather than casting to int, should the printf's be using the PRI*
> macros for uint32_t?
> --
> Rick Altherr
> kc8...@kc8apf.net
>
> "He said he hadn't had a byte in three days. I had a short, so I split
> it with him."
> --
On Fri, 2009-06-19 at 17:40 -0700, Zach Welch wrote:
> On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
> > duane> FYI - I committed several cygwin specific printf() warning fixes.
> > duane>Simple cast to fix
> > duane> these where causing "-Werror" failures on cygwin.
> >
> > zach> I
Rather than casting to int, should the printf's be using the PRI*
macros for uint32_t?
--
Rick Altherr
kc8...@kc8apf.net
"He said he hadn't had a byte in three days. I had a short, so I split
it with him."
-- Unsigned
On Jun 19, 2009, at 4:16 PM, du...@mail.berlios.de wrote:
Author: du
On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
> duane> FYI - I committed several cygwin specific printf() warning fixes.
> duane>Simple cast to fix
> duane> these where causing "-Werror" failures on cygwin.
>
> zach> I was just about to post some patches to show how to fix all of the
On Fri, 2009-06-19 at 18:26 +0200, Harald Kipp wrote:
> Hello all,
>
> I may have missed one or the other statement given in that long license
> discussion thread. Nevertheless, Michael asked me to post my view to
> this forum. If I'm repeating statements that had been posted already:
> Sorry for
duane> FYI - I committed several cygwin specific printf() warning fixes.
duane>Simple cast to fix
duane> these where causing "-Werror" failures on cygwin.
zach> I was just about to post some patches to show how to fix all of these
zach> correctly, as casts are not the right way to do it.
In
On Fri, 2009-06-19 at 19:49 -0400, Duane Ellis wrote:
> >> I think this kind of stuff should be prohibited from source files.
> >> This is noise for anyone that does not use one specific editor.
>
> I disagree.. - But since you are so proactive ...
>
> Please also fix arm-jtag-ew.c - remove the
On Fri, 2009-06-19 at 19:38 -0400, Duane Ellis wrote:
> Zach Welch wrote:
> > On Fri, 2009-06-19 at 19:18 -0400, Duane Ellis wrote:
> >
> >> FYI - I committed several cygwin specific printf() warning fixes.
> >>Simple cast to fix
> >>
> >> these where causing "-Werror" failures on cygwi
>> I think this kind of stuff should be prohibited from source files.
>> This is noise for anyone that does not use one specific editor.
I disagree.. - But since you are so proactive ...
Please also fix arm-jtag-ew.c - remove the VIM version of the same thing.
-Duane.
On Sat, 2009-06-20 at 01:16 +0200, du...@mail.berlios.de wrote:
> Author: duane
> Date: 2009-06-20 01:15:58 +0200 (Sat, 20 Jun 2009)
> New Revision: 2293
[snip]
> +/*
> + * Local Variables:
> + * c-basic-offset: 4
> + * tab-width: 4
> + * End:
> + */
I think this kind of stuff should be prohibite
Zach Welch wrote:
> On Fri, 2009-06-19 at 19:18 -0400, Duane Ellis wrote:
>
>> FYI -I committed several cygwin specific printf() warning fixes.
>> Simple cast to fix
>>
>> these where causing "-Werror" failures on cygwin.
>>
>
> I was just about to post some patches to show how
On Sat, Jun 20, 2009 at 12:29 AM, Gene Smith wrote:
>
> I can switch back and forth between jlink and olimex/ftdi OK in openocd
> and debug wiht insight. They both work OK. However, I don't see a new
> serial port in Dev mgr for the olimex. Where should I see this? I only
> see the built-in COM1 wh
Demonstrate C99 PRIuN formatting specifiers in trace.c.
---
trace.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Demonstrate C99 PRIuN formatting specifiers in trace.c.
---
trace.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
==
only in patch2:
unchanged:
---
Include from "types.h".
---
types.h |3 +++
1 file changed, 3 insertions(+)
Include from "types.h".
---
types.h |3 +++
1 file changed, 3 insertions(+)
==
only in patch2:
unchanged:
--- src/helper/types.h (revision 2292)
+++ src/helper/types.h (working copy)
@@ -29,6 +29,9 @@
#ifde
This series includes small patches that improve the core types.
1/2 Include from "types.h".
2/2 Demonstrate C99 PRIuN formatting specifiers in trace.c.
---
Summary of Patches 1-2:
helper/types.h |3 +++
target/trace.c |5 +++--
2 files changed, 6 insertions(+), 2 deletions(-)
___
On Fri, 2009-06-19 at 19:18 -0400, Duane Ellis wrote:
> FYI - I committed several cygwin specific printf() warning fixes.
> Simple cast to fix
>
> these where causing "-Werror" failures on cygwin.
I was just about to post some patches to show how to fix all of these
correctly, as ca
FYI - I committed several cygwin specific printf() warning fixes.
Simple cast to fix
these where causing "-Werror" failures on cygwin.
>> Author: duane
>> Date: 2009-06-20 01:15:58 +0200 (Sat, 20 Jun 2009)
>> New Revision: 2293
>>
>> Modified:
>> trunk/src/jtag/arm-jtag-ew.c
>> trun
Hello all,
I may have missed one or the other statement given in that long license
discussion thread. Nevertheless, Michael asked me to post my view to
this forum. If I'm repeating statements that had been posted already:
Sorry for the noise.
David Brownell wrote:
> The source code should still
Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 11:09 PM, Gene Smith wrote:
>>> That is right. This is an undocumented feature of libusb-win32
>>> that the author of libusb-win32 taught me to use back in 2007.
>>> He is a very nice guy. Unfortunately he seems to be busy lately
>>> so not much progres
Hi list,
This is minimal patch to support FA526 ARMv4 compatible core.
Since it is very similar to ARM920T I tried to reuse as much
code as possible.
CPU and board configs will follow soon.
Changes since v1:
- add fa526 argument description to "target" command documentation
- sync with latest S
On Fri, Jun 19, 2009 at 11:09 PM, Gene Smith wrote:
>> That is right. This is an undocumented feature of libusb-win32
>> that the author of libusb-win32 taught me to use back in 2007.
>> He is a very nice guy. Unfortunately he seems to be busy lately
>> so not much progress in the libusb-win32 fron
Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 10:51 PM, Gene Smith wrote:
>>> Have you tried the following method?
>>>
>>> Run cmd.exe as admin (under Vista) and
>>> D:\libusb-win32-device-bin-0.1.12.1\bin>c:\windows\sys tem32\rundll32
>>> libusb0.dll,usb_install_driver_np_rundll olimex.inf
>>>
>>
On Fri, Jun 19, 2009 at 10:51 PM, Gene Smith wrote:
>> Have you tried the following method?
>>
>> Run cmd.exe as admin (under Vista) and
>> D:\libusb-win32-device-bin-0.1.12.1\bin>c:\windows\sys tem32\rundll32
>> libusb0.dll,usb_install_driver_np_rundll olimex.inf
>>
>
> I didn't see this at first
Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 10:21 PM, Gene Smith wrote:
>>> Run inf-wizard.exe from libusb-win32-device-bin-0.1.12.1 directory.
>> I see it in the bin dir.
>>
>>> Click "Next"
>>> Click the correct VID/PID: "0x058B 0x002B USB Composite Device"
>>> Click "Next"
>>> Save the inf fil
On Fri, Jun 19, 2009 at 10:21 PM, Gene Smith wrote:
>> Run inf-wizard.exe from libusb-win32-device-bin-0.1.12.1 directory.
>
> I see it in the bin dir.
>
>> Click "Next"
>> Click the correct VID/PID: "0x058B 0x002B USB Composite Device"
>> Click "Next"
>> Save the inf file as "ftdi_libusb.inf" in t
Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 5:39 PM, Xiaofan Chen wrote:
>> On Fri, Jun 19, 2009 at 5:35 PM, David Brownell wrote:
For libusb-win32, it is not too bad. You use the INF wizard to create the
INF file and then point to the directory with the inf file.
>>> This requires a lo
On Fri, Jun 19, 2009 at 9:08 PM, Gene Smith wrote:
>> That should be enough. In fact, I kind of believe that you do not
>> need to use the modified libusb0.sys but rather a proper inf file
>> generated by the INF wizard for the whole device.
>>
>
> I used the wizard to generate and install the inf.
On Fri, Jun 19, 2009 at 5:39 PM, Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 5:35 PM, David Brownell wrote:
>>> For libusb-win32, it is not too bad. You use the INF wizard to create the
>>> INF file and then point to the directory with the inf file.
>>
>> This requires a lot of Win32 knowledge.
Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 7:27 AM, Gene Smith wrote:
>> I already have libusb working fine on windows with jlink. Now I am
>> trying to add libftdi. I have built and installed enough of libftdi to
>> enable a build of openocd with --enable-ft2232_libftdi. And I installed
>> the
>> I think we should start to collect the inf files too?
Agree, it would be nice to have a "libusb" - INF file for all ftdi based
chips that point to libusb :-)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.
On Fri, Jun 19, 2009 at 5:35 PM, David Brownell wrote:
>> For libusb-win32, it is not too bad. You use the INF wizard to create the
>> INF file and then point to the directory with the inf file.
>
> This requires a lot of Win32 knowledge. I never even knew
> there *was* such a thing as an INF wiza
On Friday 19 June 2009, Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 3:13 PM, David Brownell wrote:
> > On Thursday 18 June 2009, Michael Fischer wrote:
> >> I think we should start to collect the inf files too?
> >
> > In SVN? I'd think so.
> >
> > Along with installation and upgrade instruction
On Fri, Jun 19, 2009 at 7:27 AM, Gene Smith wrote:
> I already have libusb working fine on windows with jlink. Now I am
> trying to add libftdi. I have built and installed enough of libftdi to
> enable a build of openocd with --enable-ft2232_libftdi. And I installed
> the new libusb0.sys described
Committed.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/driver.c
===
--- src/jtag/driver.c (revision 2284)
+++ src/jta
On Fri, Jun 19, 2009 at 4:06 PM, Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 3:13 PM, David Brownell wrote:
>> On Thursday 18 June 2009, Michael Fischer wrote:
>>> I think we should start to collect the inf files too?
>>
>> In SVN? I'd think so.
>>
>> Along with installation and upgrade instruct
On Fri, Jun 19, 2009 at 3:13 PM, David Brownell wrote:
> On Thursday 18 June 2009, Michael Fischer wrote:
>> I think we should start to collect the inf files too?
>
> In SVN? I'd think so.
>
> Along with installation and upgrade instructions,
> since that's rarely painless on Windows.
For libusb-
On Thursday 18 June 2009, Michael Fischer wrote:
> I think we should start to collect the inf files too?
In SVN? I'd think so.
Along with installation and upgrade instructions,
since that's rarely painless on Windows.
___
Openocd-development mailing l
50 matches
Mail list logo
