Use of DMA?

19 views
Skip to first unread message

rob...@hotmail.com

unread,
Dec 6, 2025, 11:08:43 AM12/6/25
to jallist
Hi all,

Has anybody of you had any need to use the Direct Memory Access (DMA) feature of a PIC?

I have no application yet but it could be handy if you want to automatically transfer a lot of data from one location to another location without using CPU cycles.

But there is already a problem with this. If for example you want to copy data from FLASH (e.g. by having a large CONST array) to a USART it would not work. For DMA you need to have the source address (so the FLASH address) of your CONST array and that address is normally provided by the WHEREIS function but this function does not work for CONST. I wonder where this limitiation of WHEREIS comes from and if there is a way to obtain the CONST address in another way. I have looked at the compiler source code but did not yet study it in sufficient detail if is just not - yet - implemented or not possible. Maybe 'older' JAL users may remember why this limitation exists?

Kind regards,

Rob





pinhe...@gmail.com

unread,
Dec 6, 2025, 11:37:14 AM12/6/25
to jallist
Le 6 décembre 2025, à 17:08, rob...@hotmail.com <jal...@googlegroups.com> a écrit:

Hi Rob,

A CONSTANT has no adress during runtime.   It is replaced by its value during compiling on each instance.

Example:

Constant a = 8

B = a + 1

If you look at the same listing, you will see that a has been replaced by 8.   And if optimization does its work, you will have a b = 9, but that is another subject.

If you really need to find an adress for a constant value, example fir a string to send over to the uart, you will have to assign itvto a variable first.




--
You received this message because you are subscribed to the Google Groups "jallist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallist+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jallist/03d757a7-17eb-45a8-b578-1961932fcdedn%40googlegroups.com.

pinhe...@gmail.com

unread,
Dec 6, 2025, 12:16:55 PM12/6/25
to jallist
Le 6 décembre 2025, à 17:37, pinhe...@gmail.com <pinhe...@gmail.com> a écrit:

Sorry for the typos.
Here is the corrected text:


"If you look at the asm listing, you will see that "a" has been replaced by 8.   And if optimization does its work, you will have b = 9, but that is another subject.

If you really need to find an adress for a constant value, example for a string to send over to the uart, you will have to assign it to a variable first."

rob...@hotmail.com

unread,
Dec 6, 2025, 12:35:34 PM12/6/25
to jallist
Hi David,

You are right about a single constant. I meant a const array that is stored in Flash.

Kind regards,

Rob

Op zaterdag 6 december 2025 om 17:37:14 UTC+1 schreef pinhe...@gmail.com:

zma...@gmail.com

unread,
Dec 6, 2025, 1:50:26 PM12/6/25
to jallist
Greetings,
If the constant array is accessed via a variable:

const x = { 1,2,3 }
y = 1
z = x[y]

the array will end up in the code memory as a series of RETLW. I don't think this will help with DMA.
--kylw

Rob CJ

unread,
Dec 7, 2025, 7:06:44 AM12/7/25
to jallist
Hi Kyle,

I made a small change to the compiler source code, not sure yet if it works but I need to test.

There is check in the function 'pic_assign_from_value()' if something is a constant and if so the message is given that whereis cannot be applied to a constant. However, the compiler documentation states it should be possible to use whereis on a constant array which I would need for a DMA transfer to get the address of the const array.

So I made the following changes where it checks for a constant in pic_op.c.
Change:  if (!lbl) {
Into:  ((!lbl) & (!value_is_array(src))) {

The message is still given for a single constant but not for an array and the code seems to be generated.

I will now test to see if it actually works in combination with DMA.

Kind regards,

Rob


Van: jal...@googlegroups.com <jal...@googlegroups.com> namens zma...@gmail.com <zma...@gmail.com>
Verzonden: zaterdag 6 december 2025 19:50
Aan: jallist <jal...@googlegroups.com>
Onderwerp: Re: [jallist] Use of DMA?
 

zma...@gmail.com

unread,
Dec 7, 2025, 3:25:12 PM12/7/25
to jallist
Greetings,

The difficulty is, you need to be able to distinguish (in whereis) the difference between a constant array and a variable array. If I recall (it's been a while), on the 16 bit cores constant arrays are still in code memory, but are defined using `db' so are actually contiguous bytes, as opposed to the 12 & 14 bit cores where they are `retlw' instructions. whereis on these would be pointless.

Rob CJ

unread,
Dec 20, 2025, 11:52:54 AM12/20/25
to jal...@googlegroups.com
Hi Kyle,

Ah I understand what you mean and now I also understand the compiler source code. It seems that 'whereis' does work for const arrays but only for the PIC18F series, so the 16 bit cores. The compiler does not complain about using 'whereis' on a constant array as long as you use a 16 bit core. I think that I may add that as a remark to the compiler documentation on the use of 'whereis'.

It now says.

And for you and everybody on the JAL Google Group, a Mery Christmas and and a Happy New Year.

Kind regards,

Rob




Verzonden: zondag 7 december 2025 21:25

Rob CJ

unread,
Dec 20, 2025, 11:59:11 AM12/20/25
to jal...@googlegroups.com
Hi all,

Sorry I was a bit to soon. What I wanted to add is that the documentation should be fixed. It now says that for non-16 bit cores it returns the entry point to the lookup table but that is not correct. For these cores the compiler generated an error.

Kind regards,

Rob





Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob CJ <rob...@hotmail.com>
Verzonden: zaterdag 20 december 2025 17:52
Aan: jal...@googlegroups.com <jal...@googlegroups.com>

vasi vasi

unread,
Dec 22, 2025, 7:30:26 AM12/22/25
to jal...@googlegroups.com
Merry Christmas and Happy New Year! 
May God bless you all!



--
Vasi

Rob CJ

unread,
Dec 22, 2025, 12:49:05 PM12/22/25
to jal...@googlegroups.com
Hi Vasi,

Thanks. 

In the meantime I solved the mystery about the warning that whereis() cannot be applied on a constant also in case of a constant array. So if you - or other JAL users - are interested you can read the following. 

I was trying to get DMA on a PIC operational, just to see how it works. I declared a const array with some text that I wanted to send to the USART using DMA. For DMA you need the address of the constant array so I used the whereis() function for that but got the message that whereis() cannot be used on a constant. This is true for a single constant as described in the jalv2 documentation but I found that strange for a constant array since that is not a single constant.

The problem was caused by the following. Since DMA only uses the address of the constant array and not the constant array itself, the compiler 'thinks' that the constant array is not used and so it is optimized away and then the whereis() function cannot find the label of the constant array and so generates the error message. I made a DMA sample program (18f15q40_dma.jal) and solved this by a dummy instruction that uses the const array and then it works. This dummy code looks like this but can be any other code as long as you make the compiler 'think' that the array is used: dummy = dummy + my_text_with_dma[text_size]  where my_text_with_dma is the constant array.

So I think it should have been nice that if you use the whereis() on a constant array that it flags it as being used so that it is not optimized away. But anyway it now works and I added to the jalv2 documentation the following about a simple constant which was already documented: A simple constant or an unused constant array will generate an error. 

I assume - but did not test this - that the same error message is given if you apply it to a procedure when the procedure is not used. Not sure if there is a use case for this but I can imagine that this could be the case if you would like to pass an address of a procedure as argument to another procedure that then calls that procedure using its address (you need to hack some assembly code to get that working I think) in which case the procedure iteself is not called directly.

Kind regards,

Rob


Van: jal...@googlegroups.com <jal...@googlegroups.com> namens vasi vasi <fun...@gmail.com>
Verzonden: maandag 22 december 2025 13:30

vasi vasi

unread,
Dec 24, 2025, 12:23:28 AM12/24/25
to jal...@googlegroups.com
Thank you Rob for your work, much appreciated! 



--
Vasi
Reply all
Reply to author
Forward
0 new messages