Hi,
I’m trying to port libpd to stm32. I don’t need gui so working only on connecting pd script to the output (which is DAC from stm32 in my case). The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question: What does class_new do?
My guess is connecting puredata command with a function in C. Am I correct or completely missing the point?
Thanks.
B.
Hi,
The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question:
I think first you should post the error you get ;-) Maybe the problem is trivially solved without having to look at code for class_new() at all.
What does class_new do?
It creates a new Pd class (t_pd). The class contains all the methods and some metadata. It also registers a creator function in pd_objectmaker, which is the factory object for all classes.
When you type "[foo 0]" you really send a message "obj <x> <y> foo 0" to the canvas, which in turn sends a message "foo 0" to pd_objectmaker, which finally returns a newly created instance (given that it can find a creator method for "foo").
But again, I think the problem is likely trivial and those implementation details shouldn't concern you, unless you want to learn about Pd internals, of course :-)
Christof
On 21.03.2020 13:20, Boštjan Jerko wrote:
Hi,
I’m trying to port libpd to stm32. I don’t need gui so working only on connecting pd script to the output (which is DAC from stm32 in my case). The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question: What does class_new do?
My guess is connecting puredata command with a function in C. Am I correct or completely missing the point?
Thanks.
B.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hi Christof,
the problem is that I don’t really know what happens but it goes something like that:
calling pd_init -> pd_init_systems -> conf_init -> x_connective_setup -> pdint_setup
and then in function class_new vp is empty so while (*vp) doesn’t go through it and after exiting class_new the microcontroller stops with a hard error. So maybe the question is really - should the vp be empty and if not - why is that happening?
B.
On 21 Mar 2020, at 13:58, Christof Ressi info@christofressi.com wrote:
Hi,
The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question:
I think first you should post the error you get ;-) Maybe the problem is trivially solved without having to look at code for class_new() at all.
What does class_new do?
It creates a new Pd class (t_pd). The class contains all the methods and some metadata. It also registers a creator function in pd_objectmaker, which is the factory object for all classes.
When you type "[foo 0]" you really send a message "obj <x> <y> foo 0" to the canvas, which in turn sends a message "foo 0" to pd_objectmaker, which finally returns a newly created instance (given that it can find a creator method for "foo").
But again, I think the problem is likely trivial and those implementation details shouldn't concern you, unless you want to learn about Pd internals, of course :-)
Christof
On 21.03.2020 13:20, Boštjan Jerko wrote:
Hi,
I’m trying to port libpd to stm32. I don’t need gui so working only on connecting pd script to the output (which is DAC from stm32 in my case). The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question: What does class_new do?
My guess is connecting puredata command with a function in C. Am I correct or completely missing the point?
Thanks.
B.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
and then in function class_new vp is empty so while (*vp) doesn’t go through it
What do you mean by "empty", when exactly is "vp" empty and how did you test?
"vp" is initially set to "type1", which in the case of pdint_setup() is "A_DEFFLOAT". So it would be very strange if "vp" was initially empty in the case pdint_setup(). The while loop sets "vp" to the next vararg and increments the pointer until it encounters "A_NULL" (= 0). So finally, "*vp" will always be 0, if that is what you mean by empty.
Or did you mean "vp" itself is NULL? This would be even stranger, because it points to the stack.
Do your run the code in a debugger? If yes, post the stack trace. If not, well, use a debugger :-)
BTW, which device are you using?
Christof
On 22.03.2020 09:13, Boštjan Jerko wrote:
Hi Christof,
the problem is that I don’t really know what happens but it goes something like that:
calling pd_init -> pd_init_systems -> conf_init -> x_connective_setup -> pdint_setup
and then in function class_new vp is empty so while (*vp) doesn’t go through it and after exiting class_new the microcontroller stops with a hard error. So maybe the question is really - should the vp be empty and if not - why is that happening?
B.
On 21 Mar 2020, at 13:58, Christof Ressi info@christofressi.com wrote:
Hi,
The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question:
I think first you should post the error you get ;-) Maybe the problem is trivially solved without having to look at code for class_new() at all.
What does class_new do?
It creates a new Pd class (t_pd). The class contains all the methods and some metadata. It also registers a creator function in pd_objectmaker, which is the factory object for all classes.
When you type "[foo 0]" you really send a message "obj <x> <y> foo 0" to the canvas, which in turn sends a message "foo 0" to pd_objectmaker, which finally returns a newly created instance (given that it can find a creator method for "foo").
But again, I think the problem is likely trivial and those implementation details shouldn't concern you, unless you want to learn about Pd internals, of course :-)
Christof
On 21.03.2020 13:20, Boštjan Jerko wrote:
Hi,
I’m trying to port libpd to stm32. I don’t need gui so working only on connecting pd script to the output (which is DAC from stm32 in my case). The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question: What does class_new do?
My guess is connecting puredata command with a function in C. Am I correct or completely missing the point?
Thanks.
B.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I’m attaching images from debugger. The strange thing is that type1 is A_DEFFLOAT, but *vp is still A_NULL. Guess I need to work (at least) on that. That way the loop doesn’t even get started. So one image shows values of type1 and *vp and the other is stack.
I’m using stm32f429 and Segger programmer with their Ozone debugger.
B.
On 22 Mar 2020, at 11:52, Christof Ressi info@christofressi.com wrote:
and then in function class_new vp is empty so while (*vp) doesn’t go through it
What do you mean by "empty", when exactly is "vp" empty and how did you test?
"vp" is initially set to "type1", which in the case of pdint_setup() is "A_DEFFLOAT". So it would be very strange if "vp" was initially empty in the case pdint_setup(). The while loop sets "vp" to the next vararg and increments the pointer until it encounters "A_NULL" (= 0). So finally, "*vp" will always be 0, if that is what you mean by empty.
Or did you mean "vp" itself is NULL? This would be even stranger, because it points to the stack.
Do your run the code in a debugger? If yes, post the stack trace. If not, well, use a debugger :-)
BTW, which device are you using?
Christof
On 22.03.2020 09:13, Boštjan Jerko wrote:
Hi Christof,
the problem is that I don’t really know what happens but it goes something like that:
calling pd_init -> pd_init_systems -> conf_init -> x_connective_setup -> pdint_setup
and then in function class_new vp is empty so while (*vp) doesn’t go through it and after exiting class_new the microcontroller stops with a hard error. So maybe the question is really - should the vp be empty and if not - why is that happening?
B.
On 21 Mar 2020, at 13:58, Christof Ressi info@christofressi.com wrote:
Hi,
The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question:
I think first you should post the error you get ;-) Maybe the problem is trivially solved without having to look at code for class_new() at all.
What does class_new do?
It creates a new Pd class (t_pd). The class contains all the methods and some metadata. It also registers a creator function in pd_objectmaker, which is the factory object for all classes.
When you type "[foo 0]" you really send a message "obj <x> <y> foo 0" to the canvas, which in turn sends a message "foo 0" to pd_objectmaker, which finally returns a newly created instance (given that it can find a creator method for "foo").
But again, I think the problem is likely trivial and those implementation details shouldn't concern you, unless you want to learn about Pd internals, of course :-)
Christof
On 21.03.2020 13:20, Boštjan Jerko wrote:
Hi,
I’m trying to port libpd to stm32. I don’t need gui so working only on connecting pd script to the output (which is DAC from stm32 in my case). The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question: What does class_new do?
My guess is connecting puredata command with a function in C. Am I correct or completely missing the point?
Thanks.
B.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Don't worry too much about *vp for now. The fault actually occurs in m_class.c:506.
Do you use PDINSTANCE?
Also, you can check stm32f4xx_it.c:90 to see what kind of error you're getting.
How much memory do you have available?
Christof
On 22.03.2020 17:15, Boštjan Jerko wrote:
I’m attaching images from debugger. The strange thing is that type1 is A_DEFFLOAT, but *vp is still A_NULL. Guess I need to work (at least) on that. That way the loop doesn’t even get started. So one image shows values of type1 and *vp and the other is stack.
I’m using stm32f429 and Segger programmer with their Ozone debugger.
B.
On 22 Mar 2020, at 11:52, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> wrote:
and then in function class_new vp is empty so while (*vp) doesn’t go through it
What do you mean by "empty", when exactly is "vp" empty and how did you test?
"vp" is initially set to "type1", which in the case of pdint_setup() is "A_DEFFLOAT". So it would be very strange if "vp" was initially empty in the case pdint_setup(). The while loop sets "vp" to the next vararg and increments the pointer until it encounters "A_NULL" (= 0). So finally, "*vp" will always be 0, if that is what you mean by empty.
Or did you mean "vp" itself is NULL? This would be even stranger, because it points to the stack.
Do your run the code in a debugger? If yes, post the stack trace. If not, well, use a debugger :-)
BTW, which device are you using?
Christof
On 22.03.2020 09:13, Boštjan Jerko wrote:
Hi Christof,
the problem is that I don’t really know what happens but it goes something like that:
calling pd_init -> pd_init_systems -> conf_init -> x_connective_setup -> pdint_setup
and then in function class_new vp is empty so while (*vp) doesn’t go through it and after exiting class_new the microcontroller stops with a hard error. So maybe the question is really - should the vp be empty and if not
- why is that happening?
B.
On 21 Mar 2020, at 13:58, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> wrote:
Hi,
The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question:
I think first you should post the error you get ;-) Maybe the problem is trivially solved without having to look at code for class_new() at all.
What does class_new do?
It creates a new Pd class (t_pd). The class contains all the methods and some metadata. It also registers a creator function in pd_objectmaker, which is the factory object for all classes.
When you type "[foo 0]" you really send a message "obj <x> <y> foo 0" to the canvas, which in turn sends a message "foo 0" to pd_objectmaker, which finally returns a newly created instance (given that it can find a creator method for "foo").
But again, I think the problem is likely trivial and those implementation details shouldn't concern you, unless you want to learn about Pd internals, of course :-)
Christof
On 21.03.2020 13:20, Boštjan Jerko wrote:
Hi,
I’m trying to port libpd to stm32. I don’t need gui so working only on connecting pd script to the output (which is DAC from stm32 in my case). The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question: What does class_new do?
My guess is connecting puredata command with a function in C. Am I correct or completely missing the point?
Thanks.
B.
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I don’t use PDINSTANCE, but after checking some online stuff I thought maybe the size of the stack is the problem so I’ve changed it from 0x400 to 0x4000 and heap size from 0x200 to 0x2000, but no success. Still - I guess there is something going on with the memory so I’ll be checking this some more.
On 22 Mar 2020, at 18:01, Christof Ressi info@christofressi.com wrote:
Don't worry too much about *vp for now. The fault actually occurs in m_class.c:506.
Do you use PDINSTANCE?
Also, you can check stm32f4xx_it.c:90 to see what kind of error you're getting.
How much memory do you have available?
Christof
On 22.03.2020 17:15, Boštjan Jerko wrote:
I’m attaching images from debugger. The strange thing is that type1 is A_DEFFLOAT, but *vp is still A_NULL. Guess I need to work (at least) on that. That way the loop doesn’t even get started. So one image shows values of type1 and *vp and the other is stack.
I’m using stm32f429 and Segger programmer with their Ozone debugger.
B.
<vp_value.png><stack.png>
On 22 Mar 2020, at 11:52, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> wrote:
and then in function class_new vp is empty so while (*vp) doesn’t go through it
What do you mean by "empty", when exactly is "vp" empty and how did you test?
"vp" is initially set to "type1", which in the case of pdint_setup() is "A_DEFFLOAT". So it would be very strange if "vp" was initially empty in the case pdint_setup(). The while loop sets "vp" to the next vararg and increments the pointer until it encounters "A_NULL" (= 0). So finally, "*vp" will always be 0, if that is what you mean by empty.
Or did you mean "vp" itself is NULL? This would be even stranger, because it points to the stack.
Do your run the code in a debugger? If yes, post the stack trace. If not, well, use a debugger :-)
BTW, which device are you using?
Christof
On 22.03.2020 09:13, Boštjan Jerko wrote:
Hi Christof,
the problem is that I don’t really know what happens but it goes something like that:
calling pd_init -> pd_init_systems -> conf_init -> x_connective_setup -> pdint_setup
and then in function class_new vp is empty so while (*vp) doesn’t go through it and after exiting class_new the microcontroller stops with a hard error. So maybe the question is really - should the vp be empty and if not - why is that happening?
B.
On 21 Mar 2020, at 13:58, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> wrote:
Hi,
The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question:
I think first you should post the error you get ;-) Maybe the problem is trivially solved without having to look at code for class_new() at all.
What does class_new do?
It creates a new Pd class (t_pd). The class contains all the methods and some metadata. It also registers a creator function in pd_objectmaker, which is the factory object for all classes.
When you type "[foo 0]" you really send a message "obj <x> <y> foo 0" to the canvas, which in turn sends a message "foo 0" to pd_objectmaker, which finally returns a newly created instance (given that it can find a creator method for "foo").
But again, I think the problem is likely trivial and those implementation details shouldn't concern you, unless you want to learn about Pd internals, of course :-)
Christof
On 21.03.2020 13:20, Boštjan Jerko wrote:
Hi,
I’m trying to port libpd to stm32. I don’t need gui so working only on connecting pd script to the output (which is DAC from stm32 in my case). The code compiles but I get the error when running in the pdint_setup where pdint_new in class_new breaks with an error. My idea is to first try to understand the code hence my question: What does class_new do?
My guess is connecting puredata command with a function in C. Am I correct or completely missing the point?
Thanks.
B.
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Check how much memory Pd is using. I mean, a 16 kB stack and 130 kB heap is still pretty small... (if those hex numbers mean bytes). Pd hasn't really been designed to run on microcontrollers ;-). Anyway, have a look at m_memory.c, there are some heap memory debug options, in case your developer tools don't provide this.
Christof
On 24.03.2020 09:25, Boštjan Jerko wrote:
I don’t use PDINSTANCE, but after checking some online stuff I thought maybe the size of the stack is the problem so I’ve changed it from 0x400 to 0x4000 and heap size from 0x200 to 0x2000, but no success. Still - I guess there is something going on with the memory so I’ll be checking this some more.
Do you know what are the minimum values for the stack and heap? At least rough estimation.
B.
On 24 Mar 2020, at 11:30, Christof Ressi info@christofressi.com wrote:
Check how much memory Pd is using. I mean, a 16 kB stack and 130 kB heap is still pretty small... (if those hex numbers mean bytes). Pd hasn't really been designed to run on microcontrollers ;-). Anyway, have a look at m_memory.c, there are some heap memory debug options, in case your developer tools don't provide this.
Christof
On 24.03.2020 09:25, Boštjan Jerko wrote:
I don’t use PDINSTANCE, but after checking some online stuff I thought maybe the size of the stack is the problem so I’ve changed it from 0x400 to 0x4000 and heap size from 0x200 to 0x2000, but no success. Still - I guess there is something going on with the memory so I’ll be checking this some more.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I think a stack of 16 kB should be enough, but watch out for certain objects that might do large stack allocations, e.g. [sigmund~]. A modern OS usually has a stack size of at least 1 MB...
Regarding heap memory, you could get a rough idea by writing a small libpd test program on your Desktop with Pd's memory debug option or some external memory debugging tool like valgrind.
Also don't forget that the code itself also has to be loaded into memory. Then there are of course the actual Pd patches, which also need memory.
Finally, note that depending on the actual memory allocator, memory usage might not be deterministic. There are things like heap fragmentation to look out for. Pd might do heap allocations repeatedly during run time, e.g. [vline~] or any list larger than 100 atoms, and with such a small heap, fragmentation is very likely. One bigger allocation and boom - you're basically out of memory.
I don't know whether it's much fun to use Pd in such a constrained environment. Sound very brittle to me... You might be better of with an actual signal processing library, where you can control every aspect of your program.
Is there anyone who has actually used or tried to use libpd under such extreme memory constraints and can share their experience?
Christof
On 24.03.2020 11:49, Boštjan Jerko wrote:
Do you know what are the minimum values for the stack and heap? At least rough estimation.
B.
On 24 Mar 2020, at 11:30, Christof Ressi info@christofressi.com wrote:
Check how much memory Pd is using. I mean, a 16 kB stack and 130 kB heap is still pretty small... (if those hex numbers mean bytes). Pd hasn't really been designed to run on microcontrollers ;-). Anyway, have a look at m_memory.c, there are some heap memory debug options, in case your developer tools don't provide this.
Christof
On 24.03.2020 09:25, Boštjan Jerko wrote:
I don’t use PDINSTANCE, but after checking some online stuff I thought maybe the size of the stack is the problem so I’ve changed it from 0x400 to 0x4000 and heap size from 0x200 to 0x2000, but no success. Still - I guess there is something going on with the memory so I’ll be checking this some more.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 24 Mar 2020, at 13:49, Christof Ressi info@christofressi.com wrote:
I think a stack of 16 kB should be enough, but watch out for certain objects that might do large stack allocations, e.g. [sigmund~]. A modern OS usually has a stack size of at least 1 MB...
Regarding heap memory, you could get a rough idea by writing a small libpd test program on your Desktop with Pd's memory debug option or some external memory debugging tool like valgrind.
Also don't forget that the code itself also has to be loaded into memory. Then there are of course the actual Pd patches, which also need memory.
Finally, note that depending on the actual memory allocator, memory usage might not be deterministic. There are things like heap fragmentation to look out for. Pd might do heap allocations repeatedly during run time, e.g. [vline~] or any list larger than 100 atoms, and with such a small heap, fragmentation is very likely. One bigger allocation and boom - you're basically out of memory.
I don't know whether it's much fun to use Pd in such a constrained environment. Sound very brittle to me... You might be better of with an actual signal processing library, where you can control every aspect of your program.
That’s more and more on my mind. Since the pd code I’m trying to move to microcontroller is not that simple I dread I’ll have constant problems with memory. I’ll look into what I need for signal processing regarding the code I’m porting and see what I can do here.
Is there anyone who has actually used or tried to use libpd under such extreme memory constraints and can share their experience?
Christof
Thanks.
B.
On 24.03.2020 11:49, Boštjan Jerko wrote:
Do you know what are the minimum values for the stack and heap? At least rough estimation.
B.
On 24 Mar 2020, at 11:30, Christof Ressi info@christofressi.com wrote:
Check how much memory Pd is using. I mean, a 16 kB stack and 130 kB heap is still pretty small... (if those hex numbers mean bytes). Pd hasn't really been designed to run on microcontrollers ;-). Anyway, have a look at m_memory.c, there are some heap memory debug options, in case your developer tools don't provide this.
Christof
On 24.03.2020 09:25, Boštjan Jerko wrote:
I don’t use PDINSTANCE, but after checking some online stuff I thought maybe the size of the stack is the problem so I’ve changed it from 0x400 to 0x4000 and heap size from 0x200 to 0x2000, but no success. Still - I guess there is something going on with the memory so I’ll be checking this some more.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
OK. Here it goes. Flash size looks ok, but RAM is too small. According to my calculations it should be at least 305 Kb (and it’s 256 Kb). I’m searching for new developer board with microcontroller with larger RAM and let’s see where it will take me.
Thank for the help.
B.
On 24 Mar 2020, at 13:58, Boštjan Jerko bojerko@gmail.com wrote:
On 24 Mar 2020, at 13:49, Christof Ressi info@christofressi.com wrote:
I think a stack of 16 kB should be enough, but watch out for certain objects that might do large stack allocations, e.g. [sigmund~]. A modern OS usually has a stack size of at least 1 MB...
Regarding heap memory, you could get a rough idea by writing a small libpd test program on your Desktop with Pd's memory debug option or some external memory debugging tool like valgrind.
Also don't forget that the code itself also has to be loaded into memory. Then there are of course the actual Pd patches, which also need memory.
Finally, note that depending on the actual memory allocator, memory usage might not be deterministic. There are things like heap fragmentation to look out for. Pd might do heap allocations repeatedly during run time, e.g. [vline~] or any list larger than 100 atoms, and with such a small heap, fragmentation is very likely. One bigger allocation and boom - you're basically out of memory.
I don't know whether it's much fun to use Pd in such a constrained environment. Sound very brittle to me... You might be better of with an actual signal processing library, where you can control every aspect of your program.
That’s more and more on my mind. Since the pd code I’m trying to move to microcontroller is not that simple I dread I’ll have constant problems with memory. I’ll look into what I need for signal processing regarding the code I’m porting and see what I can do here.
Is there anyone who has actually used or tried to use libpd under such extreme memory constraints and can share their experience?
Christof
Thanks.
B.
On 24.03.2020 11:49, Boštjan Jerko wrote:
Do you know what are the minimum values for the stack and heap? At least rough estimation.
B.
On 24 Mar 2020, at 11:30, Christof Ressi info@christofressi.com wrote:
Check how much memory Pd is using. I mean, a 16 kB stack and 130 kB heap is still pretty small... (if those hex numbers mean bytes). Pd hasn't really been designed to run on microcontrollers ;-). Anyway, have a look at m_memory.c, there are some heap memory debug options, in case your developer tools don't provide this.
Christof
On 24.03.2020 09:25, Boštjan Jerko wrote:
I don’t use PDINSTANCE, but after checking some online stuff I thought maybe the size of the stack is the problem so I’ve changed it from 0x400 to 0x4000 and heap size from 0x200 to 0x2000, but no success. Still - I guess there is something going on with the memory so I’ll be checking this some more.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Am Mittwoch, 25. März 2020, 09:22:22 CET schrieb Boštjan Jerko:
OK. Here it goes. Flash size looks ok, but RAM is too small. According to my calculations it should be at least 305 Kb (and it’s 256 Kb). I’m searching for new developer board with microcontroller with larger RAM and let’s see where it will take me.
ESP32 has 520 KB SRAM, ESP32-ADF should also provide audio in and out. Just testing it with faust. ESP32-Pd would be ultra cool... With ethernet: Olimex ESP32-PoE-ISO.
mfG winfried
Am 22. März 2020 09:13:23 MEZ schrieb "Boštjan Jerko" bojerko@gmail.com:
Hi Christof,
the problem is that I don’t really know what happens but it goes something like that:
calling pd_init -> pd_init_systems -> conf_init -> x_connective_setup -> pdint_setup
and then in function class_new vp is empty so while (*vp) doesn’t go through it and after exiting class_new the microcontroller stops with a hard error. So maybe the question is really - should the vp be empty and if not - why is that happening?
what's "vp"?
also, your underlying problem sounds like a typical usecase for " libpd".
mfg.hft.fsl IOhannes
what's "vp"?
a variable in class_new()
also, your underlying problem sounds like a typical usecase for " libpd".
From his first e-mail, I understood he is already using libpd.
Christof
On 22.03.2020 13:09, IOhannes m zmölnig wrote:
Am 22. März 2020 09:13:23 MEZ schrieb "Boštjan Jerko" bojerko@gmail.com:
Hi Christof,
the problem is that I don’t really know what happens but it goes something like that:
calling pd_init -> pd_init_systems -> conf_init -> x_connective_setup -> pdint_setup
and then in function class_new vp is empty so while (*vp) doesn’t go through it and after exiting class_new the microcontroller stops with a hard error. So maybe the question is really - should the vp be empty and if not - why is that happening?
what's "vp"?
also, your underlying problem sounds like a typical usecase for " libpd".
mfg.hft.fsl IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Boštjan Jerko -
Christof Ressi -
IOhannes m zmölnig -
Winfried Ritsch