mkoval / hax

Hardware Abstraction for VEX is a C hardware abstraction layer for the VEX Robotics PIC18 and ARM Cortex M3 micrcontrollers. See the Wiki for a more detailed overview and for a guide to get started.

HAX

Getting Started

1. Things you need

   • Some type of POSIX-y environment, we developed this using Cygwin (on Windows), MacOSX, and Linux.
   • A build environment.
     • For 'pic', this means installing
       • >=mcc18-3.35 and the wrapper scripts (http://github.com/jmesmon/mcc18-wrapper) or
       • sdcc.
       • a bootloader communicator ("programmer")
         • rigel
         • ifi-picloader
         • roboctl
         • ifi loader
     • For 'cortex' you will need
       • compiled for arm-none-eabi (may be possible to use arm-elf)
         • binutils,
         • gcc,
         • and newlib
       • a "programmer" / chip flasher:
         • stm32loader : included in ./arch_cortex/jtag/stm32lodaer.py (no, it isn`t jtag)
         • stm32flash http://code.google.com/p/stm32flash/
         • stm32ld https://github.com/jsnyder/stm32ld

2. Look at the 'skel' directory and the (forthcoming) 'test' directory to get an idea of how the functions work, etc. Files containing code specific to a particular architecture are placed in folder prefixed by arch_ followed by the arch name (presently, 'pic' or 'cortex').

3. For everything hax defines, look at 'hax.h'.

4. To build some user code, cd to a user program directory (for example, 'skel') and type make.

Other Stuff

Included User Code

• 'comp2010' is code for both RU Vex 2010
• 'skel' shows the minimal amount of implimentation neccisarry.
• 'test' is the code we are using to test HAX

Archs

• 'arch_pic' is the IFI setup of a pair of 18F8520 processors, one of which we have easy access to.
• 'arch_cortex' is the new Vex 2.0 processor released as a beta test to college teams in 2010. Also the excuse for this entire project.

Unimplemented or Untested Features

• A generic timer/rtc API

hax's Issues

Request for more documentation/info

Could I get a copy of any documents/communications with VeX/communications with other developers that were used in the creation of hax and that are not in the hax git repository? My email is blelbach at cct dot lsu dot edu.

Absolute include path in default.h

One of the PIC vexlib headers uses an absolute system include path to picdefs.h. This may be a bandaid fix for a bigger problem in the auto dependency generation and should be modified to something akin to #include <picdefs.h> to limit the amount of changes required when changing the Hax directory structure.

Generate gh-pages with ASCIIDoc

This will get us the indelibility of HTML without manual updates.

Missing 'test' project

There is no test project as cited in README.md. This should be minimalistic, but substantially more fleshed out than skel (i.e. working telop and autonomous code). I am planning to hammer something out over the next few days that demonstrates HAX's cross-architecture compatibility.

Cortex target missing old style OI support.

Timing to decode the signal needs to be done on the stm32 (the user processor) by using a timer in input capture mode.

Cortex support for the first-generation OI

The Cortex architecture supports interaction with the first-generation RF OI's, but is unsupported by HAX.

Build system with arbitrarily-located targets

There is currently no facility for building projects that reside outside of Hax's directory structure. This is extremely limiting and unnecessarily ties Hax to each program.

Program/Use "Microcontroller" via direct USB connection

The firmware on the LPC2458 (master processor) in the "IFI Cortex Microcontroller" and the firmware on the OI ("Joystick" or some such, don't remember processor id) are upgradable via a direct usb connection and some windows software.

Additionally, I've been told ROBOTC can program the STM32103F (user processor) on the "Microcontroller" via the same direct usb link (avoiding the orange "programming cable"/usb to serial converter with control line pulser).

Enabling this in Linux/anything will mean determining the contents of the usb protocol.

Unfortunately, for programming the STM32103F, there is no way to get the commands for transfer with out (a) having ROBOTC and using a usb-snooper on windows or (b) having a usb-sniffer to sit bettween the "Joystick" and "Microcontroller" while programming via the orange cable.

'b' has the additional benefit of allowing determination of how to retrieve serial output over direct usb.

Info

• idVendor: C251h "Keil Software"
• idProduct: 1D01h

Reports as HID device.

Endpoint 81h

64 byte interrupt transfer size @ 4ms interval
2nd to last byte of packet (0x3E) is a counter which increases by 1 at
each transmission.

Missing timer API

Both the PIC18 and Cortex support hardware timers with interrupt callbacks, but there is no API in Hax for accessing timers. This forces user code to break Hax's abstraction if it wishes to use timers on either hardware.

Auto dependency generation is unimplemented for the Cortex architecture

Unlike the vex_pic architecture, there is no auto-dependency generation for the cortex architecture. This will especially be problematic when the large number of vexlib source files are added to the project.

Current Master fails to build pic. And possibly cortex.

Due to some path fixing i did recently in develop (tried to compile for the first time in a long time), this was discovered.

Suppose we really need develop functioning, then.

Downloads (Tags) sorted alphabetically, not by date

Makes it difficult to pick the most recent release. Consider a new naming system.
Possibly:
hax-vX.X.X-release_purpose

Auto dependency generation fails to depend on Hax system headers

System headers (i.e. #include <foo.h>) are not added to the dependency files generated by GCC. This forces a make rebuild for all programs if any of the system headers are modified (e.g. hax.h, stdint.h...).

This behavior is a result of passing gcc the -MM flag when generating the dependency files, but there are numerous preprocessor errors if the flag is changed to -M.

Random arch-* branches.

What are these for?

SDCC PIC Support

To avoid using Wine and nasty wrapper scripts, the PIC code should be modified so it is SDCC compatible. This would move all of the build tools to native *nix programs and greatly reduce the chance of running into obscure errors.

Two-Wire Motor Support

There is no support for two-wire motors on the Cortex.

USART IO over direct USB

Using the USART output code doesn't work for over direct USB (I've tried catting the serial port on Windows, and looking at the output window in EasyC). I might be doing something wrong (please tell me if I am) - I'm using usart_puts.

It'd be really awesome if we had a way to communicate with our laptops/desktops. I'm not sure if this is possible, and I can't find anything on the wiki with more info about this.

tl;dr - Can I send/receive data to my laptop from the Cortex using only a direct USB connection? If so, how can we do this? This would be very awesome.

License clarification

Can someone comment on the licensing of this software, in particular, the licensing of the included firmware library (which is, I believe, from the hardware manufacturer)?

Excessive typedefs in hax.h

There are a large number of redundant typedefs in hax.h that make it extremely difficult to use. Most of these can be replaced with raw types or merged to reduce the total number of custom types.

No Cortex Support

1 week left guys.

Cortex Digital Output Support

There is no support for digital outputs with the vex_cortex architecture.

Cross-Platform Pin Indexing

Before supporting two-wire motors, we need to standardize cross-platform pin indexing. My suggestion is to always mimic the hardware's physical numbering, with exception of the PIC's dedicated interrupt pins. Those pins should be treated as as extra digital inputs. Thoughts?