New user question about RCM6750 Serial/HDLC capabilities

Rabbit
, , , ,
1

Hello Forum,

I’m evaluating processors for an upcoming project, and the RCM-6750 is one I am considering.
I’ve got the data sheets, DC downloaded, and looked at much of this forum; all good data, but I still have a few questions.

First, a quick description of the project hardware. It will send and receive DMX-512, (async serial @ 250k), have one SPI interface to the main touchscreen controller, and also have another software-selectable serial connection:
#1: 1-Mbit rate, Manchester-encoded HDLC data stream.
#2: 100k async serial (yes, that’s the correct baud rate).
#3: 230.4k, FM0 encoded async serial
#4: 115.2k async serial
#5: 19.2k async serial.

#1-3 would need 2 receive (for data logging) and one transmit in the initial phase, then just single Tx/Rx.

Quite the variety. I was originally considering using a dsPic’s PMP port tied to a Z16C35 processor, and that’s still plan B…

So far, it looks do-able on the RCM6750 IF I change the oscillator to a 16 MHZ part instead of 25MHz. 25Mhz just doesn’t divide to get me the exact 16MHz clock I need for #1’s HDLC.
From what I can see, it’s either both TX/RX external clocks, or both internal. The Rx clock would be encoded in the Manchester stream; I’d need to generate the TX.

The other thing I’m concerned about is the instruction time. There seems to be a lot of overhead in the DC compiler, and with instructions taking upwards of 10 clocks, even at 200 MHz that starts to add up in hardware timing.

And finally…is this going to be an viable choice? Digi hasn’t done much with this since they purchased it. Is there an EOL in the stars for this line?

I’m just trying to make an informed choice. This is my top choice at the moment, but I’m not super strong on C as of yet. maybe it’s a good time to learn!

Thanks for the input,
Jerry

1 Like
2

The Rabbit 6000 processor is the 5th generation Rabbit processor based on the Z80 architecture. The 6000 includes 32-bit registers and lots of additional opcodes, but it’s not a 32-bit processor.

Dynamic C also has a long history, and has only seen updates to the Open Source libraries and samples in recent years. Digi has not released updates to the compiler itself. And it has its own features and quirks that add additional work to porting code to/from the platform.

I personally would hesitate to choose a hardware platform that requires hardware modifications that would (I assume) void the warranty. Changing the hardware clock would require changing Dynamic C libraries that assume a 25MHz clock, and would break the Ethernet capabilities of the device (which you may not need).

I don’t know enough about “FM0 encoded” to know whether the Rabbit’s UARTs can perform that work for you.

I’ve been a long-time user of Rabbit hardware, but if I was starting a project like this from scratch, I’d make sure there weren’t any hardware platforms that are a better fit.

If you decide to explore the potential, I’d start with proof of concept code to validate the 1Mbps HDLC and 230.4Kbps FM0 encoding. And see if there’s any way to use an external clock for the HDLC stream.

3

Thanks Tom. I was hoping for a single chip/module solution, but I think I’ll go with the dsPIC slaved to a comm chip solution. I’ve evaluated about 30 different ideas and that seems to be the best. I’ve been intrigued by the Rabbit line since it came out; maybe someday I’ll use one…but not today.