profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Pecacheu/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

Pecacheu/dualshock 25

Node.js module for DualShock (3 and 4) controllers.

Pecacheu/create2 12

Node.js API for Roomba 600 Series & iRobot Create 2

Pecacheu/ArduMIDI 5

A Better Arduino MIDI Library

Pecacheu/Elevators-v2 5

Adds Working Elevators to Minecraft!

Pecacheu/Arduino-Theme-Negative 2

A Customized Arduino IDE Skin Called Negative

Pecacheu/Hex-Burn-ArduinoISP 2

Burn firmware to an Arduino using another one as an ISP

Pecacheu/node-hid 2

Access USB HID devices through Node.JS

Pecacheu/Ultrawide-Video 2

Video Cropping/Stretching for UltraWide Monitors

Pecacheu/LaunchPad-MC 1

Novation LaunchPad + Minecraft = Awesome!

Pecacheu/SumoBot-v3 1

SumoBot 3.0, for both servos and steppers.

issue commentcrankyoldgit/IRremoteESP8266

Suggestion for Lower Memory Usage

Yeah, I got most of that, but for it work in normal C++ (unit tests) requires a lot more effort on top of that too. Plus it needs to be a all or nothing approach.

Oh yeah lol, I wouldn't have thought of that.

In other news hopefully I can continue to test this library at all cause I think my not-even-that-old air con is angry at me for experimenting with it, and doesn't want to work with any remote controls anymore some days XD

That and I need better IR LEDs cause the ones I have are super-weak. Might try those Adafruit "high power" ones, but damn are they expensive (as far as LEDs go).

Pecacheu

comment created time in a month

issue commentcrankyoldgit/IRremoteESP8266

Suggestion for Lower Memory Usage

I can see a "Parse a spec and implement it" method for the simple protocols. i.e. send X many bits in a certain way. But for the complexities of the A/C protocols, I can't see it being implemented without a Turing complete language of sorts. Bags not implementing that on an ESP chip. ;-)

Lol yeah, that's what I was worried about, pretty much would have to 're-invent the wheel' so to speak to implement that for the complex protocols.

FWIW, I've been looking into the entire mess that is F(), PSTR(), __FlashStringHelper, PROGMEM, etal. It's complicated, but it looks like an entire re-write of how we do strings & constants would be required to store things in flash, rather than SRAM.

Well I can show you what I learned from using them in my ESP programs, I don't know everything about them but here's how I've been using them:

PSTR() is a macro to put a string in PROGMEM in-line. Access time to PROGMEM strings seems to be just slightly higher since they have to get moved to RAM to actually use them, but they don't take up any RAM space except while they're in use.

Some functions, like printf, have a special version you must call to use PROGMEM. Not using this function will give you no error at compile time, but at runtime it'll cause a crash. Serial.printf_P(PSTR("Hello %s\n"), name);

That's why they created FlashStringHelper. That way, you can be sure that a string IS or IS NOT stored in Flash and call the right version of a function. That's also where F() comes in. It's basically a combo-macro that stores a string in Flash using PSTR(), then pulls it out from the Flash as a FlashStringHelper.

Using it directly: Serial.println(F("Hello World")); Storing in a global: FlashString str = F("Hello World"); (I used typedef const __FlashStringHelper FlashString; elsewhere to make things more readable for my sake)

Also, if you need to pull a FlashString into RAM to manipulate it directly (instead of just printing with print or printf), use the strcpy_P function. That was one part that took me a while to figure out, until I realized that all these 'P' functions exist for stuff like this.

Pecacheu

comment created time in a month

push eventPecacheu/C-Utils

Ray

commit sha 311c16b5c1a78a9801ef29554a4f224d509ef568

v2.3.2 - Fixed deinit bug with copied instance of NetAddr by using explicit copy constructor. - Made vars const where possible - Use g++ by default

view details

push time in 2 months

push eventPecacheu/LightningHTTP

Ray

commit sha 1bd358401697d2ff8f0e8f1de9bbaf8f74cb45b2

v3.6.2 - Fixed potential SEGFAULT with httpOpenRequest - Use g++ by default

view details

push time in 2 months

push eventPecacheu/LightningHTTP

Ray

commit sha 6d2c7885dc4fb69b0d015d2fde77a047229f69ff

v3.6.1 - Fixed MIME type names

view details

push time in 2 months

push eventPecacheu/Utils.js

Ray

commit sha fe22bd70670c2ac8b6a569b86ffceed57ee209a5

v8.4.6 - Multiple sub-levels in utils.copy - Improved documentation

view details

push time in 2 months

push eventPecacheu/NovaLabs-Instructor-Form

Ray

commit sha 2d8632657b18519ec3385242f24e5736282d1aeb

v3.1.2 - Fix bug with member level length

view details

push time in 2 months

push eventPecacheu/Utils.js

Ray

commit sha 1bf378627ff5bd417b08bc4be7efd0f9d584fb13

v8.4.5 - Removed utils.updateSize() in favor of getters. - Https URLs, yo.

view details

push time in 2 months

push eventPecacheu/Utils.js

Ray

commit sha a0a5893053bf1fd99be7a56abb9164bce6b1ba03

v8.4.4 - Improved loadAjax - Added utils.VER to get version. - Actually used correct version of "its" (shut up aight, you know you've done it too)

view details

push time in 2 months

issue commentcrankyoldgit/IRremoteESP8266

Suggestion for Lower Memory Usage

Like I said earlier, are you including the symbol table (i.e. a non-stripped binary) when you're running GDB? That might be your issue. I spent a fare few hours yesterday going over ways to reduce memory usage, espectially SRAM etc on the arduino platform/framework. We do most/all of what they suggest. A lot of the guides seem to indicate the compiler's RAM estimates are accurate, given that is typically the block/section of the binary that is loaded directly into memory for "global" / SRAM memory at the start of execution. Thus, it makes sense that value is accurate.

I guess it's possible that the act of including GDB affects the program. Though what I meant by the RAM estimate not being accurate is, I've noticed that in many programs the readout of the RAM usage at runtime, even right at the start of the program, can be much higher than the estimate. I don't think the compiler can really predict various dynamic allocations that go on during initializations of classes and libraries, etc.

Well, it is one of the better public style guides out there. None are perfect. Better to have a style guide than no style guide IMHO. Perhaps you've better. I'm not sure you can blame Stadia on the style guide. ;-)

Heh, I suppose that's true. But hey I just like making fun of Statia lol

I am curious about the fragmentation issues you are referring to. There is very little dynamic memory usage in the library. The only fragmentation issues we've ever had reported are with the toString() functions.

That's what I think is happening cause I'm using some of the debug functions of the library related to the IRRecv, and I've noticed that if I go crazy pressing buttons on my remote for 20 minutes straight I can start getting issues much faster. So my theory is that this miiiight be more the fault of Arduino's String class than your library's fault. I noticed that the library does try to do some pre-allocation of the strings to prevent fragmentation. I'm sure that helps but it seems like that... isn't perfect.

I'm not sure what you're doing, but you can have multiple classes/protocols/etc on the same "IR instance". The library doesn't stop you in any way with respect to supporting/controlling multiple devices from a single ESP chip or via a single IR led.

It does though, the IRSend instance in each protocol class is a private variable you can't access. And maybe I'm doing something wrong but having more than one IRSend for the same IR LED seems to conflict with each other. Whereas when I modify the library to make the IRSend instance public, and use the same one for multiple protocols, it does work.

If you have a way of "loading in/out" code without storing it in flash, I'm all ears. I've been unable to come up with one that is acceptable. Loading in remote interpreted code across a network isn't an acceptable solution IMHO. ;-)

That's true, like literally loading a binary of each module over the network would be all kinds of insane, but I am trying to think of a way to do something like that... Like being able to dynamically add support for a new protocol without a full OTA update would be nice, through some sort of like... JSON file type thing. But then the parsing for that would take up space and all but idk... Maybe a silly/dumb feature lol

Pecacheu

comment created time in 2 months

issue commentcrankyoldgit/IRremoteESP8266

Suggestion for Lower Memory Usage

@crankyoldgit That's weird, considering that GDB found that those const variables inhabited the RAM address space and were all taking up room there. But keep in mind, the compiler's RAM usage numbers are just an estimate, they're different than the true numbers that you get at runtime.

It could be that PROGMEM actually does improve the situation at runtime (#define did for me when I did a CTRL+F replace). I would assume that a PROGMEM const would be just as good as define with none of the pitfalls.

Though frankly there's a lot of messy code in this library and bugs I've had with fragmentation after running for a long time, not to mention the codes in the AC class for the LG AC not being quite right for some of the functions, despite being for the exact same remote model I have, so I had to fix them. Oh yeah and a fahrenheit mode was missing too and it was a pain to implement because the library wasn't really set up with the best practices of code modularity. And that's depsite that craptastic Google code style guide (yeah read though that thing and it was an absolute disaster... All I'll say is, no wonder Stadia was a mess on launch lol)

The other thing is you can't dynamically load in/out different classes of device/AC, or even use multiple at once on the same IR instance, which seems like a fairly big oversight and was something I need to do. At this rate I'm considering just stealing the decoders I need (with credit of course) and putting them in a more basic IR library.

Pecacheu

comment created time in 2 months

PR opened limboemu/limbo

Android Desktop Mode Support

So I have a number of suggestions/issues/bugs and I wanted to give my feedback for improving this emulator project. But since there's no issues section it seems I have to use the pull-request system as a work around, so sorry about that. I'm not that experienced with Android development so I'm not sure how much of this I could help with, but I mean, if I find some free time I guess I could try to help with some simpler things. Anyway, here they are:

  1. Behavior It's pretty solid overall, but there's a couple of odd quirks with this app's behavior, namely that the app freezes for a few seconds, then force-closes after stopping a VM, and worse yet, the VM list resets to None by default every single time you open the app. I think it should default to the last used, and secondly, I think the None option should be removed from the list after you create your first VM, leaving only New and your current list. Might seem minor, but hey, it's the little things that make an app feel polished. <br>A rename option would also be nice, unless I'm missing it somewhere in the menus.

  2. RAM The RAM selector doesn't go very high, max 2GB. This seems a little silly in 2021. First of all I think it should be in 512 or 256MB increments, like who cares about the difference between just a few megabytes? Secondly, I realize that VMs come with some overhead so you can't use all the RAM, plus Android would probably freak out if you used way too much. But I feel like selecting up to 50% of your system RAM should be allowed. Normally, my RAM is 70% free unless I'm multitasking heavily. 50% of my RAM is 6GB, since my phone has 12GB of RAM (S21 Ultra 5G 512GB), granted 2GB is reserved for OS. <br>Hard drives larger than 20GB might also be a nice feature to have, given that I do have a just a bit of space to spare on my 512GB device.

  3. Desktop Mode Support This is the big one. Desktop mode might coming soon to Android across the board in Android 12, and users of flagships have been enjoying the glory of Desktop mode for years with the big manufacturers having their own take on it, Dex in Samsung's case. It really is an awesome experience being able to transform your phone into what's practically a full-on PC. But having the full capabilities of Windows or Linux in that environment would be amazing! <br>Only problem is, this app doesn't work right with it. It seems to support dynamic app resizing, which is great, but it doesn't properly work with a mouse. When you move the cursor over the window... nothing happens. You actually have to left-click and hold and drag the mouse around, which is insufferable! This happens regardless of what mouse mode you set for the VM. And if you select mouse mode in the menu bar, the same thing applies. You have to press and hold to move the mouse, and double-click for a single click! <br>In fact mouse mode is even more broken, because for some reason, there's this weird offset between where the real mouse cursor is and where it is in the VM. And another thing, right-click doesn't seem to work. Support for all the mouse buttons (3, 5, etc) and scroll wheel would be awesome. <br>Last but not least, fullscreen doesn't work in desktop mode either for some reason. When maximizing the window, it doesn't full-screen, and I can't seem to find a full-screen option in the menus. Oh yeah, and did I mention that when entering/exiting Dex mode the ENTIRE APP CRASHES? It means you have to completely restart the VM, unless you pause it before connecting/disconnecting a dock. Super duper annoying.

  4. Touch/Pen Support Along with mouse support, I think this is another useful improvement to add. Multi-touch support seems broken. Despite there being an option for usb-tablet under mouse settings, for me that just doesn't work. Furthermore, pen pressure (ex. S-Pen on Galaxy Note or Tab devices, and now finally the main Galaxy line starting with the S21) doesn't seem to register either, despite it literally being called tablet mode, which is a shame. I mean, imagine having full Desktop photoshop on an Android phone, plus pen support... That would be something else!

  5. Extra VM Features I'm not sure if QEMU has advanced features built-in like VMWare does, since this is my first experience with it, but if it has something like USB passthrough, OMG PLEASE SUPPORT IT! That would be amazing, being able to connect USB devices like a USB Serial port (ex. Arduino) or even better... A USB thumb drive directly into the VM would be very useful. <br>Another handy feature, especially these days, would be mic and camera support. I think this would be super easy to add by simply using one of many available open source camera/mic-over-network apps to forward the data straight into the guest OS over a local network port, though this might be slightly janky, not sure if there's a better way to do it with QEMU somehow.

+2 -0

0 comment

1 changed file

pr created time in 3 months

push eventPecacheu/limbo

Ray

commit sha 1189314cf82d5557ec2f6dc48950900ef82f52fa

Test Commit

view details

push time in 3 months

fork Pecacheu/limbo

Limbo is a QEMU-based emulator for Android. It currently supports x86, ARM, PowerPC, and Sparc emulation for Intel x86 and ARM android devices. See wiki https://github.com/limboemu/limbo/wiki for APK download and Instructions.

https://github.com/limboemu/limbo/wiki

fork in 3 months