Before I present some concept on how to sort those buttons I'd like to comment on your "I'm not a designer or any creative person at all. I normally just write code..." excuse. Off-topic, thus in a box.
Think about your software this way - you want people to use it, correct? Then you should make the UI appealing as you don't want to hear the comments "the software works good but the UI is horrible" or even "I couldn't get myself through the unfriendly UI so I don't know if the software is useful". Some people might have the patience to discover your mindflow (expressed in the proposed UI), some not. Trust me, I've been there, I've done that and I'm never coming back. And this site is a great place to gain some insight in designing user-friendly apps.
Now coming back to your original question. As I mentioned in the comment, you can group the buttons. In the first page I see two groups: Requests and Connection. There is also a general Cancel all tasks button that, I assume, cancels all request tasks. Use the DRY (don't repeat yourself) rule and add some dependency in buttons enabled status to present something like this:
download bmml source – Wireframes created with Balsamiq Mockups
Now, the status info shows whether the device is connected or not and the button (one instead of two) changes its function between Connect and Disconnect depending on the status.
All the buttons that don't have a functionality at the moment should be disabled (greyed out), i.e. if the device is disconnected, it is not possible to request the Names, Margins etc. (if I assume your device's logic correctly). The same applies to Cancel all tasks - if there isn't any task pending, the button should be disabled.
This gives the user additional feedback on the software status. You may ask "why is there a general device status reported in the very beginning?" - I find this status crucial for the working of the software and that is why it has to be reported in the very beginning.
And now for the second page, again the buttons that are contradicting each other, like Life test and Stop life test can be combined into one that changes its label depending on the state of the device. The rest can be grouped logically, for example like this:
download bmml source
This time I've abstained from DRY rule a bit for a reason - for settings dropping "settings" word on each button would make them somewhat unambiguous - Set to new user or Reset to user can be misleading.
Perhaps an idea for repeating buttons (request protocol 1 and 2) - if there will be more protocols in the future, why don't you use a combo box (drop-down) to select which protocol to request?
Also the buttons that make irreversible changes (like deleting all protocols) should be named explicitly so the user knows what they are doing.
I hope that not only you can move on with your project but also you get the idea on how to approach the visible part of the development in general.