SDCC for Vex is here!

VEX V5 General Discussion Technical Discussion
21

As for patching, I did modify the install process to assume less about the base linux system (i.e. using the which command to find binaries) and was considering make and aur (arch user repo) install package for arch linux.

Ok, well at the moment my current development platform is arch linux so I’ll see if I can get the stm32loader up and running. Also while I do have C/arduino experience I’m not as familiar the PIC and Cortex controllers. If you could provide some tips or point me in the right direction to help port I’d love to help.

I’ll dig through the Vex default code to see if I can find the competition signals for the original PIC controllers. I suspect it may be the same or similar for vexnet because PIC controllers with Vexnet were at one point (idk anymore) run alongside with Cortex controllers.

22

Not sure what you are after exactly but I can tell you what I know of how the PC software achieves this using the VEX programming cable. This would be for a serial connection from PC to Joystick. I have not looked at USB connection direct to Cortex much yet, it uses similar messages to the serial communication for many things but in this area I assume it would be different.

To toggle Robot Enable/Disable or Autonomous/Driver control, the following sequence is used.

  1. Change serial baud rate to 9600.
  2. Set RTS
  3. Wait 5mS
  4. Clear RTS
  5. Wait 15mS
  6. Set RTS
  7. Wait 10mS
  8. Send serial char 0x35 to toggle enable/disable or
    Send 0x22 to toggle Autonomous/Driver control
  9. Wait 20mS
  10. Clear RTS
  11. Wait perhaps 250mS, you can get some feedback on CTS I think but its just easier to have a delay.
  12. change baud back to normal and continue communications.

This communication does not go through the programming cable to the Joystick but is intercepted by a PIC inside the programming adapter.

The PIC decodes the 0x35 (or 0x22) character and creates a pulse train on the RTS line going to the Joystick. 8 pulses, each of 3.3mS with a 50% duty cycle (that is 1.65mS low, 1.65mS high) are sent for the Enable/Disable command. 6 pulses with the same specs are sent for the Autonomous/Driver command. Pushing the button on the programming adapter sends 5 pulses.

Here’s a waveform showing RTS in (lower trace) to RTS out (upper trace) on the programming cable for the autonomous command.

https://vexforum.com/attachment.php?attachmentid=4417&stc=1&d=1311735105

I’ve no idea why it has to be this complex but can only assume it’s for some type of backwards compatibility with the older PIC 0.5.

Hope this was not confidential but engineers are curious people, we always want to know how things work :slight_smile:
TEK00000.jpg

23

Thanks for the response. I’m confused as to whether this is specific to either vexnet or the crystals however this is something that I will try to investigate.

Also is there any prepossessing on the microcontollers behalf? I ask because the vexnet adapter for the old PIC controllers goes through a serial port ultimately and I suspect might be simpler when processed that way (though idk and the same function wouldn’t work for both controllers then…)

24

It’s specific to the serial programming cable which can, I believe, be used with both the cortex and Pic. In the case of the Cortex, the serial commands are converted by the joystick controller to either USB commands or commands over vexnet and sent to the cortex cpu. I had done some investigation of the USB interface, not to difficult to use but ii made more sense to me to use the serial cable as the joystick was going to be needed anyway.

25

Ah I see.

I more or less understand the direct programming cable implementation; however, my main concern is programming cable → old big controller’s outputs the same as programming cable → joystick (vexnet).

For example:
Configuration 1:
over the old rf controllers it’d go, PC → Programming Cable → Old remote → PIC tx port → Processed

Configuration 2:
over vexnet using adapter to PIC, PC → Programming Cable → Old remote(vexnet) → vexnet adapter → serial → Processing

Configuration 3:
Cortex Controller, PC → Programming Cable → joystick → cortex vexnet adapter → Processing

I’m mainly interested in the last two steps of each configuration

26

hold on a sec. Can I download code to cortex from my mac? If so how do I do it cause i read the first post and it seemed kind of confusing and I read more posts and it just confused me more. Does this thing like compile and everything?

27

The port of open vex to cortex doesn’t seem complete but there is a description of the tool chain using easy c produced hex files at http://personalpages.tds.net/~jwbacon/vex.html

28

Theoretically you can download although I have not tried it, you still have to compile in EasyC. Even if we had a compiler for the Mac I don’t think anyone has enough information to create a runtime library to link against. Although this type of project is interesting, at the end of the day your best bet is to use the existing tools under windows, or in a virtual PC environment like Parallels.

29

Yeah, specifically if you can find a way to generate the hex files you can use stm32flash…

30

So out of curiosity I did have a look at the STM32 loader which is part of this package. No problems compiling under OSX 10.5.8 (yes, the Mac I use most is still on Leopard although I have others on 10.6 and 10.7) but it did not connect with the Cortex. After a couple of hours debugging found that there was a problem with the very first serial write so I added a retry for the initial baudrate auto-negotiate command. You have to press the button on the programming cable to put the cortex into bootloader mode also. So I can see device info and download the flash. No plans to upload an image as there’s no real upside and bricking the cortex is not an option I’m willing to chance.

The protocol for flash read/write is pretty simple and is documented well. If I were going to need this functionality I would probably rewrite with a GUI but I’m not sure there’s really any point.

31

Well idk how useful the gui would be but having a *nix based loader for cortex is def nice and would theoretically bring down operational costs.

32

I don’t disagree that for a small number of users it could be useful. I think a version with a GUI would be better for Mac users. It’s of almost no use in it’s current form for RobotC users as CMU uses a different download protocol for their applications and (as of V2.32) they do not compile to a file anyway. Any tools we can create to reduce cost is good, however, at this point being able to download an EasyC binary from *nix is just a party trick.

The issues I had last night are related to the prolific USB/serial adapter, I tried a keyspan adapter, it seems to be better.

33

Well ultimately I’d like to avoid the use of easy c or robot c by compiling using open source code.

I found this this on how other (non-vex) arm-cortex-m3 controllers are developed on.
It has a lot of information and I have yet to sit down and really read it; however, from what I skimmed it seems like the arm-cortex-m3 is pretty well supported in *nix.

p.s. So I’ve been trying to get the ultrasonic sensor to work in Open Vex (gotten everything else to work…(motor control, rc sequences, light sensor,line sensor, optical shafter encoder, limits, buttons) just not the ultrasonic sensor…any tips? (I was able to run it using Easy C but the source code seems to be a similar implementation so idk…)

34

This company also has some interesting tools.
http://www.hitex.com/index.php?id=cortex

also some documentation, good one on the STM32

http://www.hitex.com/index.php?id=download-insiders-guides

I don’t have a pic so cannot really help. There are a few comments about not calling the sonar_read function too often. If you have access to a scope then I would start by seeing if the output “ping” is being sent first.

35

I’m trying to build this on ubuntu 11.04 with the following command.


make prefix=/usr/share/sdcc/lib/pic16 install

This is giving me the following error:

gplink firmware.o crt0iz.o -w -c -s vexsdcc.lkr -m -I /usr/local/share/sdcc/lib/pic16 -I /usr/local/share/sdcc/non-free/lib/pic16 -o firmware ../Lib/OpenVex.lib libdev18f8520.lib libc18f.lib libm18f.lib libsdcc.lib libio18f8520.lib 
libdev18f8520.lib: No such file or directory
make: *** [firmware.hex] Error 1

It’s true that the libdev18f8520.lib file doesn’t exist in the director it’s looking for, which is why I supplied the prefix argument to correct that. However, it’s not working. Any thoughts?

36

also some documentation, good one on the STM32

http://www.hitex.com/index.php?id=do…nsiders-guides

CodeSourcery (Lite) seems to be a very promising cross compiler for the arm-cortex-m3 controllers with windows and *nix support.

I’ll investigate this further tomorrow.

I did read that in the sonar.c file; however, I referred to an internal delay set up in the function. That said I’ll try to add in manual pulses and read calls tomorrow :stuck_out_tongue:

37

I can’t really help here, however, from the advanced firmware directory it looks like you setup as follows.

#define SONAR_OUTPUT_PORT 9
#define SONAR_INTERRUPT_PORT 3

controller_init();

if ( sonar_init(SONAR_INTERRUPT_PORT, SONAR_OUTPUT_PORT) != OV_OK )
printf(“sonar_init() failed.\n”);

Then call at periodic intervals (18.5mS in the example)

sonar_distance = sonar_read(SONAR_INTERRUPT_PORT);

Have you tried running the code in the advanced directory?

38

I had a similar issue when setting up on arch linux. My solution was to my a symbolic link of the file in the default location because it appears that somewhere in the library there are hardcoded or just poorly written file calls. I plan on writing a patch and submitting it but in the mean time you should be able to just copy or link the files…

39

I believe the 18.5 mS is the interval that the “master” processor tells the “user” process about new rc data. It shouldn’t have to do with the sonar sensor.

In the documentation it does say to wait 14mS or else the sonar will get stuck so I’ll try that. (although to me it looks like the default code in sonar.c waits 6mS so thats either a contradiction, mistake, or something else)

I’ll try switch the echo timeout time to 16 and see what happens if I have time later tonight

40

The openvex version I was looking at is 0.5.0, it does not send the output pulse unless at least 11mS have elapsed from the last received echo. Just keep calling sonar_read, it should work.

I’m not sure who is actually working on the Cortex version of openvex but I mostly figured out the IO ports today, found a way of reading the system registers and from there not it was not to hard to figure out the digital & analog port connections, spi, uarts etc. I’m not planning to do much with this info but it would not be to hard to develop alternative firmware.