NETMF Uart and FEZ Hydra

I need to use SerialPort with Hydra board, but not in a Gadgeteer context. I see that on socket 6 the serial lines are RXD2/TXD2. It means what COMx for netmf, COM3 ?
I’ve tried, but no luck … (may be this has to be added to wiki)

IIRC there was a bug in an early Hydra firmware that only had COM1 enabled, I assume that’s not what you’re hitting here (although you could). I could have sworn there was a recent thread that talked about pinouts and COMx mapping but I can’t seem to locate it now :frowning: Maybe I’m getting oldtimers kicking in, but in reverse…

edit: if I had to guess, I would have said COM2=RXD2/TXD2

Using GTI.SerialPort on the socket 7, I see in debug it is instantiated as COM2. In fact switching to System.IO.Ports and opening as COM2 (=Socket7) I can send out data and It works.

It is COM4

Lol nice table. This info must be kept in the wiki.

I have a related question. Is there a way to use the com port functionality of the PB1/ RXD3 and PB0/TXD3 pins on socket 13 and 14 of the Hydra?

Sockets 13 and 14 don’t show as “U” so I think not. From the Wiki:
COM1 = Socket 5 -->> On Schematic it is DTXD\DRXD
COM2 = Socket 7 -->> On Schematic it is TXD0\RXD0
COM3 = Socket 4 -->> On Schematic it is TXD1\RXD1
COM4 = Socket 6 -->> On Schematic it is TXD2\RXD2

So I think you have 4 COM ports only

What Brett said correct, the Hydra officially supports only 4 COM ports as RXD3 and TXD3 are not on a single U socket. However, it should be possible to customize the firmware to allow for the 5th port to be utilized although not in the Gadgeteer capacity. You would need to modify the platform_selector.h file and the UART code of the AT91 to activate the 5th port.

I was hoping there may be something in the plain NETMF libraries that would work on a Gageteer device. Simillar to the tutorial But I guess not. Looks like custom firmware is the answer.

Thanks for the responses.

The “problem” (really just a limitation in what the firmware exposes) is that the definition of COM5 is not done; if it was, then you’d still need to “steal” those pins from the two sockets (potentially stopping them from being useful for other tasks) and then you could access them in software (Gadgeteer or not). And just to confirm, you’re needing to use more than 4 serial ports ? I love serial, but I’d never considered needing more than that many.

It’s not that I’m using 4 serial ports, its that I need an analog in port (to monitor a battery), and a TX (to control servos), and I didn’t want to waste two complete sockets to use two pins. So I was going to use a breakout board and wire off of socket 14. Maybe I could bit bang a serial port on a GPIO pin that’s on an analog socket, but then I loose
the built in serial port functions.

Either way I think it might be worthwhile for the firmware (in some way organized way) to expose all the functionality of the pins so that you could get the most use out of them. But that kind of defeats the Gageteer model.

OK, that makes sense.

I do agree with you, it’d be nice if the firmware exposed all the peripheral options the processor had, but there’s at some point a limit on how much time to invest in things that don’t make sense to who is implementing it - and while the current firmware is open source, GHI are the only ones using it, on Hydra (to the best of my knowledge anyhow). So they’d be the ones who would make sense of the requirement, and in this scenario I think that it would be a feature not many people would use and may not make sense to implement. It is something you could take forward if you wanted to - there are now a few people who have used open/free tools to compile the Hydra firmware if you search around - heck if TaylorZA pops his head in here and sees this post, he might even add it in his sleep :slight_smile: