Matrix user forums

RF_ASK Module Component

I have build a component to control a pair of modules - Receiver & transmitter on the 433MHZ frequency. I have included a step-by-step guide to build the component to control these modules.
This is all about how to make your own components, not about the actual modules themselves, although fun to use.

The step by Step Guide: The Project that created it: The actual component: All comments on how to improve the guide would be welcome.

Regards
Dave

Hello John,

Unbelievable!!

What an amazingly informative and processional looking tutorial, the quality and substance of what you have submitted is exceptional thank you so much

Matrix managers need to hang their collective heads in shame when they compare what they have done (or not) over to what you have produced. All we want is to use their amazing piece of software to its fullest and they don't give us the tools.

Right get your finger out and sort a book out for us LOL

A big collective hug from FC users
Matt

Hi Dave,

Many thanks - that is truly an awesome document and it looks like a lot of hours have gone into it. I have asked my colleagues to look at it and see if there are any improvements we can make to the document and to the component creation process in general.

I will PM you shortly with something as a token of our appreciation...

Regards,
Steve.

Hi Dave.

Thank you very much for this document(Tutorial) that was a big job you did , I truly believe it will help many people more than you can imagine.(including me)

I salute you for this effort

Hi Dave

A fantastic document, i tried to make a component in V6 a long time ago unsuccessfully. This document will be a great help i will have another go when i get the time.

thank you

Steve

Hi Dave
That's a great document.

Like Steve I've tried component creation and not had much success either.

I have those RF components myself, and have used them by programming them "the hard way", now I'll try working through your tutorial and see what happens.

Thanks again.

Hi all,

So you're aware, Dave's excellent document has prompted us to address this area and we're close to producing a tutorial which has a few additional short-cuts (that were added in v7.2) to make component creation even easier.

Leigh's been working on this and has produced the attached *draft* version so far. He's not in today, so early next week we'll look at finalising it and getting it published on the Wiki.

Once again, a big thanks to Dave for kickstarting this!

Regards,
Steve.

Hi All
This is great stuff Dave did a nice job and Matrix putting the cherry on the cake ,a big thanks to Dave and Steve for this.
This was an area where I always felt I can not handle in FC now I will give it a try again

One request though it is fine adding it to the wiki but please make it available as a .pdf download if possible

Hi Peter

as a work around If you use chrome you can save as a pdf, by going going to the 3 dots in the top left then print (or you could ctrl + p) you get to option to save as a pdf

Steve


:edit just seen Steve's post - thank you as peter says the icing on the cake

I don't know how to say this without sounding contrite and sarcastic (it is not my intention) but Steve I genuinely would like to thank you on giving a gratuity (presumably) to Dave for the work he has done, I don't know of any company who HAS done something like - especially unprompted.

Matt

Steve001 wrote: as a work around If you use chrome you can save as a pdf, by going going to the 3 dots in the top left then print (or you could ctrl + p) you get to option to save as a pdf

Hi Steve,
Thanks a million I will do this for sure

Hi Dave!

Really a nice and big project you have done, Thank's.

I have some of these rx and tx module. The output from them are very 'noisy'. Look forward to test your component. I Will use them togethers with my displayprojects.

You wrote in main page:

"Do not store this component in your main FC7 component folder. I would recommend you save the component somewhere else and use the 'Global Options' under the 'View' menu to set where FC7 should look for your components as shown here".

Do you still recommend to do this, can it destroy other component or conflict with these?

Br
Jorgen

jgu1 wrote:Do you still recommend to do this, can it destroy other component or conflict with these?

The reason to store components in a separate folder is to make sure they do not get lost when you upgrade flowcode. If you store anything in a folder where flowcode is installed it might be deleted during upgrade.

Hi Jorgen

There are several reasons to keeping what components are developed in a separate folder, as well as those suggested by kersing. It is necessary to help identify what components are still under development as shown below:-

You have the option to declare the status of the new component before it is exported to the location of your choice as shown Then, when you run FC7, you will notice that the component you have available in the list, what status is has by its icon used Its just another very important feature that FC7 has available.

Not only that, but imagine if several users are helping to develop a devices functionality. Only when it is accepted as finished would you promote its status and maybe accepted as finished would you add it to any permanent library.

Regards
Dave

Hi Dave and Kersing!

Thank's for the explanation. I do as you recommend.

Br Jorgen

Here is an updated/expanded version of the component creation getting started guide...
I've tried to keep it to the minimum basics.
So all of the previously mentioned tricks, tips and additions of this thread also apply.

Hi LeighM

I have read your tutorial, with great interest and I found it very enlightening. I am hoping to gain further insight as to how best go about creating my own FC7 components. Some of the techniques you have used do not always seem to work for me on my system, but still I will persevere. I think its a work-flow/procedural thing.

I have spent the last few days experimenting with the creation of a gLCD display, but with limited success followed by failure. I have posted the problems/successes I have had with my other post.

I only wish there were more tutorials to help myself and others master the dark art and mysteries of FC7 component creation.
However, as before, if I could get the gLCD component to work, another tutorial maybe!

Best Regards
Dave

Hi Dave, and Leigh,
Thank you both for your very informative and interesting tutorials on component creation.
That has inspired me to follow Leigh's Tutorial (Dave's is great, but I already have a LM75B)
After using the newly created LM75B I can confirm there is enough information for a working component to be created.
Results from temperature sensor: Note: Resolution = 0.5C
Both Flowcharts used to Create component and test component are very much work in progress.
If anyone has a LM75A/B and want to create component and get it working on hardware, I'm happy to post flowcharts.


Martin

Hi All,

Firstly I have to say that documents posted in this post are of great help thank everyone who contributed here. I'm relatively new FC user and I'm surprised of lack of comprehensive documentation for the product. I really enjoy using the product but discovering and using (new to me) features is a real struggle because of lack of documentations. Product support based on user forum is a bit not professional and perhaps OK if the product is free, but if you pay thousands of dollars there should be a better way. On line support (when you click on help) provides basic information which is usually already available on the FC screen just rewritten and put on a WEB page. Often there is nothing that may help to explain 'what', 'how' and 'way'. I guess I become in last few months an advanced user and really I'm looking for an advanced user manual and information, but there is no such thing.
Now when I got this off my chest, I can ask the question:
I'm working on TCA6408A component (I2C GPIO expander). Hopefully, I will get it all going and I will be happy to share all with you.
Apart from the standard I2C interface (which I can use the CAL-I2C component), I need to introduce two additional pins 'Reset' and 'Interrupt' and wrap some logic to emulate actual chip logic and also enable successful simulation. To fully define pins I need information about how to define the hardware property of the pin so the system can generate a define for my pin properties. One pin needs to be an Input and second Output. For SDA and SCL this is done by CAL but I can't find any source of information how to do it 'manually'. Could somebody provide details (and list of all applicable parameters and syntaxes) in order to configure 'Generate a define for the property'?

Thenks,
Igor

Hi Igor

Great looking component you are working on. I am no expert, but if I understand correctly from the illustration you have for the Property Variable you are using, what you are attempting to do is control two pins for controlling the functionality of the component. This is achieved within the code of the component.
Property Variable - will allow you to reference the property in the code following the same syntax rules as a variable name
Visible - is it visible to the user when the component is exported or greyed out
Writable - if the user can write to the property or is it fixed
Generate a define for the property - determines if FC7 will generate a define in the downloadable code

So, if you wish to control either pin within a particular Macro, the variable could be used to either input/output data using the same methods as you would in any FC7 project. An example of output control is shown on page 8 of the LCD tutorial. Not sure if that is much help for you.

Regards
Dave

Hi Dave,

I agree with you and this is exactly what I will do. The pins value (as variables) can be directly accessed in 'code' making the FC flowcharts.
Why I so much like FC is that takes away all abstraction from designing a microprocessor codes (and it is one of main FC features). We can be focused on designing actual algorithm instead taking care how to talk to our connected hardware. In all other methods designing the software for MCU we deal with 'components' on the very abstract level, as a bunch of header files and hopefully also some pre-designed functions. Instead, in FC we select the MCU chip (a target) and then everything is done in the background. The components provide definitions how the pins will be configured on the target, is it analogue or digital only input or bidirectional and so on. Some MCUs also have the ability to route the pins to internal hardware functionality. This is also created via FC component interface. But none of this is by a miracle.
There is a target MCU configuration file which contains all information about the MCU capability, so once we select it our component will 'offer' different sets of configuration, including pins. You can see for I2C pins on some MCU, if you select a 'CHANNEL", it will offer in some case software only, in another case only Channel1 but on larger MCU we will see also Channel2. Depending on MCU model we will be able to select pins connections, and sometimes this will be predefined and locked out for editing. To have this working we need to define our pins property (for pins which are not already linked to any other (sub) components).
So I do not think that I can just ignore the missing configuration since I'm not sure how the pin is configured. The simulation would work (as it will use the variable only), but when I try to compile the code for the target this will be missing. I could use some component as sub component like a switch and then use the pin assignment as for my component, but in the creation of my component I need to do much more than just a switch or LED.
Even when we select simple LED components, and attached to the pin on MCU this will provide configuration for the MCU config register for the particular pin. If you look into any MCU datasheet you will see that the most of the pages are describing the configuration registers. This is what must be configured in order that the physical chip works. When we do pure simulation we can ignore this fact (not that is then a real simulation) but functionality will work, since we build components which suppose to be available across various MCU (targets). From the surface when we select the pin which we use, we do not only create the physical link by doing this, the FC in the background creates all required for this link to work when it comes to the MCU configuration. This was always the hardest part. Microchip IDE introduced just recently a CCP which provide a graphic interface very similar how we do define pins on our components. The only difference is that FC does this with much more intuition and on right side, not on MCU but on the component in the exact way how we will do our PCB schematic. This to me is the logical way and why I so much appreciate the 'FC way' of doing things.

Maybe my point of view is incorrect and I missing something, but in another hand, the configuration field in pin property confirm my suspicion.
The setting is there I just don't know what to enter into it.

I hope somebody knows.

Regards,

Igor

Hello Igor,

Hopefully I can help a bit here.

For simple components using simple digital inputs/outputs or analogue inputs you can simply create a property of the right type (single analogue/digital pin) and then reference this in a calculation icon.

For more advanced components such as UART/SPI/I2C/PWM etc you would start with the CAL component from the Tools component menu and simply expose the channel/pin/remap properties shown there. This then brings through all the software/channel1/channel2 functionality and also the pin manipulations such as disabling user editing for hardware channels when remap is not available. It also brings through all the behind the scnenes functions to for example send and receive bytes on the bus. This allows the CAL component to do all the work and allow you to get on with making a new component.

This wiki page gives an overview of the property exposing as well as some tricks to make sure you expose all the relevent properties. e.g. the hidden remap properties.
https://www.matrixtsl.com/wikiv7/index. ... t_Features

Hi Ben,

Benj wrote:For simple components using simple digital inputs/outputs or analogue inputs you can simply create a property of the right type (single analogue/digital pin) and then reference this in a calculation icon.

Could you please explain me a mechanism which will configure MCU chip when is compiled for real physical MCU?
I still do not understand how this configuration miracle is working? If I choose a 'single digital pin' how the system knows if this is input or output or open collector IO? If I need dynamically to changed pin direction by component code what I do? Bottom line is that I may need to be able to change this property during code execution; such as one wire interface like component DHT11. Is it possible that you can provide a 'source' for the FC project for the creation of the DH11. This will likely provide some information. I know that the DH11 is working in real hardware world because I have it running here on my table.

Could you please dig out the specifications for the 'Generate a define for the property' field? There are a Name expression field and Value expression field.
Could you please send me a document which defines this expression? An expression like this '$(type)_$(module)_$(variable:u) may be what I'm expecting that will define the hardware configuration of the MCU pins for actual chip programming. Like 'type' may be 'Input', 'Output' or 'HiZ'?
Or perhaps this may define the variable so the configuration can be changed dynamically?

I would really appreciate if you can put some light on this feature?

Regards,
Igor

Igor,

The defines do not do anything to configure a pin. It literally generates a text string definition (in the #define C sense of the word) of the property. I've created several components over the past years and rarely need to use the define.

If you want to use a pin for I/O you can set it to a digital/analogue pin as Ben mentioned. Then if you want to use it you just need to use a calculation icon where you enter to read the state of the pin. At that point Flowcode will generate the code to set the pin to input, read the pin and (re)set it to the state it had before the input. Like wise for output generates code to set the pin to output, and set the level. At that point the pin will stay an output pin. (Until you use it for an input operation).

Best regards,

Jac

Hi Jac,

thank you for the quick reply.
I will try. I will have my hardware board at the end of this week ready and see if I can get my peripheral component working correctly.
I just wondering how this works when we have multiple components sharing the same MCU pin, some may be inputs some outputs (at the same time) how microprocessor can determine? Perhaps the pin port direction is locked to last MCU use? So if this is the case then the PIN property is actually a CAL component which has hidden code loaded to the MCU, which dynamically configures MCU pin TRIS? I still do not know how we control pool-up resistor ports? I guess this answer can be provided only by Matrix guys. Here is a topic example https://learn.mikroe.com/ebooks/picmicr ... /io-ports/ the TRIS registers configuration is where I'm not sure how the FC is handling.

Do you by any chance know how I can define in FC for the bus type of the pin (one which is sinking only, needs the pool up resistor never is the source)? Do I need to use the port in such way so I write to port only if I have '0' and if I have '1' i just do nothing?

Regards,
Igor