If this goes outside of the scope of this forum could you refer me to another forum?
I am trying to produce code that turns one of the motors using pure assembly. I am posting here not for assembly help but because I want to understand the basic concept of how the duty cycle value maps into motor speed and direction.
Are these assumptions correct:
A 50% duty cycle will produce a nuetral position effect for the motor or no movement.
A duty cycle less then 50% will produce constant current to the motor causing it to move in one direction where greater then 50% produces the opposite direction. The speed of the motor is controlled by jhow close the duty cycle is to 0% or 100%.
I was originally under the impression that a duty cycle value put the motor at a specific position and the code would have to increament the duty cycle to create movement on the motor. This is not correct?
BTW: I have been looking at any and all source code I can find and the MCC source code is interesting. If you have recommendations for other source code examples. I have looked at EasyC and VexLabs Code already. I would really like a disassembler.
There is more than one type of PWM signal associated with robotics. One is used for power and the other is used for control. A voltage modulated between 0 and 100% duty cycle ,as you have described, is used to vary the amount of power applied to a motor.
The Vex controller outputs a 55Hz control PWM signal that varies between 1 and 2 milliseconds in width. 1ms corresponds to, for instance, full reverse of a Vex motor or full counterclockwise position of a Vex servo. 2ms corresponds to full forward of the motor or fully clockwise position of a servo. 1.5ms corresponds to a stopped motor or a centered servo.
The electronics in the motor converts the control pwm signal into an internal 0-100% Power PWM signal to drive the motor.
I actually understood the PWM theory but didnt know that the motors were current controlled by the duty cycle.
I still cant get a motor to turn IFK, I have examined the code and used knowledge from the pw1open.c(OpenPW1) file in mcc18-2.40. The behavior is interesting. I used the duty cycle source to set the one duty cycle value. The code loads the center light blinks just as default code download but the programming light is on and blinking.
And I believe if you wait long enough the bot which has motors plugged into 1,2,3 will have a short fit and then continue blinking, so I clearly have some bad code loaded into the pic.
As of writing this I realized maybe I need to to also do configuration which I saw in setpwsetoc.c file? Maybe the code is good for the pic but the vex controller itself needs a configuration setup?
As with the Vex Controller I am assuming:
VEX CLOCK 40MHZ
I use a PR2 value of 0xb3 and a 1:1 scale factor setting. I am attempting to produce a 55KHZ frequency or 18.5 ms period.
Thanks for any help I plan to continue to research this technology for at least 3 more months and then I will need to find out where its actually used.
I understand the issue now. I saw an email about how the master user link has to be updated every 18 ms or the master will hold the user in RESET. This is done with the IFI code using the getdata / putdata functions.
Is there anyway around this? I am really just interested in switching the master off and using the user with straight PIC18 assembly. I have read the IF 2004 Programming Reference Diagram and would like to understand what the user sends back to the master in order to keep the master from asserting the user to RESET.
BTW: sorry about the typo in the original email “19F8520”.
Well, I’m just guessing here. I haven’t investigated how the reset occurs. One way to do it would be for the getdata or putdata routines to reset the Watchdog timer. If that is the case, then all you have to do is pet the watchdog in your own code.
If there is a hardware connection between the master controller and the user MCLR line, then it will likely require programming the master.
Sounds like the WatchDog of the Master Controller is “kicking in”.
The only documentation from VexLabs I have found says Vex is 10MIPS, but inspection (inside the Vex Controller) of the Crystal is “J10.000”, which I interpret as 10MHz.
VexLabs only allows programming of the User Processor, not the Master Processor. I would guess Because Vex is to be used in a Competition and there is a certain amount of control that must be maintained over all the participants…
IIRC from other Threads, the “getdata or putdata routines” do “pet the watchdog”, either through a “direct” hardware link, or through a Communications Channel.
Good “embedded design” would dictate a “direct” hardware link…
Examination of the file “ifi_picdefs.h” in the Vex Starter Code from VexLabs would indicate which processor lines might be used to “pet the watchdog”.
Exactly what I was thinking. If the getdata / putdata can do this then there isnt any reason I cant do this in a timer in my pure assembly implementation.
I am guessing that the Master / User communications is done via SPI ( Serial Peripherial Interface ). I believe all that is needed to “pet the watchdog” would be to send some data to the master using SPI. The documentaiton is not specific but hints that getting the data ( getData function ) isnt what pets the WD.
The 18F8520 instruction set is simple I dont think it would be difficult to write a dissassembler for it that can provide symbols from the map file and flag symbols from the header / inc file. I downloaded a disassembler but sadley it doesnt cover the PIC18 family (PICDISLITE).
Whom might I speak to in order to obtain a copy of the master code that wouldnt require a watchdog update? This would really be better then attempting it myself?