> 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
