locked
Basic concept of microcontroller and MRDS RRS feed

  • Question

  • Hi,

    Ive read many threads here asking about this same question and i hv no intention to duplicate the thread any further. But i really wish if someone could help me understand the concept of programming the microcontroller and the MRDS.

    Basically in microcontroller(18f4550), you write the code in C++ or assembly, compile the code to get the hex file and download the hex file into the microcontroller. As far as i understand (in using MRDS) after reading prev posts, first i have to establish the communication between the microcontroller and the pc, this should be no problem because the 18f4550 support usb interfacing (im working to build the hardware now). then i hv to download some firmware from the manufacturer (Microchip) in order for the pc to recognise the device. 

    So for example that if i have 2 motors connected to the microcontroller, let say port A1 and port B1, do i have to write the code, compile and download it into the microcontroller..or just simply (since the connection between the microcontroller and the pc is already established) i could just create a new service using C++ or C# specifying the function to call for that specific port A1 and Port B1 and use that service in MRDS, i dont know if that makes sense but, what im trying to say is, where do i write the function to call for that specific port? in the microC or in the service?.

    Really hope someone could help me understand this basic concept of using MRDS. Thanks!

    Thursday, April 19, 2012 7:39 PM

Answers

  • The ultimate answer is that it depends upon your microprocessor and the connected hardware.

    Case 1 - uController generates PWN signals in hardware.

    Let's say your controller has PWM outputs.  You could write your controller to expect commands from the PC to control each of the outputs.  This makes the controller simple in that it just expects to recieve a number for each PWM output and sets it into the internal counters.  Little work on the controller - just expect a number for each output.  Generalized abstraction on the PC - you have a service that knows it supports X PWM outputs.  Whether those are motors, servos, amplifiers is unknown.  This is the most general of interfaces and code.  Nothing is really known or specified in either of these two code implementations.

    Case 2 - uC only generates simple IO but hardware requires control.

    Regardless of whether the output is PWM or controlling several IO lines, your controller 'knows' that it has to 'earn it's pay'.  It has to use: A) Internal timers to generate PWM signals.  B) Sense motor outputs to control its output signals to the motor.  C) Some other specialized control/feedback mechanism. This makes the uC specialized to that hardware.  This also means that your MRS service becomes more specialized - It knows that rather than being a generalized controller, it has very specific hardware attached to it.

    Case 3 - uC only generates IO and hardware does not require control

    Think of the situation where the output is a light bulb, a simple motor.  They are either on or off.  No variable speed.  Nothing special about them.  This makes the uC simple again - get a command from the PC, put it onto the ports.  Like the first case, the connecting service on the PC can provide a basic implementation that a supporting service makes specific to the 'device'.

    Both cases are equally valid to implement.  Both cases can be built up in MRS.  This is the choice you as the hardware developer have to make:  A) Do I spend X and implement fine software control?  B) Do I spend Y and use 'generic' hardware?

    I think this is why this thread keeps poping up.  The choice is not from the MRS framework down.  The choice is from the hardware going up.  (I think a lot of people are stuck thinking from the frameword down.)  It really comes down to - What can you spend?  What are the hardware requirements?  What is my development timeline?  Do I have to make this a generic interface or is this a custom one-off situation?  ....

    For my implementation (VEX - http://vexmsrs.codeplex.com/), I chose all of the cases in one implementation  - Mostly simple PC controller.  Mostly simple uC code except for a few special sensors.  Lots of supporting generic services on the PC that implement case 1 - 'motors go onto PWM ports'.  Lots of PC services that implement case 3 - 'lights and simple sensors goes onto the IO ports'.  Finally a 'simple' PC service but a complex uC implementation for case 2 - ultrasonic sensor goes onto both interrupt ports and and IO ports.  (This is where the uC code gets messy.)

    Hope this answers your question by exposing a different point of view.

    Ed Harfmann

    Friday, April 20, 2012 12:36 PM

All replies

  • The ultimate answer is that it depends upon your microprocessor and the connected hardware.

    Case 1 - uController generates PWN signals in hardware.

    Let's say your controller has PWM outputs.  You could write your controller to expect commands from the PC to control each of the outputs.  This makes the controller simple in that it just expects to recieve a number for each PWM output and sets it into the internal counters.  Little work on the controller - just expect a number for each output.  Generalized abstraction on the PC - you have a service that knows it supports X PWM outputs.  Whether those are motors, servos, amplifiers is unknown.  This is the most general of interfaces and code.  Nothing is really known or specified in either of these two code implementations.

    Case 2 - uC only generates simple IO but hardware requires control.

    Regardless of whether the output is PWM or controlling several IO lines, your controller 'knows' that it has to 'earn it's pay'.  It has to use: A) Internal timers to generate PWM signals.  B) Sense motor outputs to control its output signals to the motor.  C) Some other specialized control/feedback mechanism. This makes the uC specialized to that hardware.  This also means that your MRS service becomes more specialized - It knows that rather than being a generalized controller, it has very specific hardware attached to it.

    Case 3 - uC only generates IO and hardware does not require control

    Think of the situation where the output is a light bulb, a simple motor.  They are either on or off.  No variable speed.  Nothing special about them.  This makes the uC simple again - get a command from the PC, put it onto the ports.  Like the first case, the connecting service on the PC can provide a basic implementation that a supporting service makes specific to the 'device'.

    Both cases are equally valid to implement.  Both cases can be built up in MRS.  This is the choice you as the hardware developer have to make:  A) Do I spend X and implement fine software control?  B) Do I spend Y and use 'generic' hardware?

    I think this is why this thread keeps poping up.  The choice is not from the MRS framework down.  The choice is from the hardware going up.  (I think a lot of people are stuck thinking from the frameword down.)  It really comes down to - What can you spend?  What are the hardware requirements?  What is my development timeline?  Do I have to make this a generic interface or is this a custom one-off situation?  ....

    For my implementation (VEX - http://vexmsrs.codeplex.com/), I chose all of the cases in one implementation  - Mostly simple PC controller.  Mostly simple uC code except for a few special sensors.  Lots of supporting generic services on the PC that implement case 1 - 'motors go onto PWM ports'.  Lots of PC services that implement case 3 - 'lights and simple sensors goes onto the IO ports'.  Finally a 'simple' PC service but a complex uC implementation for case 2 - ultrasonic sensor goes onto both interrupt ports and and IO ports.  (This is where the uC code gets messy.)

    Hope this answers your question by exposing a different point of view.

    Ed Harfmann

    Friday, April 20, 2012 12:36 PM
  • Thank you for the reply Ed,

    I think i understand a bit now, first off my timeline is only 2 months, so i don't think that would be sufficient to develop a generic interface, that is why I'm focusing to make it custom to the hardware that i have.

    And the second thing is, my case is case 2, because the uC is expected to produce PWM signals for the motors to have variable speed control. Let me explain my hardware setup in general, a joystick is connected to the PC via USB, and the PC will then send signals to the uC (USB wired connection) in which a number of ports are connected to H-Bridge circuits to drive the motors. as simple as that.

    I cannot go with Case 1 because, as how i understand it. You already have a command downloaded into the uC, let say a function called void motorA(); , that motorA function define the ports in which the motors are connected and generate the PWM. Then the service in MRDS will send a function motorA for it to work. So I will not get the speed control via the joystick.

    Rather than, if i go with case 2, where i can get all the hardware connected to the uC, and define all the ports used, generate PWM etc etc in the service of MRDS. So i can have speed control live from the PC.

    Do i understand it correctly?.

    Friday, April 20, 2012 2:09 PM
  • (Cases 1 and 3 are fundementally the same (on reflection).  The difference is basically that one is a bit and one is more than a bit.)

    Are you saying you want MRS to generate the PWM signals?  If so, I doubt it would work.  You would have to have continuous non-interrupted access the the uC and that is not going to happen.  (1st - Windows is not a real-time OS.  2nd - USB might have other traffic. ...)

    If you are saying you will have a function on the uC that sets timers and does the bit-banging itself, then I think you are ok.  (Best if the uC can just do the PWM itself, but having the software on the uC do it is a valid option.  If I read the data sheet properly, you should look at RC1/RC2 as PWM outputs.  That would GREATLY simplify your work and make the output reliable.  Just setup the registers and then you only have to update the one register with your new settings.  - Clear as mud?  ;>)

    Ed

    Friday, April 20, 2012 4:39 PM
  • I definitely not going to use MRDS to generate the PWM signal, there's no way it can do that, sorry to confused you with that..anyway, i think i hv a grip on the basic idea of MRDS and external hardware and how to implement it for my need, with your help of course. 

    Thanks Ed.

    p/s: clear as mud, well its a whole lot muddy before when i ask that question and try to answer it myself. :)..

    Thanks anyway.

    Saturday, April 21, 2012 4:13 PM
  • No problem at all.

    Ed

    Monday, April 23, 2012 12:00 PM
  • From my experience working with the Eddie platform it boils down to a timing issue.  Even over USB you are emulating a serial connection to the Propeller control board.  You send down a command, it is processed and you receive a response.  If the command is to simply apply drive power to the motors it isn't really a problem.  But if you are using wheel encoder information to determine length of travel, and you are trying to do that real-time in RDS it is.  I've seen some RTTs of 100ms or more.  So in that case, it would make sense for the local control board to read and interpret the encoder values and locally stop the motors when the command was complete, then respond to RDS.  Especially with Eddie, you have a control board that has 8 processors running 20 Mips each to divide up the hardware tasks rather than using interrupts.  IMHO the tighter the control loop, the better.

    Todd

    Thursday, May 3, 2012 4:01 PM
    Moderator