Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  

On 28/09/18 16:06, mngr wrote:


  

Il giorno venerdì 28 settembre 2018 15:10:04 UTC+2, Schooner ha
scritto:

   
On 28/09/18 13:21, mngr wrote:


  
edited from 0x2000 to
  0x3F00 and now the raspberry loads the
  hal_spi module. hal_spi.c should check the Pi
  version in a similar way to hal_gpio.c .
  


Well done.

There were no other Pi versions when it was written.

Would you like to submit a PR?
  

sure thing! 

I have just seen that after modifying naively
  BCM2835_PERI_BASE the chip select stops working.

there is some part of hal_spi that I don't understand: a
  very lot of costants in hal_spi.h are not used;
and https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_spi.c#L401
  it does something on GPIO23 and 24. for which raspberry
  version was it written?
  


It can only have been written for v1 or v2, probably not v2B given
its date of writing.
I have not heard anything of the guy who wrote it for some years
either.


  
 I see it is related to pin_out hal pin, but... how was it
  designed?






   Cut and paste the
hal_gpio.c code that version checks into hal-spi.c and test
that.
  

 
I only have rasppberry 3B on my desk, so I only can test on
  it.
  


That's fine, we  know it worked with earlier versions, if it can
detect a v3B and change the main base address accordingly
so that it works, it will be improved

If the BCM2835_PERI_BASE works, then leave as is.


  




 

   

  
Il giorno mercoledì 26 settembre 2018 12:33:31 UTC+2,
mngr ha scritto:

  
The cpuinfo information says BCM2835 for any
  raspberry version you can have, this helps with
  something in the kernel, the revision is the filed
  actually accurate.
The first version of RPi have the base address
  at 0x2000 from RPi 2 on it is at  0x3F00


hal gpio recognize this difference, hal_spi
  does not, I still have to run hal gpio, though,
  will do it in next days



https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf
  here is a BCM 2837 datasheet that shows all the
  addresses, I will try to correct them in next days


Other says to have a SPI driver for
  the 2710 (aka 2837) but it is hard to find the
  code, in case I will try to ask directly to them




Il giorno lunedì 24 settembre 2018 11:41:53 UTC+2,
Schooner ha scritto:

   Well,
despite what /proc/cpuinfo says, I don't see how
it can be a BCM2835 Soc.

The elinux hardware history (https://elinux.org/RPi_HardwareHistory)
clearly shows the v3 B has a BCM2037 and even if
you
were sold an almost identical v2 B purporting to
be a v3 B, it would have a BCM2036.

Looks like it is testing CS (chip select) to see
if it is in an active state and waiting until it
is?
Hence my question about whether SPI was
activated.
The most likely sources of the problem are
either that SPI is inactive or 
that whatever address *spi points to it does not
contain what is expected so the & test will
never result as expected.

This in turn makes one suspicious about what
will happen when the driver is attached to a
thread and started.
Will it work?
 

Re: [Machinekit] using hal_spi module

[mngr]

Il giorno venerdì 28 settembre 2018 15:10:04 UTC+2, Schooner ha scritto:
>
>
> On 28/09/18 13:21, mngr wrote:
>
> edited from 0x2000 to 0x3F00 and now the raspberry loads the 
> hal_spi module. hal_spi.c should check the Pi version in a similar way to 
> hal_gpio.c .
>
>
> Well done.
>
> There were no other Pi versions when it was written.
>
> Would you like to submit a PR?
>
sure thing! 
I have just seen that after modifying naively BCM2835_PERI_BASE the chip 
select stops working.
there is some part of hal_spi that I don't understand: a very lot of 
costants in hal_spi.h are not used;
and 
https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_spi.c#L401
 
it does something on GPIO23 and 24. for which raspberry version was it 
written? I see it is related to pin_out hal pin, but... how was it designed?


Cut and paste the hal_gpio.c code that version checks into hal-spi.c and 
> test that.
>
 
I only have rasppberry 3B on my desk, so I only can test on it.


 

>
>
> Il giorno mercoledì 26 settembre 2018 12:33:31 UTC+2, mngr ha scritto: 
>>
>> The cpuinfo information says BCM2835 for any raspberry version you can 
>> have, this helps with something in the kernel, the revision is the filed 
>> actually accurate.
>> The first version of RPi have the base address at 0x2000 from RPi 2 
>> on it is at  0x3F00
>>
>> hal gpio recognize this difference, hal_spi does not, I still have to run 
>> hal gpio, though, will do it in next days
>>
>> https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf
>> here is a BCM 2837 datasheet that shows all the addresses, I will try to 
>> correct them in next days
>>
>> Other  says to have a SPI driver 
>> for the 2710 (aka 2837) but it is hard to find the code, in case I will try 
>> to ask directly to them
>>
>>
>> Il giorno lunedì 24 settembre 2018 11:41:53 UTC+2, Schooner ha scritto: 
>>>
>>> Well, despite what /proc/cpuinfo says, I don't see how it can be a 
>>> BCM2835 Soc.
>>>
>>> The elinux hardware history (https://elinux.org/RPi_HardwareHistory) 
>>> clearly shows the v3 B has a BCM2037 and even if you
>>> were sold an almost identical v2 B purporting to be a v3 B, it would 
>>> have a BCM2036.
>>>
>>> Looks like it is testing CS (chip select) to see if it is in an active 
>>> state and waiting until it is?
>>> Hence my question about whether SPI was activated.
>>> The most likely sources of the problem are either that SPI is inactive 
>>> or 
>>> that whatever address *spi points to it does not contain what is 
>>> expected so the & test will never result as expected.
>>>
>>> This in turn makes one suspicious about what will happen when the driver 
>>> is attached to a thread and started.
>>> Will it work?
>>>
>>> It might be useful to try to get the hal_gpio demo running on the board 
>>> with DEBUG set and look at the output.
>>>
>>> Regards the args, that is peculiar.  Just ignore the print out.
>>> Look at hal_gpio.c for an example of how RTAPI_MP_STRING should appear, 
>>> and then you can see them being used in the later code.
>>> If there is any initialisation to be done it would normally be in 
>>> rtapi_app_main()
>>>
>>> You need to find someone who is up on bit twiddling on the v3 B and 
>>> check all the addresses and offsets with them.
>>> (Particularly the SPI_BASE offset, which may or may not vary between 
>>> models of Soc)
>>>
>>>
>>> On 23/09/18 20:35, mngr wrote:
>>>
>>> I am really sorry Schooner, I was excited about the findings...
>>> I actually don't know which args suits my setup, I looked in the source, 
>>> but I don't know how to find where they are used,
>>> I tried to scroll it all, but found no place that seems to use them.
>>> My board is a Raspberry Pi 3 model B  V 1.2 and attached you can find 
>>> the cpuinfo output
>>> Spi is enabled from raspi-config, and in /dev there is spidev0.0 and 
>>> spidev0.1
>>>
>>> Il giorno domenica 23 settembre 2018 19:35:25 UTC+2, Schooner ha 
>>> scritto: 

 OK, good there is some progress.

 You will probably find that whilst loaded, it may not work.

 That while statement is actually 
 while(!( *(spi + 0) & 0x0001)
 which is extremely specific and if something has changed or if SPI is 
 not enabled, it will hang forever.

 (gripe here, I have asked you 3 specific questions and you have not 
 answered any of them)


 On 23/09/18 18:01, mngr wrote:

 Thanks for the explanation about machinkit workings,

 I played with the stamps and found that it was blocking on
 while (!(BCM2835_SPICS & SPI_CS_DONE)); (Line 438)

 removing it halrun loads, now I will see if and what it writes. maybe I 
 will have to control the low level implementation... but now I know more 
 things.

 One more question, how does a hal module read the args? 


 Il giorno domenica 23 settembre 2018 17:47:44 UTC+2, Schooner ha 

[Machinekit] Re: new cnc cape

[Lang Gu]

Hi,kevin,
closed loop or semi-closed loop is hard for me.
So I chose the easy way---use open loop.
Thanks for  your advice,this is very helpful  for my future. 

在 2018年9月28日星期五 UTC+8下午10:13:44，Kevin Friesth写道：
>
> Hello, 
>
> One potential issue I see with your circuit design is that it doesn't seem 
> to have io inputs to allow use of encoders on all axis's which would 
> greatly enhance accuracy and repeatability for movements and actions. 
> Homing works for startup and such but it doesn't track potential movement 
> and positioning errors. ie 
> http://www.anaheimautomation.com/manuals/forms/encoder-guide.php#sthash.U7z4xbhg.dpbs
>
> Regards,
>
> Kevin
>
> On Thursday, September 27, 2018 at 9:36:55 PM UTC-5, Lang Gu wrote:
>>
>> Hello, everyone .
>>  I'm new drawing a cnc cape sch..
>> It‘s with 19 Optocoupler isolation  INPUT(11 INPUT use for MPG ,) and 16 
>> Non-Isolated 
>> 
>>  OUTPUT 
>> (use 74ls244 )
>> I use mcp23017 i2c bus  for 16 input(for limit --max/min/home etc.)..
>>
>> BUT， I'm not a electronic engineer 
>> 
>> ，so Dare not confirm right。。
>> Hope electronic engineer proofreading.
>>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: new cnc cape

[Kevin Friesth]

check out
https://www.nxp.com/products/analog/interfaces/ic-bus/ic-bus-controller-and-bridge-ics/fm-plus-i2c-bus-stepper-motor-controller:PCA9629PW

On Fri, Sep 28, 2018 at 9:13 AM Kevin Friesth  wrote:

> Hello,
>
> One potential issue I see with your circuit design is that it doesn't seem
> to have io inputs to allow use of encoders on all axis's which would
> greatly enhance accuracy and repeatability for movements and actions.
> Homing works for startup and such but it doesn't track potential movement
> and positioning errors. ie
> http://www.anaheimautomation.com/manuals/forms/encoder-guide.php#sthash.U7z4xbhg.dpbs
>
> Regards,
>
> Kevin
>
> On Thursday, September 27, 2018 at 9:36:55 PM UTC-5, Lang Gu wrote:
>>
>> Hello, everyone .
>>  I'm new drawing a cnc cape sch..
>> It‘s with 19 Optocoupler isolation  INPUT(11 INPUT use for MPG ,) and 16
>> Non-Isolated
>> 
>>  OUTPUT
>> (use 74ls244 )
>> I use mcp23017 i2c bus  for 16 input(for limit --max/min/home etc.)..
>>
>> BUT， I'm not a electronic engineer
>> 
>> ，so Dare not confirm right。。
>> Hope electronic engineer proofreading.
>>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: new cnc cape

[Kevin Friesth]

Hello, 

One potential issue I see with your circuit design is that it doesn't seem 
to have io inputs to allow use of encoders on all axis's which would 
greatly enhance accuracy and repeatability for movements and actions. 
Homing works for startup and such but it doesn't track potential movement 
and positioning errors. 
ie 
http://www.anaheimautomation.com/manuals/forms/encoder-guide.php#sthash.U7z4xbhg.dpbs

Regards,

Kevin

On Thursday, September 27, 2018 at 9:36:55 PM UTC-5, Lang Gu wrote:
>
> Hello, everyone .
>  I'm new drawing a cnc cape sch..
> It‘s with 19 Optocoupler isolation  INPUT(11 INPUT use for MPG ,) and 16 
> Non-Isolated 
> 
>  OUTPUT 
> (use 74ls244 )
> I use mcp23017 i2c bus  for 16 input(for limit --max/min/home etc.)..
>
> BUT， I'm not a electronic engineer 
> 
> ，so Dare not confirm right。。
> Hope electronic engineer proofreading.
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: new cnc cape

[Lang Gu]

Can your help me? 
If no error,i will make pcb & open scouce。 

在 2018年9月28日星期五 UTC+8上午10:36:55，Lang Gu写道：
>
> Hello, everyone .
>  I'm new drawing a cnc cape sch..
> It‘s with 19 Optocoupler isolation  INPUT(11 INPUT use for MPG ,) and 16 
> Non-Isolated 
> 
>  OUTPUT 
> (use 74ls244 )
> I use mcp23017 i2c bus  for 16 input(for limit --max/min/home etc.)..
>
> BUT， I'm not a electronic engineer 
> 
> ，so Dare not confirm right。。
> Hope electronic engineer proofreading.
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  

On 28/09/18 13:21, mngr wrote:


  
edited from 0x2000 to 0x3F00
  and now the raspberry loads the hal_spi module. hal_spi.c
  should check the Pi version in a similar way to hal_gpio.c
  .
  


Well done.

There were no other Pi versions when it was written.

Would you like to submit a PR?
Cut and paste the hal_gpio.c code that version checks into hal-spi.c
and test that.


  
Il giorno mercoledì 26 settembre 2018 12:33:31 UTC+2, mngr ha
scritto:

  
The cpuinfo information says BCM2835 for any raspberry
  version you can have, this helps with something in the
  kernel, the revision is the filed actually accurate.
The first version of RPi have the base address at 0x2000
from RPi 2 on it is at  0x3F00


hal gpio recognize this difference, hal_spi does not, I
  still have to run hal gpio, though, will do it in next
  days



https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf
  here is a BCM 2837 datasheet that shows all the addresses,
  I will try to correct them in next days


Other says to have a SPI driver for the 2710
  (aka 2837) but it is hard to find the code, in case I will
  try to ask directly to them




Il giorno lunedì 24 settembre 2018 11:41:53 UTC+2, Schooner
ha scritto:

   Well, despite what
/proc/cpuinfo says, I don't see how it can be a BCM2835
Soc.

The elinux hardware history (https://elinux.org/RPi_HardwareHistory)
clearly shows the v3 B has a BCM2037 and even if you
were sold an almost identical v2 B purporting to be a v3
B, it would have a BCM2036.

Looks like it is testing CS (chip select) to see if it
is in an active state and waiting until it is?
Hence my question about whether SPI was activated.
The most likely sources of the problem are either that
SPI is inactive or 
that whatever address *spi points to it does not contain
what is expected so the & test will never result as
expected.

This in turn makes one suspicious about what will happen
when the driver is attached to a thread and started.
Will it work?

It might be useful to try to get the hal_gpio demo
running on the board with DEBUG set and look at the
output.

Regards the args, that is peculiar.  Just ignore the
print out.
Look at hal_gpio.c for an example of how RTAPI_MP_STRING
should appear, and then you can see them being used in
the later code.
If there is any initialisation to be done it would
normally be in rtapi_app_main()

You need to find someone who is up on bit twiddling on
the v3 B and check all the addresses and offsets with
them.
(Particularly the SPI_BASE offset, which may or may not
vary between models of Soc)


On 23/09/18 20:35, mngr wrote:


  
I am really sorry Schooner, I was excited about
  the findings...
I actually don't know which args suits my
  setup, I looked in the source, but I don't know
  how to find where they are used,
I tried to scroll it all, but found no place
  that seems to use them.

My board is a Raspberry Pi 3 model B  V 1.2 and
  attached you can find the cpuinfo output

Spi is enabled from raspi-config, and in /dev
  there is spidev0.0 and spidev0.1


Il giorno domenica 23 settembre 2018 19:35:25 UTC+2,
Schooner ha scritto:

   OK, good
there is some progress.

You will probably find that whilst loaded, it
may not work.

That while 

Re: [Machinekit] using hal_spi module

[mngr]

edited from 0x2000 to 0x3F00 and now the raspberry loads the 
hal_spi module. hal_spi.c should check the Pi version in a similar way to 
hal_gpio.c .

Il giorno mercoledì 26 settembre 2018 12:33:31 UTC+2, mngr ha scritto:
>
> The cpuinfo information says BCM2835 for any raspberry version you can 
> have, this helps with something in the kernel, the revision is the filed 
> actually accurate.
> The first version of RPi have the base address at 0x2000 from RPi 2 
> on it is at  0x3F00
>
> hal gpio recognize this difference, hal_spi does not, I still have to run 
> hal gpio, though, will do it in next days
>
> https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf
> here is a BCM 2837 datasheet that shows all the addresses, I will try to 
> correct them in next days
>
> Other  says to have a SPI driver 
> for the 2710 (aka 2837) but it is hard to find the code, in case I will try 
> to ask directly to them
>
>
> Il giorno lunedì 24 settembre 2018 11:41:53 UTC+2, Schooner ha scritto:
>>
>> Well, despite what /proc/cpuinfo says, I don't see how it can be a 
>> BCM2835 Soc.
>>
>> The elinux hardware history (https://elinux.org/RPi_HardwareHistory) 
>> clearly shows the v3 B has a BCM2037 and even if you
>> were sold an almost identical v2 B purporting to be a v3 B, it would have 
>> a BCM2036.
>>
>> Looks like it is testing CS (chip select) to see if it is in an active 
>> state and waiting until it is?
>> Hence my question about whether SPI was activated.
>> The most likely sources of the problem are either that SPI is inactive or 
>> that whatever address *spi points to it does not contain what is expected 
>> so the & test will never result as expected.
>>
>> This in turn makes one suspicious about what will happen when the driver 
>> is attached to a thread and started.
>> Will it work?
>>
>> It might be useful to try to get the hal_gpio demo running on the board 
>> with DEBUG set and look at the output.
>>
>> Regards the args, that is peculiar.  Just ignore the print out.
>> Look at hal_gpio.c for an example of how RTAPI_MP_STRING should appear, 
>> and then you can see them being used in the later code.
>> If there is any initialisation to be done it would normally be in 
>> rtapi_app_main()
>>
>> You need to find someone who is up on bit twiddling on the v3 B and check 
>> all the addresses and offsets with them.
>> (Particularly the SPI_BASE offset, which may or may not vary between 
>> models of Soc)
>>
>>
>> On 23/09/18 20:35, mngr wrote:
>>
>> I am really sorry Schooner, I was excited about the findings...
>> I actually don't know which args suits my setup, I looked in the source, 
>> but I don't know how to find where they are used,
>> I tried to scroll it all, but found no place that seems to use them.
>> My board is a Raspberry Pi 3 model B  V 1.2 and attached you can find the 
>> cpuinfo output
>> Spi is enabled from raspi-config, and in /dev there is spidev0.0 and 
>> spidev0.1
>>
>> Il giorno domenica 23 settembre 2018 19:35:25 UTC+2, Schooner ha scritto: 
>>>
>>> OK, good there is some progress.
>>>
>>> You will probably find that whilst loaded, it may not work.
>>>
>>> That while statement is actually 
>>> while(!( *(spi + 0) & 0x0001)
>>> which is extremely specific and if something has changed or if SPI is 
>>> not enabled, it will hang forever.
>>>
>>> (gripe here, I have asked you 3 specific questions and you have not 
>>> answered any of them)
>>>
>>>
>>> On 23/09/18 18:01, mngr wrote:
>>>
>>> Thanks for the explanation about machinkit workings,
>>>
>>> I played with the stamps and found that it was blocking on
>>> while (!(BCM2835_SPICS & SPI_CS_DONE)); (Line 438)
>>>
>>> removing it halrun loads, now I will see if and what it writes. maybe I 
>>> will have to control the low level implementation... but now I know more 
>>> things.
>>>
>>> One more question, how does a hal module read the args? 
>>>
>>>
>>> Il giorno domenica 23 settembre 2018 17:47:44 UTC+2, Schooner ha 
>>> scritto: 

 Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user hal_spi.so 
 default iparms: ''
 Sep 23 15:03:17 realtimepi rtapi:0: 1:rtapi_app:701:user : hal_spi 
 initerr
 Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi 
 initdbg
 Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user 
 halg_xinitfv:90 HAL: initializing component 'hal_spi' type=1 arg1=0 
 arg2=0/0x0

 Since you haven't said where these extra prints are located, their 
 presence means nothing to me

>>> The module is obviously loading to a point but it does not look as 
 though the driver is getting any further than hal_init, which calls 
 halg_xinitfv()
 then is failing catastrophically

 You are loading with no args, are the defaults suitable for your board 
 / setup?
 Not that it looks that it gets that far, due the complete absence of 
 other error