Search found 109 matches
- Sun Jun 16, 2019 8:32 am
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: String Literal Parameter
- Replies: 4
- Views: 26877
Re: String Literal Parameter
I agree, the parameter list for this procedure is on the edge, but still just acceptable. But defining a record type for just some config parameters is worth a thought, especially as I already factored out one parameter, assuming a default value (ptype := Essential), and providing an additional conf...
- Sat Jun 15, 2019 4:16 am
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: String Literal Parameter
- Replies: 4
- Views: 26877
Re: String Literal Parameter
Indeed, using an open array is the work-around, combined with an ASSERT to check the length. The API just gets less expressive and "compile-time-checkable" this way: TYPE ProcessID* = ARRAY 4 OF CHAR; PROCEDURE Init*(p: Process; proc: Coroutines.PROC; stack: ARRAY OF BYTE; startAfter: INTEGER; perio...
- Sat Jun 15, 2019 3:54 am
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Syntax Colouring Limit?
- Replies: 4
- Views: 27716
Re: Syntax Colouring Limit?
Thanks. Renaming the file as advised does the trick.
- Fri Jun 14, 2019 12:21 pm
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: String Literal Parameter
- Replies: 4
- Views: 26877
String Literal Parameter
I don't quite understand why I cannot pass a string literal in this case: MODULE M; TYPE Pid = ARRAY 4 OF CHAR; VAR id: Pid; id2: ARRAY 4 OF CHAR; PROCEDURE P(pid: Pid); END P; BEGIN P("id"); (* error *) id := "id"; P(id); (* ok *) id2 := "id"; P(id2) (* ok *) END M. Isn't "id" a string, which by it...
- Fri Jun 14, 2019 11:02 am
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Syntax Colouring Limit?
- Replies: 4
- Views: 27716
Re: Syntax Colouring Limit?
Thanks! However, I do not get this working OMM, ie. I still see the same colouring as before. I replaced the file and restarted Astrobe. Do I need to reset any preference setting? I still have the personal edition installed in addition to the professional one -- could this interfere?
- Mon Jun 10, 2019 12:20 pm
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Syntax Colouring Limit?
- Replies: 4
- Views: 27716
Syntax Colouring Limit?
Commenting out a block of code with nested comments, I seem to have run into a limitation of the syntax colouring related to comments, see screenshot. It's purely "cosmetic", as the compiler recognises the comments correctly.
- Fri Jun 07, 2019 3:31 am
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Startup Sequence
- Replies: 1
- Views: 18930
Startup Sequence
Are the modules initialised in the order as listed in the ".map" file? Background: I want to "intercept" the reset process at some point. Upon run-errors or some MCU faults, my process scheduler can reset and restart a single process and continue, as an attempt to keep the (unsupervised) program goi...
- Tue May 28, 2019 1:13 pm
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: push {}
- Replies: 20
- Views: 85129
Re: push {}
Another version of the stack trace procedure. The above one stops at the address of the last FP-entry on the stack, this one stops with the contents of this FP-entry. I ran into the problem of where to stop the stack trace when I implemented simple coroutines (as basis for a cooperative task schedul...
- Sat May 25, 2019 9:16 am
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Initialisation of Pointer Variables
- Replies: 2
- Views: 21051
Re: Initialisation of Pointer Variables
Thanks for your explanation. Looks (sounds) like much added complexity without sufficient benefits indeed.
- Sat May 25, 2019 3:48 am
- Forum: Astrobe for ARM Cortex-M0, M3, M4 and M7
- Topic: Initialisation of Pointer Variables
- Replies: 2
- Views: 21051
Initialisation of Pointer Variables
In Oberon, as in many (most?) languages, variables are not initialised by the compiler. Eiffel would be a counter example. I am not sure if general automatic initialisation is a Good Thing, as I prefer if the program text is as explicit as possible. However, there's one exception: pointer variables....