PS2 Keyboard Library

Firmware Libraries
1

Hi,

I'm currently working on a project that uses a PS2 keyboard-wedge style barcode scanner.

I should start by saying that some of the code in the library is slightly over my head.

Now that the Web IDE supports external files (yay!) it now looks easier to work on converting the library.

I'm currently having problems with variable conversion.

As AVR chips don't have a lot of RAM the library uses PROGMEM to store the keymap array.

Spark Core doesn't support this so I have begun by removing all references to this.

For example I have changed:

extern const PROGMEM PS2Keymap_t PS2Keymap_US;

to:

extern const PS2Keymap_t PS2Keymap_US;

In the header file which I think will change the PROGMEM "array" to one stored in RAM.

I changed:

const PROGMEM PS2Keymap_t PS2Keymap_US = {

to:

const PS2Keymap_t PS2Keymap_US = {

In the cpp file which I believe tells the compiler to save the array to the array created in the header and not into flash.

and lines like:

c = pgm_read_byte(keymap->altgr + s);

to:

c = keymap->altgr + s;

which is where I am running into this problem:

PS2Keyboard.cpp:336:26: error: invalid conversion from 'const uint8_t* {aka const unsigned char*}' to 'char' [-fpermissive]

As far as I can tell there is no issue with the PROGMEM conversion, but it is how the compiler understands different data types? Would I be correct in thinking this?

Would I be correct in thinking that I need to change something in:

   typedef struct {
	uint8_t noshift[PS2_KEYMAP_SIZE];
	uint8_t shift[PS2_KEYMAP_SIZE];
	uint8_t uses_altgr;
	uint8_t altgr[PS2_KEYMAP_SIZE];
} PS2Keymap_t;

so that it uses a different type the spark compiler understands or am I way off of track.

The library I am trying to convert is the Arduino PS2Keyboard Library Version 2.4 (March 2013)

Any help would be greatly appreciated.

Many thanks.

2

I think you could be running into the issue that GCC is more strict by default than the AVR compiler about constant strings. If you have function that takes char* as an argument but does not modify that string, it should be declared const char* instead.

There are two ways to fix this, one is to change your functions that DON’T modify their arguments to mark them as const and the other is use a pragma that @Kitard pointed out to make the compiler less strict:

#pragma GCC diagnostic ignored "-Wwrite-strings"

See the thread “Coming from arduino IDE” for more details.

3

FYI - a couple of others I have been using (need to go back and clean up my code so I can remove this eventually).

#pragma GCC diagnostic ignored "-Wreturn-type" 
#pragma GCC diagnostic ignored "-Wswitch"

-Wreturn-type
Warn whenever a function is defined with a return type that defaults to int. Also warn about any return statement with no return value in a function whose return type is not void (falling off the end of the function body is considered returning without a value), and about a return statement with an expression in a function whose return type is void.
For C++, a function without return type always produces a diagnostic message, even when -Wno-return-type is specified. The only exceptions are ‘main’ and functions defined in system headers.

This warning is enabled by -Wall.

-Wswitch
Warn whenever a switch statement has an index of enumerated type and lacks a case for one or more of the named codes of that enumeration. (The presence of a default label prevents this warning.) case labels outside the enumeration range also provoke warnings when this option is used (even if there is a default label). This warning is enabled by -Wall.

Txs
Chris

4

Hey @Kitard! I would also like to connect a PS/2 Keyboard to the :spark:. Which PS/2 library did you use and did you succeed in making it compatible with :spark:?

5

@Kitard @krophi Has anyone been able to successfully port over the PS/2 Keyboard library?

6

Hi,

I am working on a project that involves a similar bar code scanner (PS2). I have it and the other components hooked up properly to the spark core, but am running into problems porting the library. Have you had any success in this department yet? I would love an opportunity to pick your brain on the modifications you have made/plan on making. Please let me know - I think collaboration might be a mutually beneficial strategy.

Thanks,
Ben

7

I think this topic is now continued here

1 Like