Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 00:18 04 Dec 2021 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : CSUB Request... anyone?

Author Message
CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1686
Posted: 08:57am 19 Nov 2021
Copy link to clipboard 
Print this post

Morning forum, you are all well I hope.

I have only fundamental C skills (I can follow a bit of code) and Zero MX/MZ/ARM assembler skills.

One thing I always thought MMBasic lacked is a built-in Swap statement.

I have a bit of code that spends ages inside some nasty maths and does thousands of swaps of Integers and Floats.

Timing shows that swapping with MMBasic code is a major bottle-neck - doubly so if you make it a Sub (which looks nice).

Is there some kind soul out there who fancies knocking up (what I imagine would be) a tiddly CSUB for Integers (SwapI) and another for Floats (SwapF) on a Mk2 ('170 based)?

I looked in the C modules folder with the disty and searched this forum and was really surprised this seems to have dropped through the net.

Let me be clear; I do not need examples of how to do this in MMBasic. It is a speed thing at this point, hence the request for a CSUB. There is another reason for it being a CSUB and not an addition to MMBasic for MicroMites (even tho' I think the command table is full and so very unlikely) - I am stuck in the 5.0408 bubble because of changes that happened that break a big project I have (saved variables wiped on upload of new prog).

I have been thinking how this might work, swapping pointers would undoubtedly be very fast but would that break Arrays if I had something like:

Swap x,a(22)

It doesn't need to be smart - I am happy that if I try to swap Ints, Floats, Consts and absolutes with each other I break stuff - that's on me.

I have nothing to offer but credit in the code, kudos and my eternal gratitude.

thanks in advance
Edited 2021-11-19 18:59 by CaptainBoing
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 5460
Posted: 09:27am 19 Nov 2021
Copy link to clipboard 
Print this post

Are floats single or double precision in the version you are using?
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 5460
Posted: 09:31am 19 Nov 2021
Copy link to clipboard 
Print this post

Assuming single precision (untested). If double precision use swapi for both

'
CSub swapi
   00000000
   8C820000 8C830004 8CA60000 8CA70004 AC860000 AC870004 ACA20000 03E00008
   ACA30004
End CSub
'
CSub swapf
   00000000
   8C820000 8CA30000 AC830000 03E00008 ACA20000
End CSub
'
 
CaptainBoing

Guru

Joined: 07/09/2016
Location: United Kingdom
Posts: 1686
Posted: 09:52am 19 Nov 2021
Copy link to clipboard 
Print this post

Aww. you are a star Peter - thanks a million.

The target platform is the humble 32MX17 Mk2 (Single precision) so this really helps

and such quick response. I will do some testing today to see the speed increase.

Perhaps these are worthy of including in the Embedded CSUBS folder of the distribution?

really, thanks once again.

EDIT:
amazing - has shaved 50+mS off a single encrypt/decrypt cycle with a moderate string.

This has made the difference between "hardened and usable" (proper encryption) and "compromised but works" (simple rolling XOR)
timer=0
a$=UnRC4$(RC4$("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"))
? timer
? a$


(with SwapI)
> RUN
459
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
> RUN
459
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
>

(with MMBasic Swap)
> RUN
515
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
> RUN
515
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
>

Edited 2021-11-19 20:27 by CaptainBoing
 
flasherror
Regular Member

Joined: 07/01/2019
Location: United States
Posts: 66
Posted: 12:05pm 19 Nov 2021
Copy link to clipboard 
Print this post

Shamelessly piggybacking another request here:

Any chance of a CSUB for calculating CRC16/32 on MX170?

CRCs are slow to compute in Basic and in a situation where a node must check CRC of a received message before processing, in some cases the CRC takes too long and causes "receiver node reply timeout" because the receiver is still computing the CRC before it can process and send a reply. MX170 is slower than more modern hardware but even other versions (Picomite/ARMmite) could benefit from "faster than basic" CRC generation.

Best would be if different CRC types could be calculated via CSUB
See list at
https://reveng.sourceforge.io/crc-catalogue/16.htm#crc.cat-bits.16
and
https://reveng.sourceforge.io/crc-catalogue/17plus.htm#crc.cat-bits.32
Edited 2021-11-19 22:06 by flasherror
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 952
Posted: 12:56pm 19 Nov 2021
Copy link to clipboard 
Print this post

What CRC ? There are several 16 bit and 32 bit CRC's. Are you looking for a generic algorithm (plug in your poly, seed, and parity ?).

I think the most common ones discussed on this forum are CRC16-CCITT and MODBUS CRC (CRC16-IBM). For CRC32 there is only one commonly used algorithm.
If nothing goes right ... turn left
 
Mixtel90

Guru

Joined: 05/10/2019
Location: United Kingdom
Posts: 1196
Posted: 01:38pm 19 Nov 2021
Copy link to clipboard 
Print this post

The trouble with CRCs is that if you are trying to talk to a device that uses them then you have to sort out what they are using. Just because you can talk to one thing doesn't mean the next one will work.  :(
-- Mick

Zilog Inside! nascom.info for Nascom & Gemini
 
flasherror
Regular Member

Joined: 07/01/2019
Location: United States
Posts: 66
Posted: 03:33pm 19 Nov 2021
Copy link to clipboard 
Print this post

  Volhout said  What CRC ? There are several 16 bit and 32 bit CRC's. Are you looking for a generic algorithm (plug in your poly, seed, and parity ?).

I think the most common ones discussed on this forum are CRC16-CCITT and MODBUS CRC (CRC16-IBM). For CRC32 there is only one commonly used algorithm.


Can either have common CRCs or generic (pass CRC params) versions, I'm not that picky.
Edited 2021-11-20 01:33 by flasherror
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 5460
Posted: 04:08pm 19 Nov 2021
Copy link to clipboard 
Print this post

The captain's request was trivial. Multi-type CRC calculation is far from trivial. I'm not interested in looking at it and CSUB engineers are few and far between so I suspect you would need to get stuck in yourself if it is something you want
Edited 2021-11-20 19:45 by matherp
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 2534
Posted: 12:10pm 20 Nov 2021
Copy link to clipboard 
Print this post

  flasherror said  CRCs are slow to compute in Basic and in a situation where a node must check CRC of a received message before processing, in some cases the CRC takes too long and causes "receiver node reply timeout" because the receiver is still computing the CRC before it can process and send a reply.

Do you calculate the CRC as each part (I guess byte) of a received message arrives?

If not, try it :)

It means you add a small overhead per byte rather than a sudden long delay.

John
 
Mixtel90

Guru

Joined: 05/10/2019
Location: United Kingdom
Posts: 1196
Posted: 12:28pm 20 Nov 2021
Copy link to clipboard 
Print this post

The best way to calculate CRCs is probably in hardware as they are shift-intensive. If you have plenty of room for a long table then lookup is the quickest way if you are working in software.

Microchip do a couple of application notes (AN730, AN1148) on generation and checking of CRCs.
-- Mick

Zilog Inside! nascom.info for Nascom & Gemini
 
Turbo46
Guru

Joined: 24/12/2017
Location: Australia
Posts: 820
Posted: 01:34pm 20 Nov 2021
Copy link to clipboard 
Print this post

  Quote   If you have plenty of room for a long table then lookup is the quickest way if you are working in software.


There is a MODBUS CRC routine Here using the table lookup method. Calculating the table during initializing saves space compared to READ/DATA statements. Using the lookup table method is about 10 times faster than the byte by byte method.

Bill
Keep safe. Live long and prosper.
 
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2021