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
loadrt hm2_pciHow 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 or Create an account to join the conversation.
InstStride1: integer := 64; -- instance stride 1 = 64 bytes = 16 x 32 bit registers !! UARTS need 0x10So 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 or Create an account to join the conversation.
git.linuxcnc.org/gitweb?p=hostmot2-firmw...feddd7deb577;hb=HEAD
Please Log in or Create an account to join the conversation.
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
Pin# I/O Pri. func Sec. func Chan Pin func Pin Dir
2 2 IOPort UARTTX 0 TXData (Out)
15 3 IOPort UARTRX 0 RXData (In)Or is this question senseless as UARTX and UARTRX are different types?
Anyway I get this error message:
Nov 5 22:06:06 debian-cml2 msgd:0: hal_lib:3535:rt hm2/hm2_5i25.0: inconsistent Module Descriptor for UART Transmit Channel, not loading driver
Nov 5 22:06:06 debian-cml2 msgd:0: hal_lib:3535:rt hm2/hm2_5i25.0: Version = 0, expected 0
Nov 5 22:06:06 debian-cml2 msgd:0: hal_lib:3535:rt hm2/hm2_5i25.0: NumRegisters = 4, expected 4
Nov 5 22:06:06 debian-cml2 msgd:0: hal_lib:3535:rt hm2/hm2_5i25.0: InstanceStride = 0x00000040, expected 0x00000010
Nov 5 22:06:06 debian-cml2 msgd:0: hal_lib:3535:rt hm2/hm2_5i25.0: MultipleRegisters = 0x0000000F, expected 0x0000000F
Nov 5 22:06:06 debian-cml2 msgd:0: hal_lib:3535:rt hm2/hm2_5i25.0: inconsistent Module Descriptor!
Nov 5 22:06:06 debian-cml2 msgd:0: hal_lib:3535:rt hm2/hm2_5i25.0: failed to parse Module Descriptor 5 of 8 gtag UART Transmit Channelint 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:
static int hm2_read_module_descriptors(hostmot2_t *hm2) {
int addr = hm2->idrom_offset + hm2->idrom.offset_to_modules;
for (
hm2->num_mds = 0;
hm2->num_mds < HM2_MAX_MODULE_DESCRIPTORS;
hm2->num_mds ++, addr += 12
) {
rtapi_u32 d[3];
hm2_module_descriptor_t *md = &hm2->md[hm2->num_mds];
if (!hm2->llio->read(hm2->llio, addr, d, 12)) {
HM2_ERR("error reading Module Descriptor %d (at 0x%04x)\n", hm2->num_mds, addr);
return -EIO;
}
.................................................................................................................
md->base_address = (d[1] >> 00) & 0x0000FFFF;
md->num_registers = (d[1] >> 16) & 0x000000FF;
md->register_stride = (d[1] >> 24) & 0x0000000F;
if (md->register_stride == 0) {
md->register_stride = hm2->idrom.register_stride_0;
} else if (md->register_stride == 1) {
md->register_stride = hm2->idrom.register_stride_1;
} else {
HM2_ERR("Module Descriptor %d (at 0x%04x) has invalid RegisterStride %d\n", hm2->num_mds, addr, md->register_stride);
return -EINVAL;
}
md->instance_stride = (d[1] >> 28) & 0x0000000F;
if (md->instance_stride == 0) {
md->instance_stride = hm2->idrom.instance_stride_0;
} else if (md->instance_stride == 1) {
md->instance_stride = hm2->idrom.instance_stride_1;
} else {
HM2_ERR("Module Descriptor %d (at 0x%04x) has invalid InstanceStride %d\n", hm2->num_mds, addr, md->instance_stride);
return -EINVAL;
}
md->multiple_registers = d[2];
..........................................................................
}
return 0;
}So in my case d[1] for UARTTTag would consist of:
BASE ADDRESS, NUMBER OF REGISTERS, STRIDES
UARTTDataAddr&PadT, UARTTNumRegs, x"10"
x"61" & x"00" , x"04" , x"10"
01100001 00000000 , 00000100, 00010000 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:
00010000 00000100 01100001 00000000Then these three make sense
md->base_address = (d[1] >> 00) & 0x0000FFFF; // = 0110000100000000
md->num_registers = (d[1] >> 16) & 0x000000FF; // = 00000100
md->register_stride = (d[1] >> 24) & 0x0000000F; // = 00000000But what about:
md->instance_stride = (d[1] >> 28) & 0x0000000F; // = 00000001
if (md->instance_stride == 0) {
md->instance_stride = hm2->idrom.instance_stride_0;then:
else if (md->instance_stride == 1) {
md->instance_stride = hm2->idrom.instance_stride_1; // 0x0000040:= 64 in decimal
}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 or Create an account to join the conversation.
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 <This email address is being protected from spambots. You need JavaScript enabled to view it.> 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 or Create an account to join the conversation.
> On 4 June 2012 22:48, Peter C. Wallace <This email address is being protected from spambots. You need JavaScript enabled to view it.> 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 or Create an account to join the conversation.
704 md->instance_stride = (d[1] >> 28) & 0x0000000F;
705 if (md->instance_stride == 0) {
706 md->instance_stride = hm2->idrom.instance_stride_0;
707 } else if (md->instance_stride == 1) {
if ((hm2_get_general_function_name(md->gtag)=="UARTTTag\0") || (hm2_get_general_function_name(md->gtag)=="UARTRTag\0"))
md->instance_stride=0x10;
else
708 md->instance_stride = hm2->idrom.instance_stride_1;
709 } else {
710 HM2_ERR("Module Descriptor %d (at 0x%04x) has invalid InstanceStride %d\n", hm2->num_mds, addr, md->instance_stride);
711 return -EINVAL;
712 }Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Nov 5 22:06:06 debian-cml2 msgd:0: hal_lib:3535:rt hm2/hm2_5i25.0: inconsistent Module Descriptor for UART Transmit Channel, not loading driverIt comes from git.linuxcnc.org/gitweb?p=linuxcnc.git;a...d0908c8f5b7e9d1#l762
762 if (hm2_md_is_consistent(hm2, md_index, version, num_registers, instance_stride, multiple_registers)) return 1;
763
764 HM2_ERR(
765 "inconsistent Module Descriptor for %s, not loading driver\n",
766 hm2_get_general_function_name(md->gtag)
767 );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 or Create an account 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 or Create an account to join the conversation.