![]() |
Forum Index : Microcontroller and PC projects : Duinomite Mega, CRC16/bit shift, newer than v4.5 firmware?
Author | Message | ||||
flasherror Senior Member ![]() Joined: 07/01/2019 Location: United StatesPosts: 159 |
Anyone else using Duinomite Mega boards? (MMBasic v4.5) I realize Geoff is pretty busy but it's been a while since MMBasic for this board has been updated. No SELECT CASE No Cfunctions (please correct me if I'm wrong) No built-in bit shift functions (faster than writing your own BASIC shift code) No CRC16 1. Regarding the last point - I'm doing a project where I need to checksum via CRC16 (Modbus). I know that on fruitoftheshed there is example CRC code, but it seems to be for MMBasic v5. (In any case being Basic it might be slow). Does anyone have any tested v4.5 code? Is it true that C functions are not supported for Duinomite v4.5? 2. If anyone else is using Duinomite Mega boards, how do you deal with the increasing "outdated" nature of MMBasic? (Before you say use a different board/chip the reason I use DM is that these boards are cheap and feature complete (for example connecting to devices via DB9 serial ports etc, or making use of plug-in UEXT boards to add Wifi (via ESP8266). In short, I can focus on software rather than hardware. Is there the equivalent of a "standard" feature complete board for other *mites? Or a "base" motherboard that allows I/O expansion? 3. Is there a documented setup for attempting to build custom firmware for Duinomite MMBasic? (what version of compiler/IDE etc so avoid possible problems) 4. Has anyone besides Geoff made any updated Duinomite MMBasic firmware? Thanks |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Can't help much but I expect the bit shift will be fast enough if you do the obvious and I also expect CRC16 will be fast enough. John |
||||
Turbo46![]() Guru ![]() Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
flasherror, the table lookup version of the CRC16 routine is pretty fast see here. One of my future projects is to make a MODBUS master using the Maximite. I'm sure the CRC16 routine will work well if you remove the references to integers and use the integer divide in place of the shift left instruction. Now I have dusted off my Maximite I'll see if I can try it later today. Bill Keep safe. Live long and prosper. |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Looks like it's on fruitoftheshed already mentioned. John |
||||
Turbo46![]() Guru ![]() Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
CRC16 works on the Maximite after few changes and a lot of head scratching. I was caught out by the LOCAL declaration, you cannot assign a value to a LOCAL variable when you declare it. Use it in the same way as the one in the library. I'll put this one in the library soon. The timing results are: F7CF 5 mS 67D5 7 mS C40B 4 mS Geoff did say he was going to update the Maximite to MMBasic 5.x but that was a while ago. Bill Keep safe. Live long and prosper. |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5091 |
Hi Bill, CRC16 = (CRC MOD 256)*256 + INT(CRC\256) MOD 256 The INT may not be needed, since both MOD and integer divide (\) leave an integer. Volhout On the F4 the code executes in 2ms per CRC16 Edited 2020-05-03 01:15 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
flasherror Senior Member ![]() Joined: 07/01/2019 Location: United StatesPosts: 159 |
Many thanks, Turbo46! Maybe a Tips N' Traps section (for various MMBASIC versions) describing things like that LOCAL "gotcha" would be a good idea. On P34 of the MMBASIC the command reference for LOCAL does not seem to indicate that assignment could be done in the same statement so that looks a bit inconsistent with what one might expect. For when he does get around to it, is there a wishlist of improvements put together by the community? If there is interest I can post my wish list in a new thread so others can add to it and we can have a public idea discussion. |
||||
flasherror Senior Member ![]() Joined: 07/01/2019 Location: United StatesPosts: 159 |
Just a quick question: Would it be more accurate for time measurement to do something like: T1=TIMER CRC$=HEX$(CRC16(test1$),4) T2=TIMER PRINT CRC$; " ";(T2-T1);" mS" to minimise the overhead of PRINT statement? (excluding it as much as possible from timing measurement?) |
||||
Turbo46![]() Guru ![]() Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
I think you are right and I did look at that at one stage while struggling with the LOCAL issue (I was looking for faults everywhere else) but considered it safer to leave it in for now. I think that's a good idea. Maybe a post in this forum could start it and some member(s) could add them to a library or document registry entry? It could be handy when/if MMBasic 5 for the Maximite arrives because I somehow doubt that it will be 100% compatible with 4.5C. There is this link but that is for a future new Maximite. Yes, I guess it would technically, but the 1mS resolution is too coarse anyway. I ran the test several times and the results sometimes varied by 1ms, probably setting the timer to 0 first would help too rather than start at some unknown point in the 1mS time step. If you test it say 1000 times and average it out you would get a more accurate measurement if you ignore the overhead of the FOR/NEXT loop. Bill Keep safe. Live long and prosper. |
||||
Turbo46![]() Guru ![]() Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
Here is a slightly modified version of the MODBUS CRC16 code for the Maximite. Ive added a LOCAL instruction to the CRCTable subroutine and removed the INT function from the CRC16 function as suggested by Volhout, it is not needed. Bill Keep safe. Live long and prosper. |
||||
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |