Keeping it Simple

One think that’s been bobbing about at the back of my mind is making the code easy to customise – In particular the various components of the data signal. At present they are pretty much hard coded into the code for development, but going forwards I’m going to move away from that idea, so that if someone did not want to use any of the “standard” setups, they can amend the signal to cover whatever is needed.

The easiest way to do this would be to include an additional header/include file that only contains the definitions of what the magazine size is and what each byte will be. When compiled these would then be included in the code, without having to edit the code at all.

The actual values would be in the documentations, though it would also not be too bad to ad a comment section to the file with the same information, or at least a summary of the information as well.

Pretty much the format below:

#define magazine_size 30

#define signal_byte_1 01

#define signal_byte_2 00

#define signal_byte_3 00

#define signal_byte_4 00

#define signal_byte_5 00

//this would be a standard 1 hit damage shot with a magazine size of 30

With comments in the define file giving the value options. That way the only changes needed are in the HFA_Setup.INC or HFA_setup.H files to change the pewpew behaviour

If do implement a 2^nd mode switch (I.e. Kill/stun) also include

#define signal2_byte_1 02

#define signal2_byte_2 01

#define signal2_byte_3 00

#define signal2_byte_4 00

#define signal2_byte_5 00

This would be a stun shot with 5 minute duration.

So the full include/header file for a 30 shot magazine, 1 point no special damage alternate fire mode of 5 minute stun would be:

/*************************************************************

HFA_Setup.H – set the customisable data for the Heretik Forge/Arcturus

                                IR Emitter circuit. This enables anyone who is willing to

                                Customise the output for the circuits to go alongside

                                The “standard” setups that are ready and in the case

                                Of the C/Pic files already compiled into the Hex file

                                Ready to burn onto the chip

*************************************************************

Created: 19/9/19 by Ady: heretikforge@gmail.com

*************************************************************/

#define magazine_size 30

#define signal_byte_1 01

#define signal_byte_2 00

#define signal_byte_3 00

#define signal_byte_4 00

#define signal_byte_5 00

#define signal2_byte_1 02

#define signal2_byte_2 01

#define signal2_byte_3 00

#define signal2_byte_4 00

#define signal2_byte_5 00

Code & Legibility...

So.. As part of working on the Pic chips, I’ve been working on code based on the info in the datasheet* ready for when the new programmer arrives.

Just a simple thing to get the basics for generating the signal for the Arcturus emitters.

Actually, just setting it up to generate a single pulse width modulated signal, and calculations aside,
it’s actually fairly straightforward to do.

I’ve also been doing the same thing with the Microchip Code Configurator** to compare the code.  And I’ll admit, that based on the experience with the code configurator that it’s easy to setup the various bits & bobs of the chip with it.


HOWEVER it does not generate particularly easy to read code – For example, setting up a Pulse width modulated signal –
Takes a couple dozen lines of code if you include  the initial chip setup commands. Easy enough to read and comment.
The code configurator generated 12 FILES with a little bit of code in each – 6 source files and 6 header files. An absolute nightmare to read and make sense of as it’s jumping around through files in what feels like a totally unnecessary manner.

 

For me, that’s a HUGE negative as pretty much the first thing that was hammered in when I started coding way back was to make the code as understandable and easy to read as possible. And There have been many times I’ve been into code that is just horrible. Bad comments or no comments even less documentation and generally just a nightmare to work with.

 

So yeah…. That’s a thing that happened. And given that I plan to release it open source, legibility and ease of understanding is far  more important that saving a little time by using a wizard.

 

 

* I swear for a microcontroller datasheet is a misnomer. 500 pages is a tad more than a sheet if you ask me…

** Microchip code configurator or MCC is essentially a wizard to generate ready to use code tailored for the chip and desired settings.

That thumping noise? Thats me banging my head against a wall

Well, I’ll be the first to admit the pic/C isn’t going hugely smoothly so far.

The C side I’ve picked up (Re picked up as did C++ way back ??) as that’s easy enough.

 

The side I’m having well.. frustrations… with is the various peripherals and libraries for the XC8 compiler for the Pic.

In a nutshell, discrete libraries for the peripherals have been replaced with the MPLAB Code Configurator – which, I can understand in some ways as otherwise there are a LOT of libraries as you need to cover all the supported chips the code configurator is missing something important from Microchip. Straight forward examples and instructions on how to use the damn thing.

 

I’ve located some tutorials which will form the basis of what I need, as I know what I want the various peripherals to do and once it well.. ‘clicks’.. it’ll be straight forward, and it’ll click once I’ve wrapped my head around the code configurator as then I’ll be able to setup & code libraries for the particular chips to do what I want them to do.

And you can be sure I’ll be including the things in the open source release when it’s eventually ready for the Pic circuits.

 

I guess the main frustration is a lack of clear documentation for things like Serial communication via the Usart module and Modulating a PWM signal via the CCP – I know how to do the latter in theory due to getting it working on the picaxe – The bit I’ve not idea is getting the serial data to the USART module.

Building the signal is straight forward, as the relevant module has 2 inputs – it’s a case of setting one input to the pwm signal for the carrier, and then switching the other input between the PWM for the hit signal and the serial data.

 

In all honesty, once I’ve got my head around the serial data transmission/usart module it’ll be pretty much gravy from their on out.

 

Ok, so rant over 😊

 

In the meantime I will be updating the Picaxe based circuits for the previously mentioned updates and having more thoughts on the medic system – It’s meant to be pretty much optional, so why include too much on the sensors. The Timing can be done on the medic boxes themselves and then just zap the sensors to auto reset when it’s done – THAT can be done on the current picaxe based sensors as it won’t take a large amount of code/space and translated to Pics when that version is up and running.

Audio module wise, I’ve got the usb based modules, though the only datasheet I’ve located is in Chinese so I’m working with a somewhat ropey auto translated copy. It suggests that it needs a program to convert from Mp3 to .bin files and upload them to the module, BUT at the same time it’s using the same core chip as the sdcard based audio module so should be able to read mp3 straight off – the main difference seems to be the storage media (onboard memory versus microsdcard), well.. That and the onboard amp – 1W compared to 3W which could also be an issue.

Worst case with that is we stick with the existing modules, which isn’t the end of the world even if it does up the cost slightly for needing the microsdcards (Which are reusable though)