Microcontroller Project Recommendations

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

 

I am currently at the start of a project which i'm currently scoping out, but one part of this project will require a micocontroller to run as an ethernet to RS422 bridge. As much as i've had a general interest in microcontrollers, ive never had the chance to use one... until now. I have done a reasonable amount of C programming + general design work as an engineer but nothing that has required a microcontroller.

 

My microcontroller application is to interface between a host PC, running Windows XP and a device that runs async RS422 busses at 10Mb/s. This solution has to be an external "plug in"  to the existing PC eg no add in PCI cards and USB not an ideal interface for this setup, hence me looking to "roll my own" RS422 interface. The interface would be primarily used to transmit data, continually to the RS422 device, with the microcontroller bridging the data transmit from the host PC via ethernet to RS422 10Mb/s. Data could be transmit from the host PC a single 9 bit data word at a time so I don't have any need for large FIFOs or memory buffers, nor is there any timing requirements for the interval between data words.

I realise this is a very broad question but in general is what would be a good suite of products to begin with? My research so far has found 32 bit MCUs somewhat commonly have an ethernet port, just requiring the magnetics / resistors to complete the interface. Can anyone recommend a device which is readily available, a dev board containing the same device w/ethernet port implemented  + debugger / emulator to use. Raw cost overall on this is generally nor important, as it will be a "one of " built so development time will be the far more costly factor.

 

In addition to this general recommendation, i have two questions that come to mind;

The first one is the handshaking on the device i am communicating with is a little odd. It receives "9N1" serial data, but acknowledges this with two bits, effectively a start and stop bit, no data. I can't see any UART that allows you to configure the receive data to be 0 data byes, and i guess for good reason. handshaking is the same in both directions, so if the device transmits data, I have to ack each 9N1 word with the same 2 bit ack. My only thought here is to have OR gates, logically OR a UART output with a GPIO output to either transmit data via the UART or provide an ack with the GPIO output. This OR'd output would then drive my RS422 transceiver. This setup would be mirrored for the receive side with the transceiver being directly connected to a UART port + GPIO port for detection of the ack bits. My question is, is there a better way to do this internal to the micro controller itself ? Can i switch a microcontroller port between being a UART or a GPIO on the fly, depending on if i am transmitting or receiving? I am asking this question now as it may relate to the functionality available in the device I use. I would prefer to not use a bit bang transmitter/receiver on GPIO pins when I have perfectly good UARTs available.

 

Secondly, it would be ideal if I can program this device in its end environment without the need for a USB style programming / debugger. Essentially if I placed a brand new device on the PCB, I could detect it is blank / not functioning and then load the required software image. I have a bunch of GPIOs available to use in the host PC which I have used for I2C / SPI interfaces previously, which i could potentially use to program the microcontroller or external flash / EEPROM if this was easier to program. Is there any solution here which is possible? I would easily be able to write a routine to drive an SPI bus to write data 'x' to address 'y' and repeat for each byte in the image to be programmed. If there are masses of different message types / formats / sequences that have to go over the SPI bus to program a device, then it would be too much to implement.

 

Any suggestions welcome.

Last Edited: Fri. Mar 2, 2018 - 10:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An 8-bit AVR would not be able to do 10Mbits/second.  And Ethernet as well.  I suggest a low-cost ARM processor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

10Mbit async? Sounds a bit brave to me! Bit jitter might start to become significant at those speeds. I'd suggest a synchronous method. Manchester encoding comes to mind.

Also, most uarts will use a 16x or 32x clock, so we're talking a peripheral clock of 160MHz or 320MHz. I dare say this spec alone will narrow your choices. What you could do is use two spi ports - one for tx and one for rx. You'll need hardware to do clock recovery on the rx. SPI ports should be able to do 25MHz on many of the upscale parts. They usually have fifos and dma. Many manufacturers spi peripherals have settable bit counts.

 

I don't know what 32bit micros you've been researching that only need the magnetics for ethernet - apart from the SoC devices for wireless routers and the only single chip micro that comes to mind is the TI TIVA series. Most others require an external phy chip.

 

 

As for programming blank devices, most use a JTAG or SWD port to program the internal flash. Some have built in bootloaders, others you need to program a bootloader if you want to load code via other means.

 

For a 'one off', maybe something like a Beaglebone black - it has two 200MHz co-processors that you could use to bit bash your unique uart along with a 1GHz 32 bit cpu running Linux.

 

In all, you've got some challenging requirements. I don't think this post should be in the UC3 forum - that product is fading away.

Last Edited: Fri. Mar 2, 2018 - 02:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sdavy wrote:
... in general is what would be a good suite of products to begin with?
Some UC3 have an Ethernet MAC, most recent are UC3C, but the UC3C evaluation board went EOL and am no longer able to locate the third party Vulcano UC3C board; the UC3C-EK alternate is STK600 though will need to attach an Atmel-ICE and "somehow" the Ethernet PHY.

PIC32MZ EF has an Ethernet MAC and the Microchip boards have a debugger and an optional Ethernet PHY; for third party, chipKIT may be close though, IIRC, would need a PICkit 3 or 4 for a debugger.

There's a plethora of arm boards with Ethernet and debuggers or an inexpensive debugger (FOSS OpenOCD) can be operated.

sdavy wrote:
... is there a better way to do this internal to the micro controller itself ?
XMEGA Custom Logic (XCL) can do that but at an order of magnitude of the required 10Mb/s.

Could get the 10Mb/s via a cPLD that can be attached (SPI, EBI, PIC32 PMP/EPMP, UC3C local bus, etc) to the MCU with the Ethernet.

 


http://www.microchip.com/wwwproducts/en/at32uc3c0512c

Microchip Technology Inc

Microchip

Product Change Notification - WE164803 - 14 Dec 2016 - End of Life (EOL) of selected AT32UC3C-EK Evaluation Boards

http://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=WE164803

http://www.microchip.com/developmenttools/productdetails.aspx?partno=atstk600

http://www.microchip.com/developmenttools/productdetails.aspx?partno=atatmel-ice

Microchip Technology

Curiosity PIC32MZEF Development Board - DM320104

http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM320104

Microchip Technology

PIC32MZ Embedded Connectivity with FPU (EF) Starter Kit - DM320007

http://www.microchip.com/developmenttools/ProductDetails.aspx?PartNO=DM320007

https://chipkit.net/

Microchip Technology

MPLAB PICkit 4 In-Circuit Debugger - PG164140

http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=PG164140

ATxmega32E5 - 8-bit AVR Microcontrollers

http://www.microchip.com/wwwproducts/en/atxmega32e5

...

 

The XMEGA E devices feature an innovative XMEGA Custom Logic module (XCL) consisting of two independent 8-bit timer/counters and two lookup tables used for defining glue logic. ...

...

In addition it can together with the USART enable customized communication protocols. 

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i was looking at 32 bit MCUs. As the area of electronics is new to me, can you suggest a specific manfacturer / series of ARM processor?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

10Mbit async? Sounds a bit brave to me!

Unfortunately, the 10Mb async is set in stone. This is the interface to the unit that i need to communicate with. 

 

Many manufacturers spi peripherals have settable bit counts.

The few UARTs i looked at had setting bit counts in the region from 5 to 9. No way (that i could see) to set a bit count of 0 or have any way to detect the 2 bit ack.

 

In all, you've got some challenging requirements. I don't think this post should be in the UC3 forum - that product is fading away.

I started this post as a general question but had to pick an area it belong to. Can you suggest another device to use? I would much prefer to put a manufacturer's chip on a PCB + my associated circuitry rather than  beaglebone / rasberry pi + my PCB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
... that product is fading away.
fyi, UC3 went legacy at Atmel then NRND at Microchip though there's still UC3 activity :

http://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=AT32UC3

UC3C is in the automotive catalog so UC3C may be around for a while.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The beaglebone black is based on a freely available TI chip or there’s the Octave Systems device that incorporates the ram and pmic.
Your requirements seem to be a bit ‘special’ in regards to the 10Mb async, so you’re going to have to do the legwork. How does the PC end generate the 10Mb signal? What chip does it use?

Last Edited: Fri. Mar 2, 2018 - 03:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
... or there’s the Octave Systems device that incorporates the ram and pmic.
https://www.avrfreaks.net/forum/embedded-linux-modules#comment-2278206

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When needing 10Mb/s async you're out of the region of small uc's.

You will probably want a uC with a few hundred MHz clock and dma.

 

A nice overview of the somewhat "bigger" uC boards is on the mbed site.

If you only select development boards with ethernet you've still got 28 out of the 131:

 

https://os.mbed.com/platforms/?connectivity=2

 

I have not done much with mbed yet.

I've avoided them for quite some time because it's "cloud" based, wich is just mist to me.

But the world is evolving.

Just recently I made a blinking led with platformio and the mbed platform.

Even though the Platformio core are "just" some python scripts they encapsulate quite some magic.

Platformio pulls a recent ARM compiler from the internet and all mbed libraries and configures a project with scons in just a few lines of code.

 

And then I discovered the mbed platform is (mostly?) based on some rtos and I'm not sure if I want to dive into that. My background is mostly small AVR's and an rtos would be overkill.

Those ARM boards can have a MB of Flash and a RTOS might be feneficial there.

 

If you don't want to use mbed you can still use their site to select a development board. Among the ethernet capable boards you can still choose between 6 manufacturers, and each will have example code, AN's etc.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From PIC32MX UART doc:

and

Edit: one options is this: http://www.microchip.com/Develop...

 

Last Edited: Fri. Mar 2, 2018 - 03:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your requirements seem to be a bit ‘special’ in regards to the 10Mb async, so you’re going to have to do the legwork. How does the PC end generate the 10Mb signal? What chip does it use?

The PC end will communicate with the microcontroller / processor over the ethernet link. So,

 

PC <---> micocontroller Ethernet / RS422 bridge <----> RS422 equipment 

 

The Ethernet part is not set in stone but this is the fastest interface available to communicate to the micocontroller driving the RS422 side. Next best is RS232 / RS422 at 115k. At this stage the Ethernet link is the easy part. hard part is the 10Mb RS422 with 2 bit ack.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you tell us what the magic 10Mb equipment is? Does it use a named protocol?
Note, from what you’ve explained, the ack is just sending 0xfe in the normal manner. The start bit is a logic 0, the first data bit is logic 0 and the rest of the bits are logic 1s.

Last Edited: Fri. Mar 2, 2018 - 04:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unfortunately, no I can't give any more information on the equipment. There is a propriety framing protocol that is used but it is still just a series of "9N1" serial words with each word being ack'd with 2 bits.

 

The ack is defined as a two bits only, but you are correct, I can't see any issue with sending the two ack bits as the start bit and the first data bit, then setting the rest of the 8 data bits + stop bit to 0. The ack would also be received as a valid msg with the first ack bit being set as the start bit, the second ack bit being the first data bit and the rest of the msg being data being read as 0.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stop bit is always 1. Start bit is always 0.
Tx idles at logic 1. For a normal uart that is.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In this case start bit is defined as 1 and stop bit is defined as 0. I would assume this means Tx idle's at logic 0 as to correctly detect the start bit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Inverting the data with RS422 is just a matter of swapping + and -.

I gather you have a spec for this protocol or is this what you’ve observed?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some of the UARTs i have looked at also have a register for inverting the Rx and Tx levels, but thanks for the tip on swapping + and -.

 

Yes, start and stop bits are from the spec on the protocol.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You might want to look at the same70 series chips. They run up to 300MHz. You’ll need to read the specs on the clocking and the usart to see how fast it can go.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your project setup seems to imply to have to be compatible with some existing protocol ?

What hardware does that have?

 

9n1 data is a bit uncommon, but not very special.

AVR's have implemented it in a very general way and they call it "multi processor communications mode"

It can also be interpreted as "mark" or "space" parity.

 

I'm on the route to port some AVR uart code (with MPCM) to an STM32F103C8T6 (Too slow for you).

I was a bit unpleasantly surprised. This chip does seem to be capable of toggling my bits in the right order, but it's 9n1 capability seems a bit more limiting.

That would be a possible cullprit for you if you go the ARM way.

But different vendors add different u(s)art hardware to the ARM kernel.

Altme's SAM usart seems to have manchester capability built in.

 

Oops: Your single start bit with no data does not seem a too big problem to me.

Oops: At 10Mbps it would take up 100ns of your cpu cycles if you want to do it in software.

Oops: (Missed this, your post is a big lump of text.

sdavy wrote:
I have to ack each 9N1 word with the same 2 bit ack.
Does your protocol really require an Ack for each byte send?

That is a horrible thing to do. Absolutely atrocious.

Did the designer of your protocol know the length of a nanosecond? Or was this protocol scaled up from some ancient 100 baud scheme?

Do you have to do some parity checking on each byte, or can you just trigger (something similar to) a NE555 to generate a pulse after a delay from the start bit. But relying on RC timesis not a very good thing to do.

More then 3 logic gates are about equivalent to some programmable logic nowadays I believe.

Some uC's have  built in programmable logic you may be able to use.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your project setup seems to imply to have to be compatible with some existing protocol ?

Yes, the protocol is set in stone. My constants are this protocol and that I have to drive it from a Windows XP PC. Anything in between is changeable but definitely not that protocol. 

 

There is a bit of a discrepancy in my information if the data packets are 9N1 or 8N1. It is shown as both in the spec, so in my post I listed as 9N1 so to be able to possibly handle 9 data bits.

 

Oops: Your single start bit with no data does not seem a too big problem to me.

Yes, it has since been pointed out to me that  the two bit ack will just be received as a start bit and the rest of the msg 0 bits. I was thinking a bit too literally with having to send or check for a two bit response.

 

Oops: (Missed this, your post is a big lump of text.

Yes, i typed it all out but when i posted it i lost a bunch of <CR>s. I have edited the original post and added some white space for clarity.

 

sdavy wrote:

I have to ack each 9N1 word with the same 2 bit ack.

Does your protocol really require an Ack for each byte send?

 

That is a horrible thing to do. Absolutely atrocious.

Did the designer of your protocol know the length of a nanosecond? Or was this protocol scaled up from some ancient 100 baud scheme?

Unfortunately, yes that is all correct. 2 bit ack for a 8N1 / 9N1 packet.

I would assume, like you, this is either a leftover from a previous protocol, just with the speed scaled through the roof, or there is a very good reason which is unbeknown to me as to why every byte has to ack'd.

 

Do you have to do some parity checking on each byte, or can you just trigger (something similar to) a NE555 to generate a pulse after a delay from the start bit. But relying on RC timesis not a very good thing to do.

More then 3 logic gates are about equivalent to some programmable logic nowadays I believe.

Some uC's have  built in programmable logic you may be able to use.

No parity check on the data. As mentioned the two bit ack is no longer a problem as i just transmit or receive the ack as the start bit + 1st data bit and then the rest of the bits will be inactive state bits, so a standard 8N1/9N1 message is still sent and received but is actually the same as sending 2 bits. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You might want to look at the same70 series chips. They run up to 300MHz. You’ll need to read the specs on the clocking and the usart to see how fast it can go.

Thanks Kartman.. This is exactly what im looking for. I'll dig a little further to make sure it can handle the data speeds but looks to be ok at a quick glance. Dev board readily available along with the microcontroller itself. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@sdavy wrote:

Unfortunately, yes that is all correct. 2 bit ack for a 8N1 / 9N1 packet.

 

A start bit followed by a stop bit is nothing more than a pulse whose width is one bit time, regardless of whether the start is 0 or 1.  For an ACK, transmit 0xFF (or 0x1FF) and you will get said pulse, followed by eight (or nine) "stop" bits. 

 

 

EDIT: added quotes around "stop."

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Last Edited: Fri. Mar 2, 2018 - 11:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can use the advanced part selector from Microchip to find chips that might suit your needs: http://www.microchip.com/maps/Mi...

 

I found either the SAM E series already mentioned (ARM arch.), or the PIC32MX series (MIPS arch.).