- Posts: 193
- Thank you received: 0
Simple UART on Mesa 6i25 with 5i25 firmware
I am trying to add two UART pins to my pin out file, one Tx and one Rx.
But I can not guess which InstanceStride I have to use.
I looked through the pin out files of fivei25.xise and saw there InstanceStride equal to x"10" and x"00" .
Tried both but got errors when loading
How to reproduce:
Case: InstanceStride= x"10"
Pin out file: gist.github.com/sirop/c6e2e610b75f3dfbf174
readhmid output: gist.github.com/sirop/3742fc5e7e165446f25e
/var/log/linuxcnc.log snippet: gist.github.com/sirop/8477e859200aae55c0f1
Case: InstanceStride= x"00"
Pin out file: gist.github.com/sirop/e29f68a04c4dd1bbc951
readhmid output: gist.github.com/sirop/8b50a12a3f9e161e197d
/var/log/linuxcnc.log snippet: gist.github.com/sirop/48b12eb98b1c50228199
I looked through this thread www.linuxcnc.org/index.php/english/forum...erna-library-and-api
as well as at the source code of hostmot2.c , but still it is hard to guess for me where I make a mistake.
Thanks for your attention.
Please Log in to join the conversation.
So probably Case: InstanceStride= x"10" is correct and Case: InstanceStride= x"00" is not.
Will try to have a look at hostmot2.c ...
Please Log in to join the conversation.
git.linuxcnc.org/gitweb?p=hostmot2-firmw...feddd7deb577;hb=HEAD
Please Log in to join the conversation.
andypugh wrote: Look in the regmap file, that defines instance strides. (and lots of other things)
git.linuxcnc.org/gitweb?p=hostmot2-firmw...feddd7deb577;hb=HEAD
Thanks for your answer.
Did not know such a file is there. It is informative but it does not help me now
as Line 45 says:
So if sudo ./mesaflash --device 5i25 --readhmid yields:45 Instance stride is address step to next register of same type but next channel
Or is this question senseless as UARTX and UARTRX are different types?
Anyway I get this error message:
int hm2_md_is_consistent_or_complain(...) .
Variables of hm2_module_descriptor_t *md are set one function before in static int hm2_read_module_descriptors(hostmot2_t *hm2)
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...d0908c8f5b7e9d1#l656
So let's look at the interesting part of the function:
So in my case d[1] for UARTTTag would consist of:
I suppose we have to turn over these 32 bits as otherwise the right shift operator would not make any sense.
So we have then:
Then these three make sense
But what about:
then:
This also confirms the error message from /var/log/linuxcnc.log.
However, we expect UARTS to have an Instance Stride equal to x"10" or 16 in decimal.
Is this a bug in hostmot2.c ?
Please Log in to join the conversation.
sirop wrote: Did not know such a file is there. It is informative but it does not help me now
as Line 45 says:45 Instance stride is address step to next register of same type but next channel
If you look at the UART section of the register definition then you will see that the instance stride is 0x10
git.linuxcnc.org/gitweb?p=hostmot2-firmw...deb577;hb=HEAD#l1179
Nov 5 22:06:06 debian-cml2 msgd:0: hal_lib:3535:rt hm2/hm2_5i25.0: InstanceStride = 0x00000040, expected 0x00000010
The regmap file says that the instance stride is 0x10 and that is what the driver expects.
However, I have a vague memory that there is a problem that Hostmot2 doesn't really have enough options for instance stride..
Looking through old emails I find:
> On 4 June 2012 22:48, Peter C. Wallace <pcw@mesanet.com> wrote:
>>
>> UARTs fixed for all 0x10 instance(channel) strides
>
> Where do you make that change?
> (I am entertaining myself by building a custom firmware, with a UART.
> I am thinking that fast serial is a better way to get the resolver
> positions out of the Arduino)
>
Its in the TopXXX.vhd file in the strides section:
InstStride1: integer := 64; -- 4..7 64 for sserial Ick double Ick
-- InstStride1: integer := 16; -- 4..7 16 for BSPI/UART Ick double Ick
note the commented out line and the comments
And this brings up a sore spot in the HM2 firmware IDROM format.
Currently sserial and uart/bspi dont get along because there are only
2 options for each type of strides (0 and 1) and three are needed to
have normal(4), 16 and 64
The proper fix is IDROM type 4 where the instance strides are dropped from the
global section of the IDROM and added to the ModuleID section (so the 4 bit
stride selectors in the module ID records are now used directly to specify the
strides so stride = 2^Selector allowing strides of 1 to 32768 bytes in powers
of 2 per module)
Please Log in to join the conversation.
> On 4 June 2012 22:48, Peter C. Wallace <pcw@nospam.com> wrote:
And this brings up a sore spot in the HM2 firmware IDROM format.
Currently sserial and uart/bspi dont get along because there are only
2 options for each type of strides (0 and 1) and three are needed to
have normal(4), 16 and 64
The proper fix is IDROM type 4 where the instance strides are dropped from the
global section of the IDROM and added to the ModuleID section (so the 4 bit
stride selectors in the module ID records are now used directly to specify the
strides so stride = 2^Selector allowing strides of 1 to 32768 bytes in powers
of 2 per module)
Well, I read this as a missing feature or a bug.
Do I misunderstand this?
Please Log in to join the conversation.
Please Log in to join the conversation.
Please Log in to join the conversation.
It comes from git.linuxcnc.org/gitweb?p=linuxcnc.git;a...d0908c8f5b7e9d1#l762
So
would not help.It might be simplest just to comment out the "return -EINVAL" so that you get the warning but execution continues.
Please Log in to join the conversation.
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...f9d8a3d345df;hb=HEAD
I do keep meaning to make uart.c accept the same config string scheme as the absolute encoders so that you don't have to write a .comp driver to use it.
(ditto BSPI). The problem is that there are many ways to mark the beginning of a byte sequence for multi-byte data.
Perhaps the config string would need to accept hex codes to denote "punctuation" such as the 0x7e used by HDLC
Please Log in to join the conversation.
