Hi,
do you mind to create a pull request for it? This imho would make discussion of
the code easier. You can add [WIP] in the title to highlight it's work in
progress.
Cheers,
Marian
Am 27. Januar 2019 11:44:21 MEZ schrieb Federico Pellegrin <f...@evolware.org>:
>Hi,
>I did a mostly working (please see below for why mostly!) scratch of
>the implementation and put it here for now:
>https://github.com/fedepell/RIOT/commit/3b9de66ce0a9d722460c3b236ef67835df91cd90
>
>I tested it and it is working on my saml21-xpro board. I can write on
>the 8KBs of RWWEE memory and read it and see that it is still there
>after rebooting and stuff. I took care to make it compile also on
>saml11 (define names are different) although I cannot test this. As
>you will see the code is mostly a copy & paste of the standard
>flashpage, with a bunch of different defines used (for base adresses
>and registers).
>As I presumed in previous emails, it looks kinda ugly to me, but I'm
>not sure we could reuse totally the code without a major refactoring
>or by making many if-s in the common code (even asserts would depend
>on if we are using RWWEE or not) to keep them united (and therefore
>less performant). Please give it a look and let me know what do you
>think!
>
>
>As for "mostly working" what is still puzzling me is that the code
>seems to have some kind of alignment issue or so (although I take care
>of using aligned memory structures are required) since if I add/remove
>some statement it may then just hang or generate a hardfault. It is
>quite puzzling me since I tried to rule out all possibilities but
>cannot get it working. But maybe it's just that I'm stubbornly doing
>this from some time and I need to detach from it mentally for a while
>;) But since I have to go out in a while I wanted to commit it so if
>someone wants to give it a look in the meantime, mostly refering to
>the structural question of how to implement it, it is there on github.
>And maybe someone has a general suggestion about this maybe-alignment
>issue from previous experience!
>
>Thanks!
>
>Cheers,
>Federico
>
>
>
>
>
>
>Il giorno sab 26 gen 2019 alle ore 05:46 Federico Pellegrin
><f...@evolware.org> ha scritto:
>>
>> Hi Dylan and Oleg,
>> Thanks for the feedback!
>>
>> Sorry I meant kilobyte indeed, but always write it wrong, both the
>k-s
>> (should be K I see now) and b-s ;)
>>
>> Regarding implementation:
>>
>> To make it interrupt driven I guess it would be quite more a radical
>> change, so I would look at least for now for a blocking one, which
>> basically makes it just an additional flash area no different than
>the
>> main one.
>>
>> About doing it similar to eeprom what I see, API wise, is that the
>> eeprom one you link (and eeprom in general) is not page based, while
>> the flash one (and also the RWWEE since the interface is the same) is
>> page based. So you need always to work with pages (erase especially).
>> So I would see it more indeed like the flashpage itself indeed.
>That's
>> why my doubts on having it separate or not, since mostly what changes
>> in the code would be the start offset, various limits now #defines
>> (such as FLASHPAGE_NUMOF) and some flags when accessing the CPU (ie
>> using NVMCTRL_CTRLA_CMD_RWWEEER instead of NVMCTRL_CTRLA_CMD_ER)
>>
>>
>> Cheers,
>> Federico
>>
>> Il giorno ven 25 gen 2019 alle ore 09:21 Dylan Laduranty
>> <dylanladura...@gmail.com> ha scritto:
>> >
>> > Hello Federico,
>> >
>> > IIRC, this flash can be use as a virtual EEPROM. Maybe It would be
>better to write a eeprom driver (like STM32 [1]) rather than add it to
>the flashpage driver ?
>> > I also think this memory is 8KB for SAML21J18 (not 8Kb), which is a
>lot :)
>> >
>> > As a side note: SAML21 also have 8KB of Low Power SRAM in addition
>to its 32 KB of SRAM
>> >
>> > I've never played with these additional memories but I'll be happy
>to help.
>> >
>> > Cheers,
>> > Dylan
>> >
>> > [1]
>https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common/periph/eeprom.c
>> >
>> > Le mer. 23 janv. 2019 à 14:27, Federico Pellegrin
><f...@evolware.org> a écrit :
>> >>
>> >> Hi,
>> >> Working on SAML21 based project it came to my attention also the
>> >> presence of an 8Kb additional flash that is called
>"Read-While-Write"
>> >> (or RWWEE in the datasheet) that, as far as I understood, can be
>> >> programmed and read in a very similar way to the normal flash.
>This is
>> >> currently not supported anyhow in RIOT as far as I see. This is
>also
>> >> present in other SAM chips (a grep on the RIOT sam0 common
>includes
>> >> tells me saml21, samd21 and samr30).
>> >>
>> >> Well it's just 8Kb (in saml21 case) but a customer is asking about
>it ;)
>> >>
>> >> Before starting to fiddle with code I was wondering if any of you
>> >> already saw this or had intention to work on or had problems with
>this
>> >> or.... any information would be great :)
>> >>
>> >> On the other side I would also be interested in an opinion if the
>> >> access to this facility should eventually be kept totally separate
>> >> from the current (with some possible code redundancy, but with the
>> >> possibility no to include it into a project) or could be
>integrated
>> >> into the current flashpage driver (bringing some complication of
>the
>> >> logic of the current code)
>> >>
>> >> Thanks!
>> >>
>> >> Cheers,
>> >> Federico
>> >> _______________________________________________
>> >> devel mailing list
>> >> devel@riot-os.org
>> >> https://lists.riot-os.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > --
>> > Dylan Laduranty
>> > _______________________________________________
>> > devel mailing list
>> > devel@riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/devel
>_______________________________________________
>devel mailing list
>devel@riot-os.org
>https://lists.riot-os.org/mailman/listinfo/devel
--
Via mobile phone
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
