simple example code request

[rootrunner]

Hello,

short version : do you have or can you make me a single cpp file that just lights one rgb led on a pacled 64 - all hardcoded? It doesn't need to be failsafe. just one led wil do. i know that it must seem a dumb question because all the source is here but always find it difficult to grasp someone's code and having a small example would be a big help for my pet project.

long version : I've written a daemon and a client program to drive an arcade cab control panel. It parses an xml file and dynamically generates what's needed to light everything up based on the input it receives. It basically does what LedBlinky on windows does but it's not as advanced yet. It wil never have a gui - I'm not into gui's. It supports multiple boards (needs testing), up to 4 players ( actually more but there are no games with more than 4 players I think and I've never seen a control panel with more than 4 joysticks), there's no real limit on the number of colors, buttons and emulators one can configure. Everything that exists at this time on the net with regards to specific rom support is integrated. eg if I tell it I want sf3 with FBAlpha it'll generate the correct color info as they were on the original cab. The xml parsing works perfectly. It generates everything that's needed very fast. Now I'm at the point where the code generated a basic json file that i can feed to your umtool.out but obviously that's not the way to go. I need real integration and as such a simplistic cpp program would be great as a learning point hence my question. I could get away with generating json files but I want to (try to) add lwax support in the end (if I get permission from the LedBlinky author) and for that json files won't cut it. Please consider my question.

Thank you for creating the driver - it gave a new dimension to my arcade hobby :)

kind regards.

[OzFalcon]

Have you had a look at the Pac Drive source code by Travis? http://www.zumbrovalley.net/readpost.php?artid=33 It's small.

[rootrunner]

No, I didn't know that program. I've downloaded it and I'll look into it. thank you.

[rootrunner]

Hi,

I ended up using your code as a base and I've just compiled some code that randomly lights the leds on my pacled64 as it's the only board I have.

just wondering : how do I interpret

define PACLED_FADE_BASE 64

define PACLED_FADE_ALL_BASE 4

----- Original Message -----

From: "Michael.S.G" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Friday, August 21, 2015 2:45:54 PM Subject: Re: [Ultimarc-linux] simple example code request (#9)

Have you had a look at the Pac Drive source code by Travis? http://www.zumbrovalley.net/readpost.php?artid=33 It's small.

— Reply to this email directly or view it on GitHub .

[katie-snow]

PACLED_FADE_BASE is for the "fade" object in the json object and how much the number needs to be adjusted before converting it to hex. The PACLED_FADE_ALL_BASE is for the "LED fade all" object which changes all the LEDs to a set fade value.

[katie-snow]

This issue should be fixing the .lib generation in the make system. Then you could use the library and the json-c library to create a json object in the code that you could send into the library.

[rootrunner]

I have another question : I've got some odd behavior. It was also in my code from yesterday but I didn't notice. This morning I cleaned up that is to say I completely took the open en close usb routines from your common.c and then used them as you do in pacled.c I did change char map[PACLED_DATA_SIZE] = {0,0}; to an unsigned char because the compiler gave an error (also in yesterdays code). I ran my new code - all leds off - oops? rebooted the board - it goes in to it's startup loop - ran my old code -> no random leds and it worked yesterday - oops again then I realized that I first ran the umtool.out as a test ran umtool.out -> leds ok ran my old code -> random leds ok ran new code -> random leds ok and it continues to function

so, after board startup I need to run umtool.out once and from that point on my 2 test programs function and continue to do so...

I don't see what I'm missing... do you have an idea?

rgds

Gijs

----- Original Message -----

From: "Katie" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Saturday, August 22, 2015 11:59:03 PM Subject: Re: [Ultimarc-linux] simple example code request (#9)

This issue should be fixing the .lib generation in the make system. Then you could use the library and the json-c library to create a json object in the code that you could send into the library.

— Reply to this email directly or view it on GitHub .

[katie-snow]

First question is, does the LED randomness change when you run your programs after the umtool.out?

My actions I would take is making sure your programs are actually writing to the board. The command dmesg could give you some insight. If it showing errors after you run your program then you are not successful programming. Also I would get the result of the write to the USB results and print that out. Anything other than the number of bytes written means there is an error. Lastly if you are writing would be to hook up wireshark and see what you are writing out. Compare it with umtool, you will have to add print statements to umtool to do the comparison.

[rootrunner]

yes the randomness changes but I suspect it's hw related. I looked into it a bit further and the umtool.out exhibits the same behavior. I don't know my boards firmware as of writing as I don't know how to check it from linux. the libusb_control_transfer call effectively returns the number of bytes written as I had a check for that in the first program to detect a successful write

this happens with both testprograms and also with umtool.out

power board - demo sequence send randomness /random leds/ map[0] = 0x000089; map[1] = 0x000000; or by json (created that one myself) { "version": 1, "product": "1401", "board id" : 1, "LED states random" : true } all leds dead send all lights up /* all on */ map[0] = 0x000080; map[1] = 0x0000FF; or by json (the one supplied) { "version": 1, "product": "1401", "board id" : 1, "LED fade all" : 4, "LED intensity all" : 255 } all lights are on

and from that moment I can program a mixture of randomness and all on's and mix the three programs all I want and it continues to function. Can you reproduce the same behavior on you pacled board(s)?

Gijs

----- Original Message -----

From: "Katie" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Monday, August 24, 2015 3:52:38 AM Subject: Re: [Ultimarc-linux] simple example code request (#9)

First question is, does the LED randomness change when you run your programs after the umtool.out?

My actions I would take is making sure your programs are actually writing to the board. The command dmesg could give you some insight. If it showing errors after you run your program then you are not successful programming. Also I would get the result of the write to the USB results and print that out. Anything other than the number of bytes written means there is an error. Lastly if you are writing would be to hook up wireshark and see what you are writing out. Compare it with umtool, you will have to add print statements to umtool to do the comparison.

— Reply to this email directly or view it on GitHub .

[rootrunner]

I just merged the usblib (pacled only - still a lot to do...) code in my daemon and adapted it's config to mach my arcade cab and everything works as expected. Awakenings YES! :) can't beat the feeling... but - the reason I post this is for the randomness issue - it effectively happens only if you write randomness after board startup - everything else works. small issue thus.

----- Original Message -----

From: dwg@telenet.be To: "katie-snow/Ultimarc-linux" reply@reply.github.com Cc: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Sent: Monday, August 24, 2015 11:20:10 AM Subject: Re: [Ultimarc-linux] simple example code request (#9)

yes the randomness changes but I suspect it's hw related. I looked into it a bit further and the umtool.out exhibits the same behavior. I don't know my boards firmware as of writing as I don't know how to check it from linux. the libusb_control_transfer call effectively returns the number of bytes written as I had a check for that in the first program to detect a successful write

this happens with both testprograms and also with umtool.out

power board - demo sequence send randomness /random leds/ map[0] = 0x000089; map[1] = 0x000000; or by json (created that one myself) { "version": 1, "product": "1401", "board id" : 1, "LED states random" : true } all leds dead send all lights up /* all on */ map[0] = 0x000080; map[1] = 0x0000FF; or by json (the one supplied) { "version": 1, "product": "1401", "board id" : 1, "LED fade all" : 4, "LED intensity all" : 255 } all lights are on

and from that moment I can program a mixture of randomness and all on's and mix the three programs all I want and it continues to function. Can you reproduce the same behavior on you pacled board(s)?

Gijs

----- Original Message -----

From: "Katie" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Monday, August 24, 2015 3:52:38 AM Subject: Re: [Ultimarc-linux] simple example code request (#9)

First question is, does the LED randomness change when you run your programs after the umtool.out?

My actions I would take is making sure your programs are actually writing to the board. The command dmesg could give you some insight. If it showing errors after you run your program then you are not successful programming. Also I would get the result of the write to the USB results and print that out. Anything other than the number of bytes written means there is an error. Lastly if you are writing would be to hook up wireshark and see what you are writing out. Compare it with umtool, you will have to add print statements to umtool to do the comparison.

— Reply to this email directly or view it on GitHub .

[katie-snow]

I have fixed the library .pc file so that it is populated correctly and installed correctly in /usr/local/lib/pkgconfig. Allowing other programs to reference this library. Still need to look into the randomess portion of this issue.

[rootrunner]

It's firmware related I think (99.99% sure actually) and it's not really an issue for me so it's ok. In the mean time my pet project is in 0.1 stage - I host it at http://users.telenet.be/rgbcommander/

----- Original Message -----

From: "Katie" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Saturday, October 17, 2015 7:52:27 AM Subject: Re: [Ultimarc-linux] simple example code request (#9)

I have fixed the library .pc file so that it is populated correctly and installed correctly in /usr/local/lib/pkgconfig. Allowing other programs to reference this library. Still need to look into the randomess portion of this issue.

— Reply to this email directly or view it on GitHub .

[OzFalcon]

Rootrunner, Have you considered including Mame output to drive other leds in your daemon? Mame outputs the state to /tmp/sdlmame_out If the file doesn't exist, no output is available to read (Obviously). If the file exists as a normal empty file then it acts as a log file (Good for debugging). If the file exists as a fifo file then it acts as a current state file (Good for normal operation).

To use the output you need to first create the fifo file. mkfifo /tmp/sdlmame_out

To use the output as a log, you would make a normal file. touch /tmp/sdlmame_out

[rootrunner]

no I haven't but I'll have a look at it. Thank you for the suggestion.

rgds

----- Original Message -----

From: "Michael.S.G" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Wednesday, October 21, 2015 12:36:11 PM Subject: Re: [Ultimarc-linux] simple example code request (#9)

Rootrunner, Have you considered including Mame output to drive other leds in your daemon? Mame outputs the state to /tmp/sdlmame_out If the file doesn't exist, no output is available to read (Obviously). If the file exists as a normal empty file (eg touch /tmp/sdlmame_out) then it acts as a log file (Good for debugging). If the file exists as a fifo file (eg mkfifo /tmp/sdlmame_out) then it acts as a current state file (Good for normal operation).

To use the output you need to first create the fifo file. mkfifo /tmp/sdlmame_out

To use the output as a log, you would make a normal file. touch /tmp/sdlmame_out

— Reply to this email directly or view it on GitHub .

[rootrunner]

Hi, I looked at it and I had my doubts at first but thinking about it you just gave me some very, very nice ideas... thx

----- Original Message -----

From: "Michael.S.G" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Wednesday, October 21, 2015 12:36:11 PM Subject: Re: [Ultimarc-linux] simple example code request (#9)

Rootrunner, Have you considered including Mame output to drive other leds in your daemon? Mame outputs the state to /tmp/sdlmame_out If the file doesn't exist, no output is available to read (Obviously). If the file exists as a normal empty file (eg touch /tmp/sdlmame_out) then it acts as a log file (Good for debugging). If the file exists as a fifo file (eg mkfifo /tmp/sdlmame_out) then it acts as a current state file (Good for normal operation).

To use the output you need to first create the fifo file. mkfifo /tmp/sdlmame_out

To use the output as a log, you would make a normal file. touch /tmp/sdlmame_out

— Reply to this email directly or view it on GitHub .

[OzFalcon]

Here is a start plus you might find some code that's useful (It's all open source) http://www.aussiearcade.com.au/showthread.php/62760-ZSystem-Dedicated-Arch-Linux-Mame-Cabinet-Index-Introduction

And a very rough section on Mame output interfacing. http://www.aussiearcade.com.au/showthread.php/63142-ZSystem-ZHooker-Wrapper-Bridge-scripts-to-link-Mame-output-to-PacDrive

[rootrunner]

I've got a question that related - In your expierience, is opening and closing a handle using libusb a costly operation? I'll clarify : the way I do it right now is that I open the handle, do what I want to do on the whole board and close the handle. Abstraction wise it would be good to view an rgb button as an entity but following that logic I would like to embed the opening and closing handle in that class but ofcourse that would multiply the handle logic times the number of buttons per board. I think you now where I'm getting at. What would be your approach?

----- Original Message -----

From: "Michael.S.G" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Friday, October 23, 2015 12:13:11 AM Subject: Re: [Ultimarc-linux] simple example code request (#9)

Here is a start plus you might find some code that's useful (It's all open source) http://www.aussiearcade.com.au/showthread.php/62760-ZSystem-Dedicated-Arch-Linux-Mame-Cabinet-Index-Introduction

And a very rough section on Mame output interfacing. http://www.aussiearcade.com.au/showthread.php/63142-ZSystem-ZHooker-Wrapper-Bridge-scripts-to-link-Mame-output-to-PacDrive

— Reply to this email directly or view it on GitHub .

[OzFalcon]

Rootrunner, I'm no expert on using libusb (Katie would be more knowledgeable) but this is the way I'd approach. Q: Is the cost of opening/closing greater than the required speed your switching. A: Probably not unless your trying to a create pwm signal. But you could code both ways and run an iteration speed test on both methods. Note: If you do leave the handle open then it's also probably worth checking if the usb device is still present before each write.

[katie-snow]

OzFalcon has stated what I would have said. I don't know the exact costs but I think the approach is more important. I will add to the note OzFalcon left in that checking for the device should be done either case, open for the whole board operation or each rgb button. Depending on the checking approach you use that could be the bigger cost.

In my learning of libusb which isn't complete. There was a way to see the list of usb attached devices and then you could pick yours from the list and that seemed very costly to me, in checking because I had to wait for the system to return to my program. That is why I picked the approach I did.

[rootrunner]

Hi Katie,

I followed OzFalcon's advice on the mamefifo and it works fine. Thanks for the very cool tip! Yet I have an issue I don't understand. I basically created classes containing boards, buttons and animations containing vectors of stuff. The code is fully object oriented now paving the way for some cool effects. I've got insert coin/start buttons blinking and the like... BUT, I have a memory leak when opening and closing libusb handles. I'm 99% sure it's libusb related because when the daemon starts and it sees no supported hw it creates a dummy/virtual device and the code follows the same flow except for the writing and the problem doesn't exist under those circumstances. It's very clear if I start for example Galaga and insert a coin because that game blinks the start button rapidly. There are 2 routines in my code that I took from yours with almost no modification being the opening and closing routines. So logically you could have the same issue. Do you have any idea? Things to close... whatever else... I just don't see where it goes wrong...

grtz

----- Original Message -----

From: "Katie" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Saturday, October 24, 2015 5:56:05 PM Subject: Re: [Ultimarc-linux] simple example code request (#9)

OzFalcon has stated what I would have said. I don't know the exact costs but I think the approach is more important. I will add to the note OzFalcon left in that checking for the device should be done either case, open for the whole board operation or each rgb button. Depending on the checking approach you use that could be the bigger cost.

In my learning of libusb which isn't complete. There was a way to see the list of usb attached devices and then you could pick yours from the list and that seemed very costly to me, in checking because I had to wait for the system to return to my program. That is why I picked the approach I did.

— Reply to this email directly or view it on GitHub .

[katie-snow]

I would recommend looking at using valgrind to determine where the memory leak is at. I followed what the quick start said to do and it doesn't appear that I have memory leaks. My confidence level in running valgrind is low, since I use it very rarely.

Good luck.

[rootrunner]

I managed to work around it and I've mitigated the problem. There's still a small leak... I'll let it rest for a while now. Valgrind = RocketScience :) The new daemon is online http://users.telenet.be/rgbcommander/

greets

----- Original Message -----

From: "Katie" notifications@github.com To: "katie-snow/Ultimarc-linux" Ultimarc-linux@noreply.github.com Cc: "rootrunner" dwg@telenet.be Sent: Saturday, December 26, 2015 4:54:59 AM Subject: Re: [Ultimarc-linux] simple example code request (#9)

I would recommend looking at using valgrind to determine where the memory leak is at. I followed what the quick start said to do and it doesn't appear that I have memory leaks. My confidence level in running valgrind is low, since I use it very rarely.

Good luck.

— Reply to this email directly or view it on GitHub .