Compatibility with new pointer-wrapper ProgMem

[Cryptjar]

In my latest commit, I changed the internals of the ProgMem wrapper from being a wrapper around a value that is stored in progmem to a wrapper around a pointer that point to another static that in turn is stored in progmem. I haven't merged this yet to the v0.2 branch (see Cryptjar/avr-progmem-rs#5), because I noticed this will break your avr_progmem_str macro.

Unfortunately, this change of ProgMem makes its constructor to take a pointer instead of a value. This means that PmString can't be created by-value either (such as an array), and thus I had to remove the PmString::from_array constructor that your avr_progmem_str macro uses, sorry.

However, the good news is, that the new way in which the PmStrings are created means that there is no more need for #![feature(const_option)], which seems to have been the motivation for avr_progmem_str.

cc Cryptjar/avr-progmem-rs#3

[mutantbob]

I have no objections to your change breaking avr_progmem_str! it was a research/proof-of-concepts, and if it helps accelerate progress in the progmem crate then it has already succeeded.

If you want to use the string_as_bytes! macro i should probably be copied into a published crate. I have never published a crate before, and would be very happy if someone experienced were to take it off my hands .

[mutantbob]

Actually, the original motivation for avr_progmem_str! was that I was having difficulty creating a string that actually lived in progmem. My experiments of a week or so ago led me to believe the slice (pointer and length) would live in progmem, but the character bytes would be in RAM. I am no longer quite as sure about that conclusion.

[Cryptjar]

I have no objections to your change breaking avr_progmem_str! it was a research/proof-of-concepts, and if it helps accelerate progress in the progmem crate then it has already succeeded.

That's alright. Then I will merge that change when I completed it, after which I' going to release the v0.2 version.

If you want to use the string_as_bytes! macro i should probably be copied into a published crate. I have never published a crate before, and would be very happy if someone experienced were to take it off my hands .

I quite like the string_as_bytes! macro, I think it is worthy of becoming a published crate. If you don't want to publish that, I can do it, with your permission.

Actually, the original motivation for avr_progmem_str! was that I was having difficulty creating a string that actually lived in progmem. My experiments of a week or so ago led me to believe the slice (pointer and length) would live in progmem, but the character bytes would be in RAM. I am no longer quite as sure about that conclusion.

It depends on what you do, if you have something like this:

#[cfg_attr(target_arch = "avr", link_section = ".progmem.data")]
static MESSAGE3: &str = "apple";

you would be entirely correct, that only the pointer and length would be stored in progmem whereas the actual content (i.e. "apple") would be stored in RAM. As you pointed out, strs are a bit complicated.
However, if you use the progmem! macro like this:

avr_progmem::progmem! {
    static progmem string MESSAGE3 = "apple";
}

Then the progmem! macro makes sure to store "apple" as a byte array in progmem.