Skip to content

Frequently Asked Questions

Jump to bottom
jmesmon edited this page Feb 27, 2011 · 8 revisions

Frequently Asked Questions

Feel free to add your own question to the bottom of this list by using other questions as a model.

  1. What is “user code”?

    "User code" refers to any program-specific code that accesses hardware through HAX’s public API and can be thought as "running on top of" HAX in the same manner that an application runs on top of an operating system.

  2. What is a hardware abstraction layer?

    Implemented in software, a [[hardware abstraction layer|http://en.wikipedia.org/wiki/Hardware_abstraction_layer]] (HAL) acts as high-level interface for dealing with different underlying hardware. In particular, Hax provides a common public interface through which user-code interacts with the hardware. Each supported architecture has a custom implementation of this public interface that maps Hax function calls to the low-level commands used to carry them out on that platform. Any piece of user-code that correctly interfaces with Hax will run on all of the supported platforms.

  3. What is the minimum change in user-code required to run a pgoram on multiple architectures?

    Code that maps physical properties of the microcontroller to software will still vary between platforms. In normal use this will only be an issue when indexing sensors and motors, since the physical labels of the pins vary between microcontrollers (e.g. the Cortex microcontroller lacks a dedicated “INTERRUPT” pin breakout). For cross-platform compatability, it is advisable to alias pin numbers to meaningful names using macros or constant variables. For example, the following is a safe method of referring to interrupts on both architectures:

    #if defined(ARCH_PIC)
#define INT_ENCODER1A IX_INTERRUPT(1)
#define INT_ENCODER1B IX_INTERRUPT(2)
#define INT_ENCODER2A IX_INTERRUPT(3)
#define INT_ENCODER2B IX_INTERRUPT(4)

#elif defined(ARCH_CORTEX)
#define INT_ENCODER1A IX_DIGITAL(1)
#define INT_ENCODER1B IX_DIGITAL(2)
#define INT_ENCODER2A IX_DIGITAL(3)
#define INT_ENCODER2B IX_DIGITAL(4)

#else
#error "Unsupported architecture."
#endif

  4. Why are all pin indexes generated by IX_ macro?

    Since the PIC18 and Cortex microcontrollers have different groups of broken-out pins, there is no indexing scheme that works equally well for both platforms. For example, the Cortex has a dedicated section of "analog" ports, whereas the PIC has a dedicated "interrupt" section. Instead of having a different index for each physical grouping, each hardware architectures defines its own internal indexing scheme. Each pin is assigned a unique index of the type index_t which can be passed to any function that interacts with a hardware pin. To improve the readability of user code each of these pin groups is paired with a macro for generating an internal index from the pin’s physical markings.

  5. Why do none of the digital inputs on the VEXNet Joystick work?

    This likely means that you have a different version of firmware on the VEXNet Joystick than on the Cortex that you are using. If you upgrade both the joystick and microcontroller’s firmware to the latest version, this problem should go away.

  6. Using printf to print a 64bit number isn’t working/all of my printf’s are messed up

    On the cortex, newlib’s printf does not appear to support 64bit numbers (uint64_t or int64_t via PRIu64, PRId64, et c.). It tries to print them as 32 bit numbers and only removes a 32 bit number from the stack of arguments. This causes all numbers being printed after the 64 bit one to be incorrect.

Clone this wiki locally