> It did not helps, because a problem is somewhere deeped. E.g. in this code: > > static BOOL ep0_std_descriptor_proc(void) > { > BYTE XDATA *pdesc = > (BYTE XDATA *)hid_ep0_std_desc_get(); > if (pdesc) { > SUDPTRH = usb_word_msb_get(pdesc); > SUDPTRL = usb_word_lsb_get(pdesc); > return TRUE; > } > > return FALSE; > } > > something wrong with SUDPTRH && SUDPTRL features. It is a HW features of > this chip which transfer the content of a "standard" descriptors to the HOST > automatically. I.e. enough to set an address of a descriptor structure to > the SUDPTRH and SUDPTRL registers.
I can't see a problem in the assignment as such and since other register assignments work, it is unlikely a problem with SUDPTRH/L. The access order is also correct. pdesc is a pointer to the descriptor table. How sure are you that pdesc points to actual content? Where is the descriptor table content defined? Where is hid_ep0_std_desc_get() defined? > Are you know that a many modern chips based on 8051 architecture? Look on > TI, Cypress and etc. This architecture is more simple than ARM, the ARM it > not a panacea to all. I am not saying that I like ARM monoculture. I am working in the TI office that designed the 8051 2.4 GHz chips btw. The last one was published around 2009 if I am not mistaken and I would be surprised if any customer uses them in new designs. I'd be interested to see a "modern" 8051 chip. I didn't want to discourage you at all. Just looking from a different perspective: As a company You usually invest in markets where you expect growth in order to make money and win customers. Winning new customers is much easier in emerging markets. It is almost impossible in areas where everybody has settled on certain devices, tools and processes. Translated to the Qbs cpp module that means: invest in MCUs and toolchains that you expect to become important in the next years and where you expect to win users. It is much more likely that anybody starts a project with brand-new chips. This is the time where companies might evaluate tooling, play around with different options and so on. If you then have an appealing off-the-shelf solution ready, that also developers time, it is more likely to become a success. That being said: RISC-V might be a thing. Multi-core MCUs are already a thing. Building firmware for multi-processor devices with a heterogenous ABI or configuration is quite challening for GNU Make based build systems. And doing that in clicky-clicky IDEs is IMO not scalable. This is an area where Qbs excels and it might be worth to invest. For instance by finishing Qbs' half-way implemented multiplex facilities. Richard _______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs