Add devo12-XMS target

[howard0su]

although there is 2MB SPI flash built-in in devo12, there are still users asking for devo12-XMS support to have auto-detect Flash support. We have two options: 1. Enable HAS_AUTO_DETECT by default as we have enough ROM space. 2. Add another target devo12-XMS to enable it.

[TheRealMoeder]

I think there's nothing wrong with enabling flash auto detection on non Rom limited transmitters.

[howard0su]

Let me measure how much ROM it needs.

On Wed, Jan 16, 2019 at 8:53 PM TheRealMoeder notifications@github.com wrote:

I think there's nothing wrong with enabling flash auto detection on non Rom limited transmitters.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DeviationTX/deviation/issues/603#issuecomment-454768553, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuzRPfF-jlIuvrH1OUynbqWlIB58wkBks5vDyDMgaJpZM4aC2Wq .

-- -Howard

[vladislavy]

We can't simply enable HAS_AUTO_DETECT to get devo12-XMS. Devo12 use media drive at PARFlash for "media" folder, but devo12-XMS don't use it, but store all filesystem at 4MB flash. See #ifdef _DEVO12_TARGETH and #ifdef MEDIA_DRIVE.

You can look into BRANCH_5.0, it has devo12-XMS target and changed devo12 "lcd.c", "extended_audio.c" and "music.h"

Also, you can search for canceled devo12-XMS target pull request.

[howard0su]

Looks like flash two DFU files is confusing to some users. I just got someone asked about this, which I don't know exactly why there is lib.dfu until I read the code.

However what's the issue with AUTO Detect then? I enabled it and built a private and user reported that he can see a 4MB SPI flash. Are u saying we should union two flash into one global view?

On Wed, Jan 16, 2019 at 11:32 PM vladislavy notifications@github.com wrote:

We can't simply enable HAS_AUTO_DETECT to get devo12-XMS. Devo12 use media drive at PARFlash for "media" folder, but devo12-XMS don't use it, but store all filesystem at 4MB flash. See #ifdef DEVO12_TARGET_H and

ifdef MEDIA_DRIVE.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DeviationTX/deviation/issues/603#issuecomment-454821815, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuzRDTzdfT5a__ZsQK1t7pXW94orRxqks5vD0YDgaJpZM4aC2Wq .

-- -Howard

[vladislavy]

He will see a 4MB SPI flash, but still need to use lib.dfu with "media" folder in it.

[howard0su]

I see. so the files put into "media" in spi flash doesn't work at all?

On Wed, Jan 16, 2019 at 11:40 PM vladislavy notifications@github.com wrote:

It will see a 4MB SPI flash, but still need to use lib.dfu with "media" folder in it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DeviationTX/deviation/issues/603#issuecomment-454825088, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuzRCo60DqohQ-bPGg72A8x1Eqjwovbks5vD0gAgaJpZM4aC2Wq .

-- -Howard

[vladislavy]

Yes, we need another target for devo12-XMS to solve it. Probably it can be solved with single target, but I don't know how.

[PhracturedBlue]

what is the reason to have XMS on the devo12? I am not in favor of a new tx target in this case. we should be able to solve this in software, the 12 has lots of free space.

[howard0su]

that's the one of the solution we are discussing. The problem is that devo12 has two flash one internal PAR and another external SPIFlash. User basically want to change external flash to something bigger, let's say 4MB. However today we lookup media only in PAR not in SPIFlash. So the SPIFlash is not useful. the solution can be : 1/ have a separate target which doesn't support PAR 2/ drop PAR flash completely when we detect external flash 3/ union two flash together. it is not easy consider handle open/readdir.

On Wed, Jan 16, 2019 at 11:59 PM PhracturedBlue notifications@github.com wrote:

what is the reason to have XMS on the devo12? I am not in favor of a new tx target in this case. we should be able to solve this in software, the 12 has lots of free space.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DeviationTX/deviation/issues/603#issuecomment-454832767, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuzRPxpRKv20uwSklVhk066wv-V2y8Sks5vD0xwgaJpZM4aC2Wq .

-- -Howard

[PhracturedBlue]

Is XMS even fast enough for the big images? SPI may not be fast enough to have good perfromance for reading media directory.

Your 3rd option should not be hard to implement. it could be done entirely in syscalls.c most likely.

[PhracturedBlue]

how much ROM does XMS require? is it really necessary to have separate build targets for it for other Transmitters? Is the primary reason for a separate build to disable devofs?

[TheRealMoeder]

Yes, devofs is not used in xms builds

[vladislavy]

devo12-XMS quite fast with "drawn_background=1" at "config.ini".

[background] drawn_background=0 bg_color=50A0D8 hd_color=707070

[PhracturedBlue]

Sure, but that doesn't answer my question. How is it with 'drawn_background = 0'? I'm trying to determine if (2) or (3) makes sense. (2) is simpler to implement. If the use of XMS means that the background can be put on SPI and perform OK, then the answer is simple...we should do (2). But I bet it isn't true, since otherwise Walkera wouldn't have invested in using a parallel flash chip in the 1st place.

The alternative is (3) which allows users to put the background (and anything else) on the parallel flash and still overwrite the smaller files on SPI.

[caixiaohai0]

在devo12上使用XMS的原因是什么？在这种情况下，我不赞成新的tx目标。我们应该能够在软件中解决这个问题，12有很多可用空间。

I think it should be like devo8s, so that users can freely change the background map and have more personalized things. I can't generate devo12-lib.dfu files with the program you provide. Every time, I generate parallel slash file paths. This is my suggestion. Forgive me for my poor English

[PhracturedBlue]

The problem is that the internal memory architecture makes this difficult. I did have an idea though. Any thought son using MTP/PTP instead of MSC for the devo12? We could then use an internal page-mapping scheme (something like what is done for devofs) which would allow us to use the entire 16MB flash as a normal drive (probably requiring wasting 1 or 2 128kB pages for buffer). I didn't see an implementation for libopencm3, but it looks like there migt be one for STM32Cube. If it is small enough, it might also allow transparent access to devofs too

[howard0su]

MTP should be easy to implement compare to UMASS considering it's simpler. However the OS support is limited, from wikipedia, seems only Windows has a good support. https://en.wikipedia.org/wiki/Media_Transfer_Protocol

On Thu, Jan 31, 2019 at 2:06 AM PhracturedBlue notifications@github.com wrote:

The problem is that the internal memory architecture makes this difficult. I did have an idea though. Any thought son using MTP/PTP instead of MSC for the devo12? We could then use an internal page-mapping scheme (something like what is done for devofs) which would allow us to use the entire 16MB flash as a normal drive (probably requiring wasting 1 or 2 128kB pages for buffer). I didn't see an implementation for libopencm3, but it looks like there migt be one for STM32Cube. If it is small enough, it might also allow transparent access to devofs too

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DeviationTX/deviation/issues/603#issuecomment-459025238, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuzRO8XL3tnUC9tQkWh_yPbPQUF2Wodks5vIdD9gaJpZM4aC2Wq .

-- -Howard

[howard0su]

one idea, just do combine both range as a single address space and let it shows up as one driver. I think this is pretty easy to implement and only need a small change in mass_mal.c. And let the filesystem code to reuse mass_mal function to read the content as well.

On Thu, Jan 31, 2019 at 8:12 AM Howard Su howard0su@gmail.com wrote:

MTP should be easy to implement compare to UMASS considering it's simpler. However the OS support is limited, from wikipedia, seems only Windows has a good support. https://en.wikipedia.org/wiki/Media_Transfer_Protocol

On Thu, Jan 31, 2019 at 2:06 AM PhracturedBlue notifications@github.com wrote:

The problem is that the internal memory architecture makes this difficult. I did have an idea though. Any thought son using MTP/PTP instead of MSC for the devo12? We could then use an internal page-mapping scheme (something like what is done for devofs) which would allow us to use the entire 16MB flash as a normal drive (probably requiring wasting 1 or 2 128kB pages for buffer). I didn't see an implementation for libopencm3, but it looks like there migt be one for STM32Cube. If it is small enough, it might also allow transparent access to devofs too

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DeviationTX/deviation/issues/603#issuecomment-459025238, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuzRO8XL3tnUC9tQkWh_yPbPQUF2Wodks5vIdD9gaJpZM4aC2Wq .

-- -Howard

-- -Howard

[PhracturedBlue]

We'd probably use P2P which is a subset of MTP and supported by all major OSes. The problem isn't combining the ranges. if it were only that I would have just setup 2 partitions and been done with it. The problem is that the block size is 128kB. That is bigger than FAT supports, and FAT doesn't support having a cluster size smaller than the page size. because the FS is read-only on the Tx, we can get away with using 4k sectors, but it doesn't work if you want to do a write. Instead we need a NOR-Flah optimized FS which allows for page sizes smaller than the erase size. DevoFS is one such FS (but it is optimized for small filesystems and won't scale efficiently to 16MB). something like yaffs might be more applicable to the devo12. But with a non-FAT fs, we need MTP/PTP

[howard0su]

Not good for the complexity v.s. gain. I would prefer just making internal flash as readonly and add fallback from XMS. we can revise this when we have more Tx having the similar situation.

[PhracturedBlue]

I think there is real gain for PTP if it is small enough for the devofs based radios who currently have a worse user experience

[howard0su]

If you do not know about this: https://developer.chrome.com/apps/app_usb

I think this is more forward looking to have a website to viewed in chrome to do customization including one click download of community uploaded models, firmware upload, mixer setup. Someone has the implementation of device side based on libopencm3. I would prefer to try cutting edge tech instead of implementing MTP. https://link.medium.com/BwU4b73bWT

On Friday, February 1, 2019, PhracturedBlue notifications@github.com wrote:

I think there is real gain for PTP if it is small enough for the devofs based radios who currently have a worse user experience

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DeviationTX/deviation/issues/603#issuecomment-459431885, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuzROn7HXXylwhmd5H_PXix2mfv6zDcks5vIyeMgaJpZM4aC2Wq .

-- -Howard

[howard0su]

shall i just add FLASH_DETECT to the devo12 for now before we make call on other things?

[PhracturedBlue]

i don't see any reason we wouldn't use FLASH_DETECT on all Tx except where there is no flash (t12/x9d/at9) or enabling it costs us some other needed feature.