Giter VIP home page Giter VIP logo

Comments (9)

xedbg avatar xedbg commented on June 12, 2024 1

Hi Dominic, It has unfortunately been slipping out of the last few sprints, but we still hope to release it this side of summer. Which means May/June.
(There should be few risks attached, but we need to run a set of QA procedures.)
Its good that you ping us like this - then we are aware of you!
(Edit; currently scheduled for sprint 16.05-27.05)
(Edit2: I just published the latest build of (3.13) to test.pypi to help to fast-track any pre-release verification)

from pymcuprog.

xedbg avatar xedbg commented on June 12, 2024

Hi Tim, you are not the first to request this :) and yes, we all agree its annoying. After using it for a few years, doing the separate pre-erase becomes a (bad) habit.
All memory types are not equal and hex files can contain a mix of them, so we have chosen to ignore this until we settle on the best way to do this (yes, we have discussed it a lot...) that keeps all architectures happy.
Correct, fuses to not need an erase (they are like eeprom) which is just how they are.
To implement auto pre-erase correctly, I suspect we should be erasing any memory sections which are included in the (hex) file being programmed, if that area requires erasing, or if the specified area (-m) requires it. Not all flash architectures and debuggers support the same 'region erase' capabilities... so the temptation is just to do a chip erase... but that may have undesirable side effects, like erasing eeprom while writing flash.
Logged (again) internally as DSG-3951, although fixing this will have to be argued through with a fair amount of coffee again...
Thanks for the input!

from pymcuprog.

T3sl4co1l avatar T3sl4co1l commented on June 12, 2024

Huh, I always assumed HEX was flat. But that makes sense. Ah, I see just objcopying an ELF puts the Flash at zero and fuses at, 0x820000 I think that would be. Which sounds like where they're represented in the ELF too.

Which, that'd be another thing, take in the ELF format directly. That's probably a lot more work and not really needed with the ready availability of binutils... just nice to have eventually.

As for erase, there's a fuse about EEPROM erase, at least on this device; I would tend to just assume the user's set that correctly, or maybe add a confirm prompt/option; or maybe read the fuse and check if that was intended or whatever. Or, I mean... how does avrdude handle it? :P

from pymcuprog.

sh-mcu8apps avatar sh-mcu8apps commented on June 12, 2024

You are right about the EEPROM fuse for AVRs, but remember this tool is also for PIC devices. Some PIC devices have bulk erases that only erase Flash and some don't. Then if you have a hex file with several segments, do you erase the whole flash or just the segments to be written (remember you can have several segments in a hex file for the same memory). What if the device has erase sections that does not match the segments in the hex file. Then the tool would have to read out flash, modify according to hex content and write back. All in all what you suggest is possible but far from trivial. And it might also increase programming time significantly. But I do agree, having to explicitly run erase upfront is annoying.

from pymcuprog.

xedbg avatar xedbg commented on June 12, 2024

"lowest cost" solution proposal might be: add --erase switch (or something like that) which will do the easiest/simplest chip-erase before writing whatever its writing, from wherever its writing from. This is back-compatible with existing behaviour, and is explicit enough to not have to do anything complicated (you ask for it, you get it). Cost to users is a new (bad) habit of adding the --erase, but at least it becomes a one-liner.
Might also be an option to add a "hint" to users (logging.warning) if verification happens to fail and --erase was not specified.

from pymcuprog.

xedbg avatar xedbg commented on June 12, 2024

This didn't make the cut for 3.10.2 and will be scoped for 'next' release

from pymcuprog.

xedbg avatar xedbg commented on June 12, 2024

@T3sl4co1l :
Version 3.11 on pypi test has --erase switch on write: https://test.pypi.org/project/pymcuprog/3.11.3.142/

as documented, and as suggested here, this is the "lowest-cost" solution in terms of simplicity and back-compatibility.
--erase will do a chip erase before writing from an Intel hex file
It will not work for writing bin or literal (excluded to avoid complications)

from pymcuprog.

domdfcoding avatar domdfcoding commented on June 12, 2024

What's the timeline for releasing 3.11 to PyPI proper?

from pymcuprog.

xedbg avatar xedbg commented on June 12, 2024

--erase is now supported in 3.13

from pymcuprog.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.