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 0x20000000 from RPi 2 on it is at 0x3F000000
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 <https://ultibo.org/wiki/Unit_BCM2710> 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) & 0x00010000) >> 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 >>> init!!!!err >>> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi >>> init!!!!dbg >>> 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 or info messages >>> >>> The insmod error is completely non specific, so doesn't help, may just >>> be picking up the last return value. >>> >>> What is the output from /proc/cpuinfo and what version etc is your Pi? >>> >>> >>> >>> On 23/09/18 16:12, mngr wrote: >>> >>> Attached. >>> >>> In the log you can see the message I added in the hal_spi rtapi_app_main. >>> >>> pi@realtimepi:~ $ halcmd loadrt hal_spi >>> <commandline>:0: insmod failed, returned -1: >>> rtapi_rpc(): reply timeout >>> See /var/log/linuxcnc.log for more information. >>> pi@realtimepi:~ $ halcmd show all >>> halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28 >>> -dad21114744a): rtapi_rpc(): reply timeout >>> >>> E: 18-09-23 15:04:20 dangling 'DEALER' socket created at hal/utils/ >>> halcmd_rtapiapp.cc:281 >>> >>> >>> Il giorno domenica 23 settembre 2018 16:43:25 UTC+2, Schooner ha scritto: >>> >>>> >>>> On 23/09/18 15:16, mngr wrote: >>>> >>>> >>>> >>>> Il giorno domenica 23 settembre 2018 15:34:58 UTC+2, Schooner ha >>>> scritto: >>>>> >>>>> It's not about doubt >>>>> cat /proc/cpuinfo >>>>> will tell you whether you have BCM2835 >>>>> >>>> >>>> Thanks didn't know about that! on the rpi is written 2837, bit cpuinfo >>>> says 2835! >>>> So at least the part that writes in the SPI registers should work. >>>> >>>> I tried to add some debug message in hal_spi rtapi_app_main function, >>>> but I don't see them anywhere, I have exported DEBUG=5, and maximized the >>>> DEBUG value in the ini file. I am looking in /var/log/linuxcnc.log and in >>>> the terminal output. >>>> I have tried with different msg types >>>> >>>> rtapi_print_msg(RTAPI_MSG_ERR, ": hal_spi init!!!!err\n"); >>>> rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi init!!!!dbg\n"); >>>> rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi init!!!!all\n"); >>>> >>>> >>>> There are plenty of error messages in the driver already. I did not >>>> see any in the log however which makes me >>>> suspect it was never loaded. >>>> If insmod errors it should say why however and that was not in there >>>> either. >>>> >>>> Instead of complicating things with loading a non working config, just >>>> to load the driver, try this in a terminal on your Pi >>>> >>>> sudo > /var/log/linuxcnc.log (you may have to run this a root, it >>>> should zero the log) >>>> DEBUG=5 realtime restart >>>> halcmd loadrt hal_spi >>>> halcmd show all >>>> halrun -U >>>> >>>> That should give you a short log and if it errors loading hal_spi will >>>> be easier to trace through >>>> >>>> In addition to the log do >>>> >>>> dmesg | tail > dmesg.log >>>> >>>> and attach that log too >>>> >>>> >>>> If you do and the driver should work, we can try to find out why it >>>>> isn't. >>>>> >>>>> If you don't, what the differences are from the BCM2837 for example, I >>>>> have no idea >>>>> >>>>> I am guessing you are trying to generate steps using the SPI, that is >>>>> an area outside my experience >>>>> but there seems to be quite a bit about it on the RPi forums >>>>> >>>> >>>> Actually, I tought that hal_spi is used to write something to a MCU >>>> that will control the motor generating steps. >>>> I think it sends the commanded velocity and the MCU updates the PWM. >>>> I am not sure of those things, though >>>> >>>> On 23/09/18 13:50, mngr wrote: >>>> >>>> >>>> >>>> Il giorno domenica 23 settembre 2018 13:41:42 UTC+2, Schooner ha >>>> scritto: >>>>> >>>>> The log does not show what your earlier email showed, there is not >>>>> mention of an error from insmod >>>>> >>>>> I think you need to get right back to basics. >>>>> >>>>> This driver was written 5 years ago and is specific to the BCM2835 chip >>>>> It can only have been meant to support Pi v1 & v2 and maybe not all of >>>>> them, as they kept changing versions and hardware, >>>>> because nothing of a higher version had been released then >>>>> >>>>> Does this driver support your Pi? >>>>> >>>> >>>> In case of doubt I gave a look to wiringPi, it calls ioctl and >>>> write/reads from /dev/spidev. >>>> Is calling that syscall from a hal driver a sane thing to do? (It is >>>> for example used here >>>> <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_p260c.c> >>>> ) >>>> >>>> >>>> >>>>> Regards DEBUG, the ini file bit was explained by the text you deleted >>>>> from yours. >>>>> It takes a hexidecimal number up to 0x7FFFFFFF, the output is to >>>>> terminal and the output is from NML messaging >>>>> >>>>> The exported DEBUG=5 is the debug setting for logging and relates to >>>>> the rtapi system, not NML >>>>> >>>> >>>> Thanks for the explanation, Schooner >>>> >>>> >>>>> On 23/09/18 11:07, mngr wrote: >>>>> >>>>> >>>>> >>>>> Il giorno venerdì 21 settembre 2018 16:44:50 UTC+2, Schooner ha >>>>> scritto: >>>>>> >>>>>> You are not running with DEBUG=5 >>>>>> >>>>> >>>>> I edited DEBUG = 5 in ini file(in EMC section), nothing changed, then >>>>> I exported DEBUG=5 in bash. what is the difference? what is the deBUG >>>>> setting in the ini file for? >>>>> >>>>> Attached you can find the ini and the hal file, I edited the CRAMPS >>>>> configuration, basically removing everything relative to the PRU, and >>>>> adding loadrt hal_spi in CRAMPS.hal (and leaving one only axis) >>>>> linuxcnc_old.log is everything before adding loadrt hal_spi. >>>>> linuxcnc.log is the execution with loadrt hal_spi and termila_output >>>>> shows what has been written, I attached it because it talks about >>>>> rtapi_rpc(): reply timeout, that is not mentioned in the log >>>>> >>>>> pi@realtimepi:~ $ uname -a >>>>> Linux realtimepi 4.14.66-rt40-v7 #2 SMP PREEMPT RT Mon Sep 17 >>>>> 21:15:46 UTC 2018 armv7l GNU/Linux >>>>> >>>>> >>>>> >>>>> >>>>>> Do so and your linuxcnc.log will have info as to what failed. >>>>>> >>>>>> Also as I said in my last reply, it does not look as though you have >>>>>> a realtime kernel, irrespective of what you have named your pi. >>>>>> >>>>>> On 21/09/18 15:31, mngr wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I am sorry to post another noob question here, but, >>>>>> >>>>>> I am trying to use the hal module hal_spi, shortly I tried with >>>>>> loadrt hal_spi >>>>>> in the hal file, but >>>>>> CRAMPS.hal:15: insmod failed, returned -1: >>>>>> rtapi_rpc(): reply timeout >>>>>> See /var/log/linuxcnc.log for more information. >>>>>> >>>>>> in the log >>>>>> Sep 21 14:22:09 realtimepi msgd:0: startup pid=5979 flavor=posix >>>>>> rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516 >>>>>> version=unknown >>>>>> Sep 21 14:22:09 realtimepi msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0. >>>>>> 0 atomics=gcc intrinsics libwebsockets=2.0.3 >>>>>> Sep 21 14:22:09 realtimepi msgd:0: configured: sha=b87920504 >>>>>> Sep 21 14:22:09 realtimepi msgd:0: built: Sep 18 2018 16:43:17 >>>>>> sha=b87920504 >>>>>> Sep 21 14:22:09 realtimepi msgd:0: register_stuff: actual hostname as >>>>>> announced by avahi='realtimepi.local' >>>>>> Sep 21 14:22:09 realtimepi msgd:0: zeroconf: registering: 'Log >>>>>> service on realtimepi.local pid 5979' >>>>>> Sep 21 14:22:10 realtimepi rtapi:0: rtapi_msgd went away, exiting >>>>>> Sep 21 14:22:10 realtimepi msgd:0: zeroconf: registered 'Log service >>>>>> on realtimepi.local pid 5979' _machinekit._tcp 0 TXT >>>>>> "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" >>>>>> "instance=b9c730a2-bda9-11e8-bcc3-b827eb4bcf42" "service=log" >>>>>> "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a" >>>>>> >>>>>> I tried launching machinekit without it and adding it later using >>>>>> halcmd loadrt hal_spi, but with similar results >>>>>> >>>>>> >>>>>> should I give it some arguments? I don't know how to understand how >>>>>> to write them from the code... >>>>>> Maybe the module is old and has lost some compatibility? >>>>>> >>>>>> right now i am executing from >>>>>> Linux realtimepi 4.14.69-v7+ #1141 SMP Mon Sep 10 15:26:29 BST 2018 >>>>>> armv7l GNU/Linux >>>>>> Debian Stretch, Machinekit compiled from source >>>>>> maybe should I explicit the path to hal_spi? >>>>>> >>>>>> mngr >>>>>> -- >>>>>> 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+...@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+...@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+...@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+...@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+...@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+...@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+...@googlegroups.com <javascript:>. > 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.
