On Fri, 24 Jun 2011 16:32:54 +, Tomek CEDRO wrote:
Cool, I will add new field into layout structure that will indicate
forbidden bits to bitbang, this field will be zero by default so all
bits are allowed, driver author can add some value of this field to
the specific layout - that value AND
The best is to standardize at a lower level ... and to forget the idea to have
the possibility to bitbang from the TCL of the openocd.
/
//That's as for the SWD, we have to standardize some function call in the
ft2232, and avoiding bitbang access from higher-level.
//
//That's not simple to
Cool, I will add new field into layout structure that will indicate
forbidden bits to bitbang, this field will be zero by default so all
bits are allowed, driver author can add some value of this field to
the specific layout - that value AND port mask to set/bitbang will be
checked in
Simple and true :-) Each interface has its own config file anyway, so
this file can contain also signal definition for that interface. If
interface has no signals defined, no signals will be defined, so there
is no worry.
Here we have to select between Simple and Safe !
We know that a large
The best is to standardize at a lower level ... and to forget the idea to have
the possibility to bitbang from the TCL of the openocd.
That's as for the SWD, we have to standardize some function call in the
ft2232, and avoiding bitbang access from higher-level.
That's not simple to dev,
/My objective is not to block feature.Never,never,never ... But we have
//to avoid any trouble in generic ft2232 driver regarding specific layout.
//That's all.
//Your TCL bitbang will control the port of the FTDI from an higher level
//than FT2232.c. OK but you TCL bitbang is specific to the
On Tue, Jun 21, 2011 at 3:57 PM, Phil Fong fong...@yahoo.com wrote:
I think there is an misunderstanding here. My reading of Tomek's emails
indicates there is a layout specific mechanism to filter which pins can be
bitbanged. The interface config file will define which pins can be
bitbanged
My objective is not to block feature.Never,never,never ... But we have
to avoid any trouble in generic ft2232 driver regarding specific layout.
That's all.
Your TCL bitbang will control the port of the FTDI from an higher level
than FT2232.c. OK but you TCL
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name |Mask| Value
--
interface_signal add led 8000
interface_signal add led 8000
There are no signals
On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch
laurent.ga...@amontec.com wrote:
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name | Mask | Value
--
Sergey Lapin wrote:
On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch
laurent.ga...@amontec.com wrote:
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name |Mask| Value
Please refrain from shouting(using uppercase). It's more likely
that people will ignore your email than read it.
As a maintainer, I'm not terribly excited about bitbanging and other
non-CPU related protocols. Projects like UrJTAG pursue
this sort of avenue. I'd like to see OpenOCD focusing on
Hi Øyvind Harboe,
Please refrain from shouting(using uppercase). It's more likely
that people will ignore your email than read it.
Thank you for the advice.
As a maintainer, I'm not terribly excited about bitbanging and other
non-CPU related protocols. Projects like UrJTAG pursue
this
Laurent,
1. If you create cable that have ADC onboard (like KT-LINK) then it is
easier to write simple TCL script to read ADC than rewrite whole
driver in the source code.
2. If you need to program I2C, SPI, or other kind of memory, you
simply write simple TCL script to do so, no need to rewrite
Am 06/20/2011 02:44 PM, schrieb Laurent Gauch:
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name |Mask| Value
--
interface_signal add led 8000
Please explain the dangers.
If a driver can't implement a sane feature safely, then the driver shouldn't
implement that feature
One of the reasons I'm not excited about adding the IO features to OpenOCD
is that we have barely enough maintainer resources as is. If a maintainer
came out of
(Resending since I forgot to cc the list)
There is at least one useful end-user use case for bitbanging. There
are many IO lines unused on the FTDI port that can be used for GPIO.
Some dongles expose these and of course a custom FTDI interface that you
integrate with your prototype can
Am 06/20/2011 08:14 PM, schrieb Øyvind Harboe:
Please explain the dangers.
If a driver can't implement a sane feature safely, then the driver shouldn't
implement that feature
Fine.
I *do* think hardware should be designed in a way that it can not be
damaged by software, but if existing
On Mon, Jun 20, 2011 at 6:14 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
(..) I would dearly like to see SWD done before
opening the floodgates to GPIO and other serial protocols.
SWD is packed-based half-duplex bus that defines TRN operation for bus
direction change and buffers
On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch
amotec-laurent_ga...@mail.axianet.ch wrote:
Your TCL bitbang will control the port of the FTDI from an higher level than
FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you
accept or not the use of the TCL procedure,
On Mon, 20 Jun 2011 16:37:32 +, Tomek CEDRO wrote:
Laurent,
1. If you create cable that have ADC onboard (like KT-LINK) then it
is
easier to write simple TCL script to read ADC than rewrite whole
driver in the source code.
Yes, easy but dangerous, because you are layout specific !!!
Tomek CEDRO wrote:
On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch
amotec-laurent_ga...@mail.axianet.ch wrote:
Your TCL bitbang will control the port of the FTDI from an higher level than
FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you
accept or not the use
22 matches
Mail list logo
