Flowcode Support Board

I can't be sure on the details without checking on my installation and I'm not at all familiar with AVR.

Will take some more fiddling...

I tried changing the name - it still flicks to the AVR/attiny4313 file (even when I moved to the ARD directory) Changing the device name - fails on compilation (as does changing the compilation to include (chipalt) instead of (chip:l) - although I had to change this in FC compiler options - as it didn't seem to stick from the fcdx file.
I tried changing the GUID value too - but it still transfers to the attiny4313 file - but all is well as it keeps the settings.

Outsmarted by some XML

Could you try adding a property
file = "ATTINY4313_dev_board"
after the name =
(I can't remember if we need the .fcdx suffix)
And delete everything above <root>
Such that it's the first line.

Thanks Leigh...

Yes - that does the trick

Martin

The fcdx file...

A fun experiment....

I often bang on about using local variables instead of globals. (In a good way of course )

I tried a simple blinkie:

loop
pin = .on // pin is a single digital pin in properties.
.on = !.on // on is a local bool
end loop

This gives 952kHz with 20MHz clock.

loop
pin = on // same property
on = !on // now a global
end loop

Gives (only) 606kHz.

So - more readable code isn't the only benefit - locals are also faster (on AVR hardware at least) (and less RAM usage etc etc)

Using a write to PORTD - gives 1.5MHz for a local and 800kHz for a global.

Forgetting the variable and using PIND |= (1 << PD6); // Toggle the pin - gives 2.5MHz

Assembly language?

I feel a need for speed!!!

Martin

mnfisher wrote: ↑

Sun May 31, 2026 9:41 pm

I feel a need for speed!!!

The in-built port i/o functions in Flowcode have many compromises to account for all the different family and sub-family types and so are not necessarily optimised for speed. For example, I think TRIS is always set even though this may be unnecessary.

Flowcode's focus is mainly to make things easier for the user and that does come with some trade-offs in the generated code.

That said, Flowcode commands can be replace or customised with C / Assembly code, so optimisations can easily be made to time-sensitive parts of the project once it is up and running.

Yes - I thought the speed pretty good (better than the Arduino IDE )

Just having gone down the rabbit hole...

Hit another issue...

In my quest for ultimate speed (of pin toggling) - I tried the PWM component. This should allow generating PWM of up to 10MHz. However - it seems to ignore the period overflow setting and always generates 39.2kHz.

I also wrote a small C PWM setup. This allows the period overflow value to be passed in - and passing 0 does generate the 10MHz signal ***Fireworks***

The following has various disabled blocks - demonstrating (on pin PB2) - these various methods. All are commented out - except (here) the PWM (and I tried ChangePeriod and setting the overflow in properties - always 39.2kHz.... Is this the same for other chips?

The techniques other than PWM use PD6...

Martin

Thanks, Martin, for this workaround.

It looks like this chip has a special mode for PWM when that OCR0A register is set to zero, and the PWM CAL may not support it.

I'm not familiar with that chip and its datasheet has a lot of text relating to the various PWM modes, so it seems pretty complex to me.