Producer-Consumer with PIC

[tonyyy]

Hi.

I need to create a board where the MCU will be responsible of handling data coming from different source (i.e. rs232, rs485, standard I/O pins). The MCU (18F) has to assemble the data into a tcp and send it to a remote tcp server.

I am an electronic engineer but I've never worked on such problem. I have several doubts on how best approach the problem, I hope you can give me a good suggestion, not a solution, it is even enough a small description/hit from which I can start learning. Following how I would create my board.

Two MCU and a shared memory. A sort of producer-consumer problem where the first PIC handles the data from the I/O sources (data are just small values like temperature, pression...) and writes it to a shared memory. At time the second PIC reads the memory location searching for new data to transmit, if any an tcp segment is created and sent to a remote tcp server.

Is it correct or do I need to implement the board using an OS and use just one MCU?
Or maybe it's just enough one MCU and I am trying to complicate my life...

All suggestions are welcome and appreciated.

 

[FoxyRick]

You could most likely do it with just one PIC, provided that the data rate isn't too high.

It might help to have a look at a project produced by Everyday Practical Electronics magazine. the 'Web server in a box'. It used just a 28-pin dsPIC and an ethernet controller chip. Really simple hardware and the code is written in C so easy to learn from. The TCP stack was Microchip's freely available if I recall correctly. It had some ADC channels available, a serial interface and temperature logger I think, all fed to a web page but the code could be changed to simply send a data packet.

If that sounds useful, it was in three issues starting December 2011.

 

[ysba]

I think you are complicating your life. You can do it all with only one MCU. The secret is to make a good use of your main loop in the firmware. All proccesses must be divided in a way that they never get stuck waiting for something.

 

[tonyyy]

I think you are complicating your life. You can do it all with only one MCU. The secret is to make a good use of your main loop in the firmware. All proccesses must be divided in a way that they never get stuck waiting for something.

Hi.
Thanks for your reply.

A FSM model approach maybe useful?

 

[ysba]

Yes, it is. Each process in your app should a function call in your main loop; each function, a FSM. And don't forget that interrupts are just for short 'interrupts'. Sounds funny, but a lot of people use interrupts to process lots of things inside the ISR. If something need to use a interrupt, let it happen, set a flag, go out the ISR and treat this flag at the corresponding FSM. This is the way I work and in general, I can do wherever I want with a single MCU. Off course, once you start to add parallel processes, depending on the application, you'll need a higher clock MCU. Hope I've helped.

 

[arbj2]

you could implement a state machine for various functions, thus eliminating delay loops.

I think your idea could be easily implemented using a suitable 18F series PIC. The important thing with a TCP/IP stack is that this will require a lot of RAM compared to the RS 232 or RS 485.

What development tool are you using, only Microchip has a TCP/IP stack (made using their C compiler), CCS does not have a TCP/IP stack. Either you would have to re-engineer Microchip's stack or develop your own.

Also what protocols in the TCP/IP stack would you be using. Some basic protocols like ARP,ICMP (Ping only) would be essential. Others like TCP, UDP, SMTP,FTP, HTTP etc. would depend on our requirements. For your application I think an HTTP client could be a likely choice.

Making a TCP/IP stack from scratch could be difficult as you also have to cater to different scenarios like static IP, DHCP, IPv6 adressing etc. So using Microchip's TCP/IP stack could be helpful.

Alternatively you could use a raspberry computer to do all these jobs. But then you wouldn't be creating your own hardware but just the software for your application.

thanks
a

 

[tonyyy]

you could implement a state machine for various functions, thus eliminating delay loops.

I think your idea could be easily implemented using a suitable 18F series PIC. The important thing with a TCP/IP stack is that this will require a lot of RAM compared to the RS 232 or RS 485.

What development tool are you using, only Microchip has a TCP/IP stack (made using their C compiler), CCS does not have a TCP/IP stack. Either you would have to re-engineer Microchip's stack or develop your own.

Also what protocols in the TCP/IP stack would you be using. Some basic protocols like ARP,ICMP (Ping only) would be essential. Others like TCP, UDP, SMTP,FTP, HTTP etc. would depend on our requirements. For your application I think an HTTP client could be a likely choice.

Making a TCP/IP stack from scratch could be difficult as you also have to cater to different scenarios like static IP, DHCP, IPv6 adressing etc. So using Microchip's TCP/IP stack could be helpful.

Alternatively you could use a raspberry computer to do all these jobs. But then you wouldn't be creating your own hardware but just the software for your application.

thanks
a

Hi. Thanks.
I would like to use MikroC and their library. I don't have to use the board as server but only as UDP client. I have to gather data via rs485 and send via udp to a remote upd server. No need to resolve domanin name, will always specify an IP, which is static. So the main doubt here is how to approach to the problem of best exchanging data among inputs (rs485, I/O PIC pins, rs232...) and outputs (ethernet frames). For instance I am not considering unsolicited data, but the 18F at regular interval will run a routine for polling remote information. I guess that when important data has to be sent the 18F will receive an interrupt...(so how to handle a situation when the pic is "packing" the frame).

 

[123jack]

tony - first dont use polling.
Polling is only useful if you can guarantee that peripherals can wait to be serviced.
Generally that means you dont care if any or all data is lost during one or more polling cycles.
While you can design that way polling systems are a real pain if anything gets out of sync
You dont want to "guess" that an interrupt will intervene in a polling system. That would be a nighmare.
Your application very much needs to be interrupt driven (unless I have missunderstood something)

In an interrupt system such as you describe it is important to start with systems analysis of the problem.
I'd advise you begin by making a list of each peripheral and calculating the maximum frequency each of them
might possibly need servicing.
Then work out the worst case assuming all are doing so simulatneously. Then add a suitable safety factor (10% maybe depending on situations)
Then add in the amount of data that needs to be transfered within what time period to do this.
This lets you know the input rate (so far just an approximation that helps)
Next take a look at your output channel and see if it can service the input rate.

Now you have an idea of your throughput needs you can start to look for a suitable processor to
deal with it - remembering that you you need to add in latency and processing delays etc.

You might find that a pic 18F can do it but you might also find better solutions.
Dont forget you can also use different priorities of interrupts and maybe buffer the input.

 

[arbj2]

Polling is only useful if you can guarantee that peripherals can wait to be serviced.
Generally that means you dont care if any or all data is lost during one or more polling cycles.
While you can design that way polling systems are a real pain if anything gets out of sync
You dont want to "guess" that an interrupt will intervene in a polling system. That would be a nighmare.
Your application very much needs to be interrupt driven (unless I have missunderstood something)

I agree polling is wasteful you need to use an interrupt based system. The PIC microcontroller can generate interrupts for various events like USART data reception, I2C interrupts etc. You can make use of these interrupts and create UDP packets on the fly.

I think for address resolution you still need to implement some protocols like ARP, ICMP etc. these can also be used to diagnose network problems.