Suggestion to change how PTA1 and PTA2 are overwritten when using USB Serial on KL25Z

15 Oct 2013

Hello All, When making a USB serial object on KL25Z:

Serial pc(USBTX, USBRX);

pins PTA1 and PTA2 are overwritten to be serial communication too. This is very unclear from the communication, and to me a waste of resources; I want to use those pins!

My suggestion:

  • Document this behaviour in "Serial" and "SerialPC" in the handbook, preferably in one of those yellow / orange boxes
  • Change the code to let the user disable this "feature", for example like this:

Serial pc(USBTX,USBRX,NO_PHYSICAL_Pins);
15 Oct 2013

That 'feature' cannot be disabled. It is hardwired that way: PTA1 and PTA2 are USBTX and USBRX. Internally they are also routed to the interface chip.

Imo it was a bad design decission of freescale. Probably to make it more like arduino, but to me it makes little sense. That said there is nothing that can be done to fix it by mbed staff.

15 Oct 2013

Erik - wrote:

That 'feature' cannot be disabled. It is hardwired that way: PTA1 and PTA2 are USBTX and USBRX. Internally they are also routed to the interface chip. Imo it was a bad design decission of freescale. Probably to make it more like arduino, but to me it makes little sense.

"it makes little sense": You could say that again.... If I want serial hardwired I would like to declare it that way!

Erik - wrote:

That said there is nothing that can be done to fix it by mbed staff.

At least document CLEARLY that this happens. I didn't know, and found out because of some discussions / questions. The USBTX/USBRX names are misleadingly suggesting they're not on PTA1 and PTA2. On the Serial, SerialPC or KL25z page there's no notice that USBTX/USBRX in fact use the hardware pins.....

Knowing what you just told me the 'stdio' remark in the pinout diagram makes more sense, but it's too indirect to be clear....

15 Oct 2013

@First Last

I wonder why you complain here and also in the questions section?

1. It's documented in the code (PinNames.h). Please check mbd sources

 // USB Pins
    USBTX = PTA2,
    USBRX = PTA1,

2. If you have checked schematic, you would have found out that those 2 pins are used for the serial communication.

So at least on 2 places are those. Do you know why those 2 pins are defined as USBTX, USBRX ? For portability. No matter what platform you take, it should work.

undefine those 2 defines and redefine them as you wish, before the definition of the object.

#undef USBTX
#define USBTX PTA3


@Erik Can you explain how it was a bad decision?

Regards,
0xc0170

15 Oct 2013

Don't be angry at me :P

First, I have to say for a new user needing to check PinNames.h or tracing schematics isn't what you like to be doing ;). Also I know the way the mbed library is build, but for a new user it can take quite some time to find PinNames.h.

PTA1 and PTA2 are on arduino shields the 'default' pins for serial connection, all others need a software serial. On the arduino the USBTX and USBRX also share those pins, since their atmega has only one serial port, so they didn't have much choice. The Obvious downside is that you cannot use both a serial connection with your PC and with a shield, but on a limitted device as an atmega328 you have to make compromises.

Then you got the KL25Z. I understand they want to make it like an arduino, but that doesn't mean imo you should also copy its weaknesses when you dont have to. (You cant do much about the stupid pin spacing for example). Considering PTA1 + PTA2 and USBTX + USBRX are the most used serial pins when you want something arduino compatible, imo it makes sense to me to put them on a different hardware UART, so you can both communicate serial with an arduino shield, and still send debug information to your PC. Considering the KL25 has 3 UARTs and a gazilion possible ways of connecting them to pins this shouldn't be a problem.

If you really want it to be like arduino you could also connect them to one UART but with different physical pins. Not what I personally would do, but then at least you can disable the UART on PTA1 and PTA2 while still communicating with your PC.

From just looking at the pinout of the KL25 and without being hindered by any info on how it should be routed on the PCB, I would connect PTC3 and PTC4 as USBTX and USBRX. (Or them to the place of PTA1 and PTA2, and keep them as USBTX and USBRX). Since these pins are on the inside row they are less important: standard shields don't use them. You could then either keep them connected to USBTX and USBRX, or just make those pins NC, something to say for both options.

But the main upsite is that this way you can debug to your PC while also using the default hardware serial port of arduinos.

16 Oct 2013

@Erik: thanks for clarifying, that is exactly my issue

@Martin:

  • Thanks for pointing out the portability issue, hadn't thought about that yet.
  • I inadvertently put it in questions, but I can't find how to 'remove' a question. If you tell me how, I'll remove it there.
  • I'm very used to diving into source code, writing all kinds of libraries and interrupt handlers on bare metal myself. In the case of mbed, I'm very happy with using it as a "quick development platform", with GOOD documentation. Until now I've never had any issues, I could just happily code, and not be bothered with tricky issues with pinning. Very,very happy with that.... Just get something going as a functional prototype.
  • I'm using the mbed for Biomedical Technology students to write code. Most of them have no previous programming experience, and are also new to hardware. They're following a kind of "crash course", and I selected the mbed platform because of the clear documentation. I'm giving them a lot of example programs, and they're already having trouble grasping that PwmOut pins should have "PwmOut pin numbers" (i.e. read the friendly diagram), and that encoders that need interrupts should be on PTAx or PTDx pins. I think you can imagine that at that level diving into PinNames.h or the schematic is too much. As per the reasoning of Erik, I think the design could have been done smarter, but given the way it is now, an update in the documentation (Serial, SerialPC, maybe KL25Z Introduction) would be in place.