UART tool for Linux/OSX?

[Steven Bell]

From what I understand, there is currently no Linux or OSX tool for
communicating with a PIC UART using the pickit2. Is this correct?
Would it be possible to develop an open-source driver to read data
from the UART with the pickit2? If so, how much work is it likely to
be, and where would I start?
Thanks,
Steven

[lementec fabien]

what about pk2cmd?

[Steven Bell]

pk2cmd just downloads hex files, right?  I'm interested in a way to receive printf( ) output from the chip.
Steven

[Jeff Post]

I'm not sure what you mean by read data from the uart with the PICkit2. Serial
port interface software in Linux is not difficult to write. If you can
communicate directly through a serial port, why would you need the PICkit2 in
between?

Jeff

[Xiaofan Chen]

On Tue, Jan 13, 2009 at 9:32 AM, Jeff Post <j_p...@pacbell.net> wrote:
> I'm not sure what you mean by read data from the uart with the PICkit2. Serial
> port interface software in Linux is not difficult to write. If you can
> communicate directly through a serial port, why would you need the PICkit2 in
> between?

In the Windows PICkit 2 PC application, there is a UART tool. Basically
PICkit 2 acts as a rudimentary USB to Serial Converter here without the
level shifter to RS232 kind of electrical signal level. Normally USB to
Serial converter uses USB CDC ACM protocol and is supported by
the Linux kernel with usbserial or cdc-acm driver. But in the case of
PICkit 2, it is using a vendor specific USB HID protocol as the underline
protocol. So the idea is to write a tool to use the PICKIT 2 pseudo
UART function. I guess it can still use the low level libusb (linux)
or native HID (Mac OS X) function currently as the base.

Xiaofan

[Mark Rages]

A Unix serial port can be thought of a special file that supports
read(), write() and a few special ioctl() calls (to set baudrate, stop
bits etc). So the easiest way to make a serial port might be to
extend pk2cmd to support these calls, then implement the special file
in userspace using libfuse. Then no kernel hacking or USB trickery is
required.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
mark...@midwesttelecine.com

[Jeff Post]

On Tuesday 13 January 2009 07:08, Mark Rages wrote:
>
> A Unix serial port can be thought of a special file that supports
> read(), write() and a few special ioctl() calls (to set baudrate, stop
> bits etc). So the easiest way to make a serial port might be to
> extend pk2cmd to support these calls, then implement the special file
> in userspace using libfuse. Then no kernel hacking or USB trickery is
> required.
>

I have code for Linux to access serial ports that is used in picp. If anyone
wants it, let me know.

Jeff

[Mark Rages]

I think you are talking about accessing a serial port, while I'm
talking about providing a serial port for other code to access.

[walter....@microchip.com]

PICkit 2 has the capability to emulate UART hardware, but does not
appear to software or the OS as a standard serial port. The USB HID
interface is still used for software to set the port baud rate and
send and receive data.

Either a library making this easier to access from software or a
"driver" to interface to the PICkit 2 over HID and make it accessible
via file methods may be possible.

I anyone here is interested in taking up such a project, I would be
willing to assist with the USB interface to the PICkit 2.

> markra...@midwesttelecine.com

[Jeff Post]

On Tuesday 13 January 2009 10:17, walter....@microchip.com wrote:
> PICkit 2 has the capability to emulate UART hardware, but does not
> appear to software or the OS as a standard serial port. The USB HID
> interface is still used for software to set the port baud rate and
> send and receive data.
>
> Either a library making this easier to access from software or a
> "driver" to interface to the PICkit 2 over HID and make it accessible
> via file methods may be possible.
>
> I anyone here is interested in taking up such a project, I would be
> willing to assist with the USB interface to the PICkit 2.
>

Please privately send me whatever technical documentation you have on PICkit 2
UART emulation, and I'll have a look at it to evaluate how much time would be
needed for the project. Classes start in two weeks (I'm teaching statistics
again, yay!) so I'd like to get a good handle on the project by then.

Jeff

[Daniel Turner]

I have found the PICKIT2's UART tool to be quite inconvient to use due
to the fact that you have to change the way the pk2 is connected to
your device. A TTL Serial -> USB device is much more useful IMHO. And
you gain the ability to treat it as a true serial port (TTY).

> communicating with a PIC UART using the pickit2. Is this correct?

> Would it be possible to develop an open-source driver to rad data

> from the UART with the pickit2? If so, how much work is it likely to
> be, and where would I start?
> Thanks,
> Steven
>
>
>
> >
>

--
-Daniel
KD5UZZ
www.w5yj.org

[walter....@microchip.com]

On 14 Jan, 13:20, Daniel Turner <danielttur...@gmail.com> wrote:
> I have found the PICKIT2's UART tool to be quite inconvient to use due
> to the fact that you have to change the way the pk2 is connected to
> your device.

I'm not quite sure what you mean by "change the way the Pk2 is
connected to your device." Would you elaborate on that?

[Daniel Turner]

I have not used the PICKIT2's UART tool in some time, so I may have
the pins wrong, but IIRC the UART tools requires the PGD and PGC be
connected to the TX and RX pins of the PIC. On most (all?) of the PICs
I use the PGD and PGC pins are different from the UART pins of said
PIC. This means that in order to first program the PIC I must have
those pins connected to (if using a 16F876a) to
Bhttp://www.space.com/scienceastronomy/090114-first-moon-map.html5 and
B6. Then, to talk to the PIC's UART I have to change to C5 and C6 (I
may have those pins wrong also). I find it much easier to use a TTL
<-> Serial adapter in addition to the PK2.

Of course, this is not always the case, you can use software to
emulate a UART on the applicable pins, thus no longer requireing you
to move your connections. But then you do not get to use the UART's
features (buffer, ISR, etc).

--
-Daniel
KD5UZZ
www.w5yj.org

[walter....@microchip.com]

I see, thanks. Some dsPIC30 devices share the PGx and TX/RX pins, but
most PICs do not.

Note that it is possible to use 2 PICkit 2's on the same PC (with 2
instances of the software), so one could be used as, in effect, a
dedicated TTL serial tool. :)

Another possibility with only 1 PICkit 2 is to dedicate the PGx pins
to programming, leave them as inputs (tristate) in the code, and
connect them appropriately with the TX/RX pins.
Thus during programming, the TX/RX pins are held in tristate, so the
PGx signals get to the PGx pins. During code execution, the PGx pins
are effectively tri-stated (inputs) and the TX/RX signals get through
without having to move the PICkit 2.

On 15 Jan, 18:05, Daniel Turner <danielttur...@gmail.com> wrote:
> I have not used the PICKIT2's UART tool in some time, so I may have
> the pins wrong, but IIRC the UART tools requires the PGD and PGC be
> connected to the TX and RX pins of the PIC. On most (all?) of the PICs
> I use the PGD and PGC pins are different from the UART pins of said
> PIC. This means that in order to first program the PIC I must have
> those pins connected to (if using a 16F876a) to
> Bhttp://www.space.com/scienceastronomy/090114-first-moon-map.html5and
> B6. Then, to talk to the PIC's UART I have to change to C5 and C6 (I
> may have those pins wrong also). I find it much easier to use a TTL
> <-> Serial adapter in addition to the PK2.
>
> Of course, this is not always the case, you can use software to
> emulate a UART on the applicable pins, thus no longer requireing you
> to move your connections. But then you do not get to use the UART's
> features (buffer, ISR, etc).
>

> On Wed, Jan 14, 2009 at 4:13 PM, walter.kicin...@microchip.com

[Daniel Turner]

I was wondering if there was a way to do that, it was my first
thought. I just didn't want to damage the PIC. There is still the
issue of reconfiguring the software, but all-in-all, not a bad
solution.

On Fri, Jan 16, 2009 at 1:16 PM, walter....@microchip.com
<walter....@microchip.cAnother possibility with only 1 PICkit 2

is to dedicate the PGx pins
to programming, leave them as inputs (tristate) in the code, and
connect them appropriately with the TX/RX pins.
Thus during programming, the TX/RX pins are held in tristate, so the
PGx signals get to the PGx pins. During code execution, the PGx pins
are effectively tri-stated (inputs) and the TX/RX signals get through
without having to move the PICkit 2

--
-Daniel
KD5UZZ
www.w5yj.org