Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] TCF and microcontrollers/uC (e. g. AVR or ARM Cortex)

Hi Christophe,

yes, it was quite easy to find them, thanks for the hint!
  * http://dev.eclipse.org/mhonarc/lists/tcf-dev/msg00370.html
  * http://sourceforge.net/p/openocd/mailman/message/28348882/

However, it seems that aside of some discussions there has not been
much progress in the meantime concerning interfacing OpenOCD from TCF.

I will definitely have a look at the OpenOCD source to see how
complicated things would be.

Greetings,
  Rainer


On Tue, Feb 24, 2015 at 2:13 PM, Christophe Augier
<christophe.augier@xxxxxxxxxxxxx> wrote:
> Hi Rainer,
>
> you should probably take a look at the openocd project [1] where you can
> find all the low-level parts for JTAG, SWD and other hardware debugging
> interfaces.
>
> There have been discussions in the past on writing a TCF Agent on top of
> openocd, you should be able to find them easily.
>
> - Christophe
>
> [1] http://www.openocd.org/
>
>
> On 02/24/2015 01:32 PM, Rainer Poisel wrote:
>>
>> Hi Eugene,
>>
>> thanks for your response. That sounds interesting to me. What would be
>> the starting point for implementing such a bridge? Or what would be
>> the missing 10% of code?
>>
>> I think that I would need to implement both the interfaces in the
>> "machine" as well as the "system" directory of the agent source? After
>> studying the "TCF agent porting guide" and the "TCF Agent Prototype
>> Implementation" documents it is not completely clear to me.
>>
>> Aside from that, would it be possible to implement a TCF agent (i. e.
>> the bridge) in JAVA as well?
>>
>> Regards,
>>    Rainer
>>
>>
>> On Mon, Feb 23, 2015 at 7:48 PM, Eugene Tarassov
>> <eugene.tarassov@xxxxxxxxxx> wrote:
>>>
>>> Hi Rainer,
>>>
>>>> Would TCF be suitable for communicating with systems that do not have an
>>>> operating system such as microcontrollers?
>>>
>>> Sure. One way to do is to use JTAG. TCF provides over 90% of code needed
>>> to build very powerful JTAG debugger. In such case, TCF agent runs on a host
>>> and communicates with the microcontroller over JTAG cable.
>>>
>>> Regards,
>>> Eugene
>>>
>>> -----Original Message-----
>>> From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On
>>> Behalf Of Rainer Poisel
>>> Sent: Sunday, February 22, 2015 10:59 PM
>>> To: TCF
>>> Subject: [tcf-dev] TCF and microcontrollers/uC (e. g. AVR or ARM Cortex)
>>>
>>> Dear list,
>>>
>>> recently I have spent some time on learning what TCF is and how things
>>> actually work. To me it's an impressive and powerful framework. Now I
>>> was wondering:
>>>
>>> Would TCF be suitable for communicating with systems that do not have
>>> an operating system such as microcontrollers?
>>>
>>> My use cases would be to download code or to debug downloaded code. I
>>> stumbled upon the TCF porting guide
>>>
>>> (http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/plain/docs/TCF%20Agent%20Porting%20Guide.html)
>>> and I have seen that Xilinx supports TCF for their devices.
>>>
>>> Regarding the ARM Cortex devices (e. g. STM32F4) - is there anything
>>> available yet for these 32-bit microcontrollers? I don't know whether
>>> the Xilinx approach works for all ARM Cortex microcontrollers. I have
>>> used the CDT together with GDB to debug applications but would it be
>>> possible with the TCF as well?
>>>
>>> And how about even more resource limited devices such as AVR
>>> microcontrollers?
>>>
>>> What would be the preferable approach to support such devices -
>>> implementing a TCF agent that runs on a host and works as a bridge to
>>> the microcontroller (e. g. TCF over TCP/IP to a custom serial
>>> protocol) or running a stripped down agent implementing the serial
>>> protocol directly on the microcontroller?
>>>
>>> Thanks in advance for giving me a few hints,
>>>    Rainer
>>> _______________________________________________
>>> tcf-dev mailing list
>>> tcf-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/tcf-dev
>>>
>>>
>>> This email and any attachments are intended for the sole use of the named
>>> recipient(s) and contain(s) confidential information that may be
>>> proprietary, privileged or copyrighted under applicable law. If you are not
>>> the intended recipient, do not read, copy, or forward this email message or
>>> any attachments. Delete this email message and any attachments immediately.
>>>
>>> _______________________________________________
>>> tcf-dev mailing list
>>> tcf-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/tcf-dev
>>
>> _______________________________________________
>> tcf-dev mailing list
>> tcf-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/tcf-dev
>
>
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/tcf-dev


Back to the top