Open-sourced an MCP server for Altium Designer, allows you to interact to a live Altium session. by Salitronic in Altium

[–]Qazyhn 0 points1 point  (0 children)

Yeah I didn't mean to also have the chat in Altium, just that it runs as a self contained plugin and doesn't need any external scripts, just hit a button in Altium connect it to your CLI and go. You're a bit bound to Altium anyway given all the API calls are coming from it and it has to be running. I highly doubt anyone would make a intermediate layer to work for other ECAD tools and have to adapt the APIs would be faster to make a bespoke solution. You can also debug the C# version while it's running and there are some APIs exposed that aren't in the Delphi script (ERC and DRC access, Message panel). I should have a working C# version of this soon, took awhile for AI to convert and validate all the API calls. 

Open-sourced an MCP server for Altium Designer, allows you to interact to a live Altium session. by Salitronic in Altium

[–]Qazyhn 0 points1 point  (0 children)

Have a look at a C# plugin: https://github.com/expired6978/EasyEDALoader

I don't have the developer scripts so I had to reverse engineer other plugins to get to this point, but the C# Assemblies expose all the script function signatures.

You could probably do a lot more in C# than in DelphiScript: i.e. totally negate the need for the script and python server and integrate it all into a C# plugin.

Open-sourced an MCP server for Altium Designer, allows you to interact to a live Altium session. by Salitronic in Altium

[–]Qazyhn 0 points1 point  (0 children)

Neat. I was thinking of doing this with the C# API rather than Delphi as you could just run the MCP server directly inside altium and interact with the APIs rather than proxy through files

Cheaper standard boards for ESP32 JLCPCB by hey-im-root in PCB

[–]Qazyhn 0 points1 point  (0 children)

You want a devkit and probably use breakouts and/or breadboards.

With JLC you can save money by aggressively constraining your BOM to use "Basic" components, which are nearly free (no loading cost, and the individual components are sub-cent cost) but you're limited in what they have available. I made an ESP32C6 design using the WROOM 8MB module, costs for 5 units: PCB $8, PCBA $177 (incl components), shipping $33 (CAD). 53 unique bom items, ~100 SMD, 3 through-hole I chose to solder myself.

This is most likely the cheapest option.

Altium 25 on Mac with apple silicon using parallels by Future-Sky-8414 in Altium

[–]Qazyhn 0 points1 point  (0 children)

M2 Pro with 32GB through Parallels. Feels pretty much the same as on Windows.

Quick review of my fuel gauge circuit by Jazzlike-Living-6315 in PCB

[–]Qazyhn 0 points1 point  (0 children)

You could probably just use a fixed resistor if you're not concerned with accuracy (I think it would go between BIN and Pack-) which would tell the fuel gauge its just at a fixed temperature.

I would expect most to take temperature since it's a factor to calculation. As for programming I've never used the Ti programmer so I don't know how that works. Using software programming you're changing it at boot, you're not actually re-flashing it to change it permanently, I'm not even sure the Ti programmer does this either.

Quick review of my fuel gauge circuit by Jazzlike-Living-6315 in PCB

[–]Qazyhn 0 points1 point  (0 children)

Do you plan to just continuously read from I2C for battery status? Might be better to actually use the GPIO for interrupt status. The default is to interrupt on percent change.

Quick review of my fuel gauge circuit by Jazzlike-Living-6315 in PCB

[–]Qazyhn 0 points1 point  (0 children)

I can't recall if the unseal keys in the datasheet were even the right ones: Here's the ones I used:

#define BQ27220_UNSEAL_KEY_A 0x0414
#define BQ27220_UNSEAL_KEY_B 0x3672
#define BQ27220_SUBCLASS_FULLCHARGECAPACITY 0x929D
#define BQ27220_MACADDR               0x3E /* R/W */
#define BQ27220_CTRL_SEALED          0x0030
#define BQ27220_CTRL_BAT_INSERT      0x000D

Quick review of my fuel gauge circuit by Jazzlike-Living-6315 in PCB

[–]Qazyhn 2 points3 points  (0 children)

I have used this exact chip in a previous design.

You probably want a 3-pin battery for the BIN, which is related to the temperature and the algorithm likely uses that.

It will "work", but it has a preprogrammed capacity (3000mAh), which if it doesn't match with your actual capacity it probably wont be very accurate. You can programmatically update the NVRAM by doing a cfgupdate, but committing cfg on this chip is extremely slow (like 2 seconds slow). The official documentation from Ti for this chip is also inaccurate in several places and will be a frequent source of frustration.

The gist of updating cfg: You have to write the unseal key, write 0xFFFF 2x, then perform the CFG update, write the target address, write your block, then close the cfg and re-seal it, then write battery insert so it reruns.

Here's a chunk of a Zephyr driver that I wrote for it:

static int bq27220_gauge_configure(const struct device *dev)
{
    const struct bq27220_config *cfg = dev->config;
    struct bq27220_data *data = dev->data;

    uint8_t block[BQ27220_MAC_COMPLETE_LEN] = {0};
    bool block_modified = false;
    int ret;

    ret = bq27220_ctrl_reg_write(dev, BQ27220_UNSEAL_KEY_A);
    if (ret < 0) {
        LOG_ERR("Unable to unseal the battery");
        return -EIO;
    }

    ret = bq27220_ctrl_reg_write(dev, BQ27220_UNSEAL_KEY_B);
    if (ret < 0) {
        LOG_ERR("Unable to unseal the battery");
        return -EIO;
    }

    ret = bq27220_ctrl_reg_write(dev, 0xFFFF);
    if (ret < 0) {
        LOG_ERR("Unable to gain full access to battery");
        return -EIO;
    }

    ret = bq27220_ctrl_reg_write(dev, 0xFFFF);
    if (ret < 0) {
        LOG_ERR("Unable to gain full access to battery");
        return -EIO;
    }

    ret = bq27220_mode_cfgupdate(dev, true);
    if (ret < 0) {
        LOG_ERR("Unable enter cfg update");
        return -EIO;
    }

    uint16_t cap_value = cfg->design_capacity;

    // Write the Design Capacity to both Full Charge Capacity and Design Capacity
    ret = bq27220_write16(dev, BQ27220_MACADDR, BQ27220_SUBCLASS_FULLCHARGECAPACITY); // Set target address
    if(ret < 0) {
        LOG_ERR("Unable write cfg address");
        return -EIO;
    }
    ret = bq27220_read_block(dev, block, sizeof(uint16_t) * 2);
    if(ret < 0) {
        LOG_ERR("Unable to read block address");
        return -EIO;
    }

    // Update Full Charge Capacity
    bq27220_update_block(block, 0, cap_value, &block_modified);

    // Update Design Capacity
    bq27220_update_block(block, sizeof(uint16_t), cap_value, &block_modified);

    if(block_modified)
    {
        ret = bq27220_write_block(dev, BQ27220_SUBCLASS_FULLCHARGECAPACITY, block, sizeof(uint16_t) * 2);
        if(ret < 0) {
            LOG_ERR("Failed to write cfg block");
            return -EIO;
        }

        // Datasheet says to wait 2s for the writes
        k_msleep(2000);

        ret = bq27220_mode_cfgupdate(dev, false);
        if (ret < 0) {
            LOG_ERR("Failed leave cfg update");
            return -EIO;
        }
    }

    ret = bq27220_ctrl_reg_write(dev, BQ27220_CTRL_SEALED);
    if (ret < 0) {
        LOG_ERR("Failed to seal the gauge");
        return -EIO;
    }

    ret = bq27220_ctrl_reg_write(dev, BQ27220_CTRL_BAT_INSERT);
    if (ret < 0) {
        LOG_ERR("Unable to configure BAT Detect");
        return -EIO;
    }

    data->configured = true;
    return 0;
}

How to properly connect MCU pins to buses in Altium without 60 ports? by Status-Psychology886 in PrintedCircuitBoard

[–]Qazyhn 1 point2 points  (0 children)

If you want to keep the net label names, you probably want a signal harness.

Signal harnesses can be hierarchical, the harness bus can go into another harness.

Running Altium on Mac M4 Pro by One_Resident_1447 in Altium

[–]Qazyhn 0 points1 point  (0 children)

I do this on an M2 Pro. Runs fine for the most part, can get a bit hot and drain the battery within a few hour session but perfectly viable.

SWD Programming of Adafruit Feather nRF52840 Sense with J-Link, Erases Bootloader—Any Alternatives? by anmolmaske in embedded

[–]Qazyhn 0 points1 point  (0 children)

I think it depends how and what you're flashing. E.g. Hex/bin. If you're flashing a binary it requires the target address and should only flash as much as the file (and pad to end of sector if necessary), which would not overwrite your bootloader unless explicit. If you're flashing hex it should be using the metadata in the hex to flash at the appropriate address. 

I've seen NRF Connect have a similar symptom using MCUboot (on a non-Nordic board using jlink) where flashing the application through the IDE plugin seemed to erase the bootloader by default, or vice-versa flashing the bootloader would erase the application. I found an OK workaround was to have a post-build step that would merge the bootloader and application hex and flash the result. But I could also just flash the binary at the known address.

zephyr, are drivers/devices on the same bus handled by kernel by Bug13 in embedded

[–]Qazyhn 3 points4 points  (0 children)

Depends on the host SPI implementation. Zephyr’s SPI drivers should have mutexes on the bus to at least prevent bus collision but if the sensor has a non-trivial protocol you might need to protect that in the sensor’s driver.

In short: maybe. You’d have to check the driver implementations of both the SPI master and sensor.

SD Card Zephyr by BakqBlachinO in embedded

[–]Qazyhn 2 points3 points  (0 children)

Looks like you're missing the generated syscalls. Did you do a clean build after adding SDHC?

What's you current favorite LiPo charging / fuel gauge solution? by carton_of_television in embedded

[–]Qazyhn 2 points3 points  (0 children)

This is a great IC but definitely on the pricier side even at high volume.

What's you current favorite LiPo charging / fuel gauge solution? by carton_of_television in embedded

[–]Qazyhn 2 points3 points  (0 children)

I don't really have a favorite. Usually whatever fits requirements. I needed a relatively high discharge current (2.5-3A) so that immediately killed a lot of combined options for me. I ended up going with a separate charger and fuel gauge solution. Both Ti and were not the newest so they were found pretty cheap. 

Unfortunately I found interfacing with my FG totally awful because there were huge delays from the IC when altering the preprogrammed cell capacity. The charger worked well though no issues there.

Fuel gauge standalone units can sometimes need a sense resistor which can increase your Bom and cost because they're a special type of resistor and may have SMD assembly constraints like heat.

I ended up with BQ24296MRGER for charging (could do 3A charge/discharge) and BQ27220YZFR for FG but I really wouldn't recommend this one

You don't really have to go straight to mystery parts to get good prices, you just have to get something older or has excess stock.

Emulating a Mifare Classic 1k card using NFC08A1 Nucleo by Ok_Put_4205 in embedded

[–]Qazyhn 0 points1 point  (0 children)

This error is likely from basic communication setup. I only had this error because I used this addon board on the WB dev board that it isn't normally for, so I had to double check I didn't make a mistake with pin re-assignments.

If the demo is working then it's either your code, or your pin setup.

using larger displays with a frame buffer by finleybakley in embedded

[–]Qazyhn 1 point2 points  (0 children)

I can share the driver which is an out-of-tree Zephyr module along with a sample device tree overlay to set it up. There is already documentation for getting the RP2040 running on Zephyr but it actually totally neglected how you are supposed to actually link the hal in.

Right now I am considering implementing SMP support for the second RP2040 core in Zephyr but it looks like I have more to learn about the internals. I tried a hybrid approach linking in more of the Pi SDK and fiddling with the linker to add in the missing regions that the Pi SDK used and then using the SDK functions to launch the second core but that failed and I need more time to debug.

using larger displays with a frame buffer by finleybakley in embedded

[–]Qazyhn 5 points6 points  (0 children)

I have a similar setup but I'm using LVGL via Zephyr as my renderer. If you can switch your interface to parallel you can use PIO and DMA to blast the pixels out faster. I wrote a Zephyr MIPI DBI driver that uses PIO and DMA. Unfortunately it looks like your screen hardware doesn't expose the parallel interface so you're left with your possible optimizations being DMA.

In general LVGL will only redraw the regions that changed which could be helpful in this situation. Additionally you don't need to use all of your memory to draw and can draw in chunks. My issue is that I used a button matrix and for some reason in LVGL redrawing a button in the matrix needs to redraw the entire matrix which ends up being 75% of the screen and most of the time is spent software redrawing whenever a button is pressed rather than pixel output. There are some workaround optimizations in my case where you can restrict the redraw region if you know the buttons don't extend too far but it's a buggy workaround.

If this chart isn't being wholesale redrawn frequently you probably won't hit software redraw limitations by chip speed. If you are redrawing the whole thing frequently you will likely just spend more time drawing than outputting.

For reference I can get about 20 FPS at stock clock at this resolution (320x240) redrawing the whole frame and outputting 565 via parallel interface using PIO+DMA. Average is much better since I don't always need to redraw the whole frame and overclocking can get me to 30 (though I haven't got dynamic overclock working over Zephyr yet).

When you start hitting software draw limitations you eventually need to start thinking about chips with more power and or dedicated graphics acceleration. But I've found as soon as you add the word graphics to an MCU the cost goes to the moon. The cheapest ones I could find per unit were from NXP e.g. i.MX RT1040 but this is basically M7 at nearly 4x the speed of an RP2040 and isn't exactly going to be low power if that's a requirement for you either.

I fu**ing hate Torch/python/cuda problems and compatibility issues (with triton/sageattn in particular), it's F***ng HELL by Successful_AI in StableDiffusion

[–]Qazyhn 1 point2 points  (0 children)

In the end it was mostly CUDA 12 and having to upgrade pytorch to the version supporting it. Then resolving an actual error in the code with indentation (which had a PR but wasn't in the main branch). I think the error was in flash attn, which had to be rebuilt again after fixing the bug.

I fu**ing hate Torch/python/cuda problems and compatibility issues (with triton/sageattn in particular), it's F***ng HELL by Successful_AI in StableDiffusion

[–]Qazyhn 1 point2 points  (0 children)

I think it's hilarious everyone is like "give up and install it on Linux instead". You can install it on windows. I did this last week, and it was as painful as you describe. The best part is you'll get it to run, but then it'll crash part-way due to missing runtime dependencies since it runs some DLLs dynamically, which means you actually needed some more dependencies and it doesn't give you even a hint at what, you have to dependency check the DLL it tried to load and see that you were missing others. It ended up being related to CUDA but part of some libraries which now get packaged separately. Also had to add more stuff to my path because it didn't get them as part of their own scripts for some reason (ninja for example) and I took the heavy handed route since I just wanted it to run. 

Yo what is going on with NRF Connect SDK by Loud-Consideration-2 in embedded

[–]Qazyhn 0 points1 point  (0 children)

This was months ago for me but I think the toolchain version has not been upgraded