Library porting question (PS2X_lib)

LeafLabs Garden » Support » Maple IDE Support

Library porting question (PS2X_lib)

(25 posts) (5 voices)

Started 3 years ago by
Latest reply from crenn

12 Next »

Anonymous
Unregistered
Hello all,

First of all, I want to thank the folks at Leaf Labs for putting this product together. I have been using an Arduino for a while and ran into limitations with their IDE as well as with their chip's 8bit nature, so this product was a greatly needed upgrade even if the IDE and libraries are still in their early stages.

I have only been playing around in C for a month or so on the Arduino, so pardon any overly noobish questions. I am building a device to work with a telescope and carry out various astrodynamics calculations. I got my Maple board this past Friday and I already have just about everything working (serial VFD display and GPS, I2C RTC, 3-axis accelerometer and 3-axis magnetometer). What is proving to be a thorn in my side is the library that I was using on the Arduino for interfacing a Playstation2 controller.

The library that I am trying to port is called PS2X_lib. It makes use of several functions in this format:
```
unsigned long CalledFromLoopToGetPulseCounts( void )
  {
    unsigned long c;
    {
      uint8_t SaveSREG = SREG;   // save interrupt flag
      cli();   // disable interrupts
      c = PulseCounts;  // access the shared data
      SREG = SaveSREG;   // restore the interrupt flag
    }
    return( c );
  }
```
I am not certain how to beat the code into submission to get it to work with the Maple. SREG is not defined, nor is cli(). I am under the belief that a the function nvic_globalirq_disable() is probably the best substitution, but that is just a wild guess based upon my browsing through the supplied Maple code.

If someone could show me a quick example of how this function could be rewritten, I could repeat the process for the rest of the Library that I am porting and I believe the code would then work as expected. If there is a Library porting guide or something that covers these sorts of pitfalls, I would be interested in having it pointed out. Google has failed me on this endeavor. :)

Thanks,

Jason
Posted 3 years ago #
mbolivar
LeafLabs
Unfortunately, it's not trivial to port code which makes use of low-level processor-specific features, like your snippet does.
- Based on a quick Google, it looks like SREG is the AVR status register, which looks like it carries a mix of ALU flags, bitfield flags, and the global interrupt state. I'm not aware of a close analog to it on Cortex M3, and without knowing more about PS2X_lib, it's not clear what its purpose is here. You'd need to determine exactly why they did things that way (i.e., why this protects the shared data in PulseCounts) and know the equivalent on Cortex M3 to port this correctly.
  Do you know why the SREG save/restore is happening? If so, maybe we can point you to equivalent functionality for the STM32. If you can't figure it out, you might try contacting the developers of the library. I imagine they'd be interested in a port of their library to Maple, so they might be willing to explain in detail.
- The equivalents to cli() and sei() using libmaple are respectively noInterrupts() and interrupts().
  In fact, on Wiring and Arduino, noInterrupts() and interrupts() are just macros for cli() and sei(), so doing a find/replace to get rid of cli() and sei() in favor of noInterrupts() and interrupts() would result in code that still works on Arduino. You can move on from there to try to figure out what to do with the lines mentioning SREG.
  
  Note however that cli()/sei() imply a memory barrier on AVR, while noInterrupts()/interrupts() (which get compiled down to the ARM instructions cpsid i and cpsie i) do not. Since there's some mention of accessing shared data, I would replace each cli() with the following just to be safe:
  
  noInterrupts(); asm volatile("dmb");
  
  And each sei() with:
  
  interrupts(); asm volatile("dmb");
  
  The dmb instruction is a data memory barrier that might be important depending on how PulseCounts is modified on AVR.
(edits for grammar and code typos)
Posted 3 years ago #
Anonymous
Unregistered

Thanks mbolivar for the quick response.

The snippet that I provided is just a generic example I found in other code, not from the PS2X_lib that I am porting. I chose that example because it was the simplest example. It appears to disable interrupts to access data and then re-enable interrupts. I understand the need to do this (remember, I am only a month or so into learning C, coming from Python).

The library did not use a single instance of sei(), so I am guessing that interrupts get re-enabled automatically somehow, probably once the code is finished servicing the interrupt. I think your example meant to put "interrupts()" on the second example for sei() replacement. :)

I gathered that SREG was some sort of status register, but I have not yet dug into the arduino code to understand the full contents of the register. They are obviously preserving the contents of the register prior to disabling interrupts and I believe that the interrupt disable/enable status is within this register. This would explain why there is no call to sei() since restoring SREG would effectively re-enable the interrupts. Again, speculation. :)

There very well may be no need for the saving of the SREG state, or any analogue on the Maple. I will try first of all to just comment out these snippets and replace the cli() instructions with noInterrupts() and then execute interrupts() wherever they restore SREG.

My only other question is regarding your asm volatile("dmb") instruction. I am not quite sure I understand the rationale behind it. If you have a moment to share some insight, it would be greatly appreciated.

Thanks.

Posted 3 years ago #
Anonymous
Unregistered

Well, that got rid of a whole mess of compiler errors. :)

/Applications/MapleIDE.app/Contents/Resources/Java/libraries/PS2X_lib/PS2X_lib.cpp: In member function 'byte PS2X::config_gamepad(uint8_t, uint8_t, uint8_t, uint8_t, bool, bool)':
/Applications/MapleIDE.app/Contents/Resources/Java/libraries/PS2X_lib/PS2X_lib.cpp:162: error: 'digitalPinToBitMask' was not declared in this scope
/Applications/MapleIDE.app/Contents/Resources/Java/libraries/PS2X_lib/PS2X_lib.cpp:163: error: 'digitalPinToPort' was not declared in this scope
/Applications/MapleIDE.app/Contents/Resources/Java/libraries/PS2X_lib/PS2X_lib.cpp:163: error: 'portOutputRegister' was not declared in this scope
/Applications/MapleIDE.app/Contents/Resources/Java/libraries/PS2X_lib/PS2X_lib.cpp:169: error: 'portInputRegister' was not declared in this scope

I'm stuck on these 4 errors. These might be easy to solve, or hard. I see that others have run into the digitalPinToBitMask issue with the Maple libraries, but no solutions that I have yet found online. I'll have to look at the arduino code and see if I can make something work. :)

Posted 3 years ago #
Anonymous
Unregistered

Perhaps you could try replacing the type uint8_t with uint8. Remember that the declaration should be like uint8(a) or uint8(xx) = xxx.

Posted 3 years ago #
mbolivar
LeafLabs

My only other question is regarding your asm volatile("dmb") instruction. I am not quite sure I understand the rationale behind it. If you have a moment to share some insight, it would be greatly appreciated.

I'm not sure that it's necessary. According to the AVR-libc documentation for cli(), the instruction has the effect of inserting a memory barrier in addition to disabling interrupts. You can read about memory barriers here:

http://en.wikipedia.org/wiki/Memory_barrier

Given that the code after the cli() accesses what appears to be a variable shared between the main thread and interrupt context, such a barrier might be necessary for correctness. Again, without knowing more about the code, I'm not sure.

dmb is an ARM assembly instruction which inserts a data memory barrier. I'm not too familiar with the AVR instruction set, but dmb seems like the likeliest equivalent to what cli() does (although there are some other related memory access instructions). Putting it there in addition to the call to noInterrupts() is thus just a guess about a way to simulate cli() more accurately on ARM.

Well, that got rid of a whole mess of compiler errors. :)

The remaining errors are for Arduino-specific API for getting at the underlying GPIO ports for a pin. They're likely there as optimizations because digitalWrite() and digitalRead() were considered too slow. Perhaps you can rewrite them in terms of the high-level write/read functions and see if it works OK on Maple? The extra processor speed might be enough to let you get by without thinking too hard about it.

If not, then there's an FAQ about fast pin I/O which goes into all the gory details (with many links to relevant forum threads at the bottom).

I'll have to look at the arduino code and see if I can make something work. :)

In addition to the FAQ I mentioned above, here are some starting points:

- Source for digitalPinTo*
- More on PROGMEM

(The uses of PROGMEM here are because the Arduino has such limited RAM that it's very important to put all your constants in Flash. You can do that on Maple too, but I wouldn't worry about it at first, since you've got so much more RAM to play with.)

Learning about how GPIOs work is a nice way to start getting used to dealing with peripheral registers. While the GPIOs on STM32 are a little more complicated than on AVR, the basic idea is the same. On AVR, you can read/write all the pins on a port by setting PORTx (where x is A, B, C, or D). More info and examples here:

http://www.arduino.cc/en/Reference/PortManipulation

On STM32, there are a few different registers you have to consider when dealing with pins at the port level, so libmaple provides some convenience functions. In addition to gpio_write_bit(), which is mentioned in the FAQ, there's also gpio_read_bit() and gpio_toggle_bit(), which work the same way. Check the gpio.h documentation for more details:

http://leaflabs.com/docs/libmaple/api/gpio.html#functions

On Maple, the way to get the GPIO port and bit for a pin (so you can use the gpio_xxx_bit() functions instead of digitalRead() and digitalWrite()) is to look in the pin map. See the FAQ for an example.

It may seem like a lot of information to take in at once, but it sounds like you're getting close to porting the library successfully.

Posted 3 years ago #
mbolivar
LeafLabs

/Applications/MapleIDE.app/Contents/Resources/Java/libraries/PS2X_lib/PS2X_lib.cpp

By the way, the recommended way to add the library is to put it into the "libraries" folder in your sketchbook. You have to create that folder if it doesn't exist yet. That way, you can keep it around when you upgrade Maple IDE.

Posted 3 years ago #
Anonymous
Unregistered

Thanks so much. I cannot thank you enough for putting links to all the reference material in your response. I'm sure that I'll get it figured out with this information. I will likely be tied up reading for the next week at this rate. :)

I will move the library, I put the Arduino libraries in the correct place, so I must have been tired when I did this, lol. This library porting, and the project as a whole that I am working on, are a bit over my head since my C knowledge is still rather limited. I'm still having difficulty with pointers and references, but I'm getting there. =/

Posted 3 years ago #

mbolivar
LeafLabs

Glad to help; good luck with the port!

As a parting shot, here's a code snippet for getting the GPIO port and bit for a pin when using libmaple (untested, but should work; if used from a C++ file, you need to include wirish.h):

int pinNumber = 3; // or whatever

// PIN_MAP is an array of stm32_pin_info structures, indexed by pin number.
// Each stm32_pin_info structure contains information about the GPIO port/bit for the pin.
// Here, we get a pointer to the pin info for 'pinNumber'.
stm32_pin_info *pinInfo = &PIN_MAP[pinNumber];

// Pull a pointer to the GPIO port and the GPIO bit for 'pinNumber' out of 'pinInfo':
gpio_dev *port = pinInfo->gpio_device;
uint8 bit = pinInfo->gpio_bit;

// Now you can use 'port' and 'bit' as arguments to the gpio.h routines.
// For example, if you had called pinMode(pinNumber, OUTPUT), you can
// write the value HIGH to the pin like this:
gpio_write_bit(port, bit, HIGH);

That will let you get port/bit information for a pin programmatically, instead of looking them up in the pin map documentation for a particular pin number.

Posted 3 years ago #

crenn
Moderator

Why they're bit banging SPI, I'm not sure, but you can quickly implement the PS2X controller using SPI. Looks like it's mode 1 (clock line idles high) and the adapter needs to be connected like so:

Attention to NSS
Command to MOSI
Data to MISO
Clock to SCK

I'm guessing this is where you got the library?
http://www.billporter.info/playstation-2-controller-arduino-library-v1-0/

The functions you'll need to translate to use SPI are
boolean Button(uint16_t);
unsigned int ButtonDataByte();
boolean NewButtonState();
boolean NewButtonState(unsigned int);
boolean ButtonPressed(unsigned int);
boolean ButtonReleased(unsigned int);
void read_gamepad();
void read_gamepad(boolean, byte);
byte config_gamepad(uint8_t, uint8_t, uint8_t, uint8_t);
void enableRumble();
void enablePressures();
byte Analog(byte);

But should require minimal work.

You can look at the SPI documentation here:
http://leaflabs.com/docs/spi.html

Posted 3 years ago #
Anonymous
Unregistered

Awesome! Thanks crenn. I've never messed with SPI before, but might as well use hardware instead of software for this thing. :)

BTW, in case you are curious what I am up to, I am building a Go-To device for controlling a telescope mount and will have a large database of items on an SD card. I already have the functions working that calculate current location in the sky for planets, moon, and a few major stars.

The device will have an alternate mode of operation where I can put it on a trivial mount made with two stepper motors and a gear drive so that the Maple can point a bright green laser at celestial objects, sort of like a planetarium guide, but using the actual sky. With this ability, one can also determine location on the planet with a reliable time source (such as an RTC). Even in the absence of an RTC, the device can calculate current date (but not accurate time) by finding a solution based upon the location of 2 or 3 planets.

The reason that I stepped away from Arduino is because the 8bit math was pretty lame for doing high precision calculations. Seven sig-figs makes me cry. :(

I can't wait to get this thing working and post some videos.

Posted 3 years ago #
crenn
Moderator

I'll see if I can't borrow a PS2X controller from my uni (in a project, I had to implement a SPI interface for a microblaze core in VHDL) for a weekend and see what I can do. Although I might be a little busy since I'm helping my uni do an open day by doing a student panel and talking about the uni.

The SD Card should be realitively easy now that the maple SD fat library is being worked on, something I'll be working on as well. Did you know that the Maple actually has an RTC built in? Doing maths on a low bit system isn't as bad as you'd might think, but certainly is slower. Especially, floating point. However, if you need floating point, do you really need all that accuracy? You could potentially use fixed point maths instead.

Keep us update on the project, I'm sure quite a few people would be interested in seeing it!

Posted 3 years ago #
Anonymous
Unregistered

crenn,

I saw that the chip has an RTC, but I am not certain how I'd access it. I did a little reading but came up empty handed. I would obviously need an external oscillator, but god knows how to access the RTC after the hardware bits have been taken care of.

Regarding the floating point, my skill with C is still in its infancy so trying to work around the 8bit in software was going to be a bit of a hassle. Unfortunately with most of the astrodynamics formulas, we end up using Julian dates which themselves need several significant figures. Granted, I could make it work, but I thought that I would give the Maple a try since the system is obviously an upgrade in many ways. :)

It would be really nice of you to take a shot at the PS2 controller. I would love to contribute to this community, but I feel that the code that I'd produce would be scary at best.

Posted 3 years ago #
crenn
Moderator

If I recall someone made a library for use and the crystal already on the maple. This can be seen here:
http://forums.leaflabs.com/topic.php?id=1058
And can be downloaded here:
https://github.com/bubulindo/MapleRTC

With a compiler, you don't have to worry about the implementation of floating point maths in your code, you just write your program using float variables the and compiler does the rest. Moving from an arduino to a maple is certainly an upgrade!

I got a loan of a PSX controller for the weekend so I'll see if I can't whip something up that will work for you, I can't guarantee it will work though. But at least I should be able to test it on some hardware. I'll see if I can get it working by Saturday (I have a bit on my plate the next couple of days including today) and give you some code to test.

Posted 3 years ago #
Anonymous
Unregistered

Well, the issue with double precision floats on Arduino was that they weren't double precision. :) I was running into problems with objects being calculated almost 2 arc minutes away from where they should have been, vs a few arc seconds when running my code on my macbook. :(

Right now I am trying really hard to get my controller to talk to my Arduino. I am using hardware SPI on port 2, and LSBFIRST, tried all 4 modes on the lowest three SPI speeds (i think 500KHz is max for controller). I cannot read a single byte from the controller.

I am going to try moving it back to SPI 1 and running at about 250kHZ, maybe something is up with port2.

Posted 3 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.