exit of master/slave?

79 views
Skip to first unread message

Rob Hamerling

unread,
Oct 12, 2022, 1:36:57 PM10/12/22
to jallib

Hi guys,

Like similar changes in other places, I see in the Microchip datasheets that the terms 'master' and 'slave' are being replaced by 'host' and 'client'. Seems a positive and desirable change to me. I would like to suggest to follow Microchip in this for Jallib. I'm afraid this is not a simple operation. It is not only about file names, but also related 'includes' in samples. But it will also have effects on existing user programs!   What are your thoughts about this?

Regards, Rob

--
Rob Hamerling, Vianen, NL

Rob CJ

unread,
Oct 15, 2022, 5:31:54 AM10/15/22
to jallib
Hi Rob,

I agree that we should keep it in line with Microchip to keep consistency.

What we could do is the following:
  • Copy the current libraries using the new terminology, so for example spi_master_hw to spi_host_hw
  • Keep the current libraries for now but add something like _warn "This library will be deprecated, use spi​_host_hw. In this way the library can still be used and it gives the JAL users time to switch to the new library convention. We could keep the old libraries for one release and remove them from the next release.
  • Modify all current sample files so they use the new libraries.
Would this be a workable approach?

Kind regards,

Rob

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob Hamerling <robham...@gmail.com>
Verzonden: woensdag 12 oktober 2022 19:36
Aan: jallib <jal...@googlegroups.com>
Onderwerp: [jallib] exit of master/slave?
 
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/a87bb739-c320-a351-698e-3d5264087327%40gmail.com.

vasi vasi

unread,
Oct 15, 2022, 8:36:12 AM10/15/22
to jal...@googlegroups.com
This will not be a workable solution if you do not keep the old libraries at least in repository, even if you do not release them anymore. You don't know how many valuable projects are out there, is a real pain for new development teams to deal with old, deprecated firmware, written in an alien language that does not have support anymore... if you understand what I mean...



--
Vasi

Rob CJ

unread,
Oct 15, 2022, 10:34:00 AM10/15/22
to jal...@googlegroups.com
Hi Vasile,

We can keep the older version on GitHub. Not all files on GitHub are part of a release, that is determined by the file TORELASE on GitHub.

On GitHub you also find a directory called 'Casualties' where some older stuff is stored but you could also just remove it from the release (after some time).

Kind regards,

Rob

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vasi vasi <fun...@gmail.com>
Verzonden: zaterdag 15 oktober 2022 14:35
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] exit of master/slave?
 

Matthew Schinkel

unread,
Oct 15, 2022, 9:27:33 PM10/15/22
to jallib
Hi, how many files are affected?

Is someone offended by this? If someone is offended we can change it, else it seems like quite a lot will need to be changed and won't be backwards compatible.

Matt.

vsurducan

unread,
Oct 16, 2022, 12:31:25 AM10/16/22
to jal...@googlegroups.com
What if you put these in the library header:
-- alias master = host in Microchip datasheet, please be aware
-- alias slave = client in Microchip datasheet, please be aware

A good practice would be that at the end of any project, ALL libraries, the used compiler, schematic, PCB, machine files ( gerber excelon), all components datasheet used in the project, source code (well commented) and the hex file to be saved in two different places.


Oliver Seitz

unread,
Oct 16, 2022, 1:29:57 AM10/16/22
to jal...@googlegroups.com
Hi!

I agree to the later, but not to the first. (Well, could be done, but I don't think that is enough in the long run.)

Yes, if we stick to the new nomenclature, we break backwards compatibility. If we use our own fork of a namespace, we introduce new difficulties especially for newcomers to learn how to use JAL (or to read datasheets).

If I'm digging out old projects, and they do not compile, I'd have to make changes. If it's only changeing the obvoiusly differing library and function names, that's easily done.

I was quite deep into DOS programming back in the 1990's, and I saw a real lot of internal MS-Windows problems which had their origin in maintaining a 100% backwards compatibility to MS-DOS. MAC-OS was by far more stable, consistent and clean, by breaking backwards compatibility from time to time.

Greets,
Kiste 

Am Sonntag, 16. Oktober 2022, 06:31:28 MESZ hat vsurducan <vsur...@gmail.com> Folgendes geschrieben:


ZetWeeh

unread,
Oct 16, 2022, 4:20:02 AM10/16/22
to jal...@googlegroups.com

Hi

I suggested the same with aliases in a private mail to Rob.

Make an announcement on the website that within 2 (?) years the old libs cannot be used anymore.

And maybe it’s possible to make a message in the compiler like: deprecated; use newer library.

Than you have for some time two libs: the old one with the aliases (for example spi_master_hw.jal and the new one = spi_host_hw.jal).

Greetings,

Peter

 

Van: vsurducan
Verzonden: zondag 16 oktober 2022 06:31
Aan: jal...@googlegroups.com
Onderwerp: Re: [jallib] exit of master/slave?

 

What if you put these in the library header:

-- alias master = host in Microchip datasheet, please be aware

-- alias slave = client in Microchip datasheet, please be aware

 

A good practice would be that at the end of any project, ALL libraries, the used compiler, schematic, PCB, machine files ( gerber excelon), all components datasheet used in the project, source code (well commented) and the hex file to be saved in two different places.

 

On Sun, Oct 16, 2022 at 4:27 AM Matthew Schinkel <mattsc...@hotmail.com> wrote:

Hi, how many files are affected?

 

Is someone offended by this? If someone is offended we can change it, else it seems like quite a lot will need to be changed and won't be backwards compatible.

 

Matt.

On Saturday, October 15, 2022 at 10:34:00 AM UTC-4 rob...@hotmail.com wrote:

Hi Vasile,

 

We can keep the older version on GitHub. Not all files on GitHub are part of a release, that is determined by the file TORELASE on GitHub.

 

On GitHub you also find a directory called 'Casualties' where some older stuff is stored but you could also just remove it from the release (after some time).

 

Kind regards,

 

Rob

 

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vasi vasi <fun...@gmail.com>
Verzonden: zaterdag 15 oktober 2022 14:35
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] exit of master/slave?

 

This will not be a workable solution if you do not keep the old libraries at least in repository, even if you do not release them anymore. You don't know how many valuable projects are out there, is a real pain for new development teams to deal with old, deprecated firmware, written in an alien language that does not have support anymore... if you understand what I mean...

 

On Sat, Oct 15, 2022 at 12:31 PM Rob CJ <rob...@hotmail.com> wrote:

Hi Rob,

 

I agree that we should keep it in line with Microchip to keep consistency.

 

What we could do is the following:

  • Copy the current libraries using the new terminology, so for example spi_master_hw to spi_host_hw
  • Keep the current libraries for now but add something like _warn "This library will be deprecated, use spi_host_hw. In this way the library can still be used and it gives the JAL users time to switch to the new library convention. We could keep the old libraries for one release and remove them from the next release.
  • Modify all current sample files so they use the new libraries.

Would this be a workable approach?

 

Kind regards,

 

Rob

 

Rob CJ

unread,
Oct 16, 2022, 4:45:17 AM10/16/22
to jal...@googlegroups.com
Hi Oliver (Kiste 🙂),

We could indeed add an alias to the library like alias spi_host_hw is spi_master_hw and use spi_host_hw in all new sample files (and use that in all current sample files and libraries) so that people get used to it. 

In my ili9341 library I am using SPI (but am moving the initialization part of the spi interface to the sample file so still some changes are made to this library) and will use ili9341_spi_host in my library so the sample program has to define this alias.

Another thing we can do is mention that the library is no longer maintained (give a compiler warning when using it), make a copy of it to spi_host_hw and if there are any improvements needed, they will only be done in this new version. I know there have been changes in newer PICs that require an update of the SPI library but I did not yet find the courage to work on that.

BTW. In all the years that I am using JAL (since 2013) I have encountered only once that one of my projects did not compile with a newer version of Jallib which was a simple fix. I think there was a change in a device file (but am not sure). The older Jallib versions can still be downloaded from the download site.

Kind regards,

Rob

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens ZetWeeh <zet....@gmail.com>
Verzonden: zondag 16 oktober 2022 10:19
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: RE: [jallib] exit of master/slave?
 

Matthew Schinkel

unread,
Oct 16, 2022, 2:49:41 PM10/16/22
to jallib
I am ok with the change. Do as Rob suggested with aliases and warnings in the old library.

What libraries will change?

Matt.

Rob CJ

unread,
Oct 17, 2022, 1:42:13 PM10/17/22
to jallib
Hi Matt,

About 30 libraries should be changed that use spi master. I do not know how many sample files.

I would only make a new library and do not add any aliases. You either use the deprecated library with the term master or you use the new library with the term host.

BTW. I assume this will be the same for IIC master and slave.

Kind regards,

Rob



Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Matthew Schinkel <mattsc...@hotmail.com>
Verzonden: zondag 16 oktober 2022 20:49
Aan: jallib <jal...@googlegroups.com>

Zet Weeh

unread,
Oct 22, 2022, 12:13:51 PM10/22/22
to jal...@googlegroups.com
Hi
Maybe we can also change sdi and so on. I 
= input 
but pic or device?
I suggest:
Mosi = hoci (host out cliënt in)
and of course
Hico = host in cliënt out

Peter


Mijn spreuk: liever kort en goed dan te uitgebreid. 

Op 17 okt. 2022 om 19:42 heeft Rob CJ <rob...@hotmail.com> het volgende geschreven:



vasi vasi

unread,
Oct 22, 2022, 1:06:14 PM10/22/22
to jal...@googlegroups.com
Stupid Microchip. It is more safe to remain to old master/slave and when scanning for new devices or whatever, change host/client to old naming. As for me, I remain at the old master/slave and having entire world kiss my back goodbye!  Period!

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/4E97DAEF-EF62-4D9D-85C8-E42ED831D68C%40gmail.com.


--
Vasi

vasi vasi

unread,
Oct 22, 2022, 1:15:04 PM10/22/22
to jal...@googlegroups.com
Forked!
--
Vasi

Matthew Schinkel

unread,
Oct 22, 2022, 2:56:55 PM10/22/22
to jallib
I think we're going the wrong way with this whole thing.

I don't see how we are going to keep the new naming out of new files, and I hope we aren't planning to send nasty emails to everyone that puts the word slave in their lib/sample. That would be quite bad for Jallib. Instead of us changing everything, maybe we should only change this where microchip and other chip vendors have.

The reason for the change should be "to match the vendors wording". Not to remove it completely, because that can't be enforced due to freedom of speech and will prevent some from adding files to Jallib. The person making the library can name it as they please.

Can we list all libraries containing the terms master/slave, then note which are not matching the vendors wording?

Since microchip is using host/client for SPI, I think we should keep spi_master_hw.jal, but replace it's contents with only a few lines like:
include spi_host_hw
alias spi_master_hw is spi_host_hw

Some vendors still refer to it as spi master/host and some as spi slave/client. Therefore we should keep both a spi_host and a spi_master library.

Nobody owns Jallib, therefore nobody should enforce this new wording. Our policy should be "try to use the vendors wording, but it's up to the creator".

I think this solution should work better for everyone.

Peter, I don't think we'll be making any other changes to SPI naming, this seems to be enough change for now.

Matt.

vsurducan

unread,
Oct 23, 2022, 2:54:39 AM10/23/22
to jal...@googlegroups.com
I agree with Matt. I think this is a fake issue,
Perhaps Rob Hammerling needed to see you at work and plugged you in the socket. :)  ( deep respect for Rob, just an innocent joke)
One guy from Microchip was not attentive and changed the terms to sound good for his ears ( definitely his and not her, women are attentive).
I really like hoci and hico. :0) People with a deep sense of humor here.

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

Rob CJ

unread,
Oct 23, 2022, 4:22:26 AM10/23/22
to jal...@googlegroups.com
Hi all,

Agree. We coule makt it something gradual.

I started with the ili9341.jal library.

-- Define the interface alias for the ILI9341.
alias ili9341_spi_host is spi_master_hw


Kind regards,

Rob

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vsurducan <vsur...@gmail.com>
Verzonden: zondag 23 oktober 2022 08:54
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Re: exit of master/slave?
 

ZetWeeh

unread,
Oct 26, 2022, 4:48:47 PM10/26/22
to jal...@googlegroups.com

I read the reactions on my mail about hico/hoci: from adoration of women to freedom of speech.😊

 

I believe Microchip is very smart: don't wait till critics begin about master/slave:

but change it before. 🤔

Jal is going also from master/slave to host/client. When you do it: do it good.

Raspberry, Arduino (and so on) they all use MOSI/MISO and that has a reason.

 

Rob H. started this discussion also with a reason. Master/slave is an issue

in the world of this moment. Jal is part of this constant changing world.

And it is not important what a JAL-maker/volunteer thinks!

The future of JAL is important.

 

All kind of volunteers worked hard for JAL and it's not the intention that it's becoming a dull

old-fashioned IDE.

 

It's to easy to say: it's a lot of work for Rob J.

Rob J. has already made suggestions of changes. If he works it out he can send me the names of samples and I'll change them.

In this way all changes remains equal.

Together with new libs JAL remains up-to-date.

 

Peter 😎

 

PS. Who will help too?

Van: Rob CJ
Verzonden: zondag 23 oktober 2022 10:22
Aan: jal...@googlegroups.com
Onderwerp: Re: [jallib] Re: exit of master/slave?

 

Hi all,

 

Agree. We coule makt it something gradual.

 

I started with the ili9341.jal library.

 

-- Define the interface alias for the ILI9341.

alias ili9341_spi_host is spi_master_hw

 

 

Kind regards,

 

Rob

 

Rob CJ

unread,
Oct 27, 2022, 2:53:11 PM10/27/22
to jal...@googlegroups.com
Hi Peter,

The use of MISO and MOSI does not solve this for Arduino since it stands for Master In Slave Out and Master Out Slave In 🙁.

So Host and Client should be the terminolgy (until these termis become a problem ....)

We are still undecided if we should do this or not. As far as I see it now we have several options:
  1. Do nothing. Wait until some JAL user has problems with the terminology.
  2. Remove Master Slave from all libraries and sample files and change them to host/client. This will break current projects for JAL users that use SPI.
  3. Copy the libraries with master/slave to new libraries with host and client. Adapt all sample files to that and add a warning to the master/slave library that it will be deprecated (not determined when that will happen maybe when somebody has any issues with them) but also do not maintain these libraries anymore (no bug fixes).
Option 3 does not break anything (yet). And of course option 1 also doesn't.

Kind regards,

Rob


Van: jal...@googlegroups.com <jal...@googlegroups.com> namens ZetWeeh <zet....@gmail.com>
Verzonden: dinsdag 25 oktober 2022 23:56
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: RE: [jallib] Re: exit of master/slave?
 

Rob CJ

unread,
Oct 27, 2022, 2:54:23 PM10/27/22
to jal...@googlegroups.com
Hi Peter,

And in addition. This is also valid for IIC 🙁.

Kind regards,

Rob

Van: Rob CJ <rob...@hotmail.com>
Verzonden: donderdag 27 oktober 2022 20:53

Zet Weeh

unread,
Oct 28, 2022, 4:21:20 AM10/28/22
to jal...@googlegroups.com
Hoi Rob 

Of course Arduino had to solve the same problem sooner or later. 
I understand very well that IIC also use M/S. 
That’s why I going to help you if you will. 

Greetings Peter



Mijn spreuk: liever kort en goed dan te uitgebreid. 

Op 27 okt. 2022 om 20:54 heeft Rob CJ <rob...@hotmail.com> het volgende geschreven:



Matthew Schinkel

unread,
Nov 1, 2022, 10:08:51 PM11/1/22
to jallib
Hi, did anyone have any objections on what I had suggested in my previous message?

I think we should keep spi_master_hw.jal, but replace it's contents with only a few lines like:
include spi_host_hw
alias spi_master_hw is spi_host_hw

This way it will be backwards compatible, and we'll be able to slowly migrate to the new spi_host_hw.jal library.

If no objections I'll go ahead with this.

Matt.

Rob CJ

unread,
Nov 2, 2022, 9:22:48 AM11/2/22
to jal...@googlegroups.com
Hi Matt,

Fine by me.

Met vriendelijke groet,
Rob Jansen
From: jal...@googlegroups.com <jal...@googlegroups.com> on behalf of Matthew Schinkel <mattsc...@hotmail.com>
Sent: Wednesday, November 2, 2022 3:08:51 AM
To: jallib <jal...@googlegroups.com>
Subject: Re: [jallib] Re: exit of master/slave?
 
Reply all
Reply to author
Forward
0 new messages