Re: [Qbs] [baremetal] I looking proffesionals faced with Cypress FX2 && IAR

2019-10-19 Thread Richard Weickelt
> 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


Re: [Qbs] [baremetal] I looking proffesionals faced with Cypress FX2 && IAR

2019-10-19 Thread Denis Shienkov

> using toolchain-specific c extensions

IAR has not declarations of this registers for this chip. But, I have 
declared all Cypress FX2 registers in a regs.h file. So, it takes from that.


PS: I'm not stupid. ;)

19.10.2019 10:33, Oswald Buddenhagen пишет:

On Sat, Oct 19, 2019 at 10:13:45AM +0300, Denis Shienkov wrote:

something wrong with SUDPTRH && SUDPTRL features.

such registers are typically declared using toolchain-specific c 
extensions. are you sure qbs is picking up the the headers from the 
IAR toolchain?

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] [baremetal] I looking proffesionals faced with Cypress FX2 && IAR

2019-10-19 Thread Oswald Buddenhagen

On Sat, Oct 19, 2019 at 10:13:45AM +0300, Denis Shienkov wrote:

something wrong with SUDPTRH && SUDPTRL features.

such registers are typically declared using toolchain-specific c 
extensions. are you sure qbs is picking up the the headers from the IAR 
toolchain?

___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] [baremetal] I looking proffesionals faced with Cypress FX2 && IAR

2019-10-19 Thread Andrzej Telszewski

On 18/10/2019 23:02, Richard Weickelt wrote:

Why should anybody invest time in using Qbs on 8051?


Funnily, it is still very alive and used in many new chips.
If I recall correctly, TI uses it in some of its Bluetooth chips.
And I saw it recently in some new chip, but kill me, I can't remember 
what was that.


--
Best regards,
Andrzej Telszewski
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


Re: [Qbs] [baremetal] I looking proffesionals faced with Cypress FX2 && IAR

2019-10-18 Thread Richard Weickelt
Hi,

> Currently it does work with Keil C51 compiler && SDCC compiler. But, it does> 
> not work with an IAR 8051 compiler.

I guess you do not have JTAG access to this device and can step-debug. But
it looks like you have GPIOs that you could access with a logic analyzer.

> I don't know why, but the USB enumeration fails, the OS can't fetch the USB
> descriptors from the FW. e.g. at attempt to fetch the USB "Device
> Descriptor", the OS receives a zero data.

I haven't reviewed Your code, but here are some ideas:
- interrupt tables not correctly initialized
- missing volatile qualifier in variables shared between task and interrupt
context. This is a common mistake, especially when one side uses this
variable in a loop (task waiting for a flag) and never observes a change
because the variable value is kept in a register.

> Maybe, someone can help me? Because I have not ideas why it does not work
> with IAR. 

Possible strategies when you cannot debug with JTAG:
- use a GPIO and a logic analyzer to output serialized data at certain
checkmarks to see whether the program works correctly.
- decompose your application, make sure that the peripherals are working one
after another

> PS: A google has not any mention or example at using this chip && IAR 
> compiler.

And that makes me wonder if you are the only person on the planet trying to
do this. This looks like a hobby project. Is IAR even used among hobbyists?

If you want to show-case multi-toolchain development with Qbs, why 8051? I
doubt that any company uses 8051 for new projects. At least, companies would
build upon a large legacy codebase and infrastructure (we have done this for
30 years...) . Why should anybody invest time in using Qbs on 8051?

However, your project looks exotic enough to be fun :)

Richard
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


[Qbs] [baremetal] I looking proffesionals faced with Cypress FX2 && IAR

2019-10-17 Thread Denis Shienkov
Hi guys,

I want to add an additional example which implements the USB HID Game Pads
for the NES (Dendy) Joysticks:

* https://github.com/denis-shienkov/nes-gamepads/tree/fx2

This example based on a Cypress CY7C68013A chip:

* https://www.cypress.com/file/138911/download

which is based on 8051 architecture.

Currently it does work with Keil C51 compiler && SDCC compiler. But, it
does not work with an IAR 8051 compiler.

I don't know why, but the USB enumeration fails, the OS can't fetch the USB
descriptors from the FW. e.g. at attempt to fetch the USB "Device
Descriptor", the OS receives a zero data.

Maybe, someone can help me? Because I have not ideas why it does not work
with IAR.

PS: A google has not any mention or example at using this chip && IAR
compiler.

BR,
Denis
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs