* Interfacing Ada With Full Runtime Directly to Electronic Chips
@ 2017-01-02 2:42 patrick
2017-01-02 9:14 ` Dmitry A. Kazakov
` (4 more replies)
0 siblings, 5 replies; 19+ messages in thread
From: patrick @ 2017-01-02 2:42 UTC (permalink / raw)
Hi Everyone
Happy New Year!
Ada-AVR is a neat project and I am not knocking it. It doesn't have tasking support yet but this is of course a huge job.
If I want to connect any sort of computer running Linux directly to a circuit using "full Ada" with tasking support what are my options?
By circuit, I mean a variety of electronic components and in this case with no microcontroller, an A/D chip is a simple example.
I am thinking that single board computers like BeagleBone are my best bet, they have plenty of GPIO lines.
Has anyone interfaced directly with chips via SPI or IC2 via a GPIO PCI card or GPIO-USB adapter ?
Is there any other options?
Thanks-Patrick
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 2:42 Interfacing Ada With Full Runtime Directly to Electronic Chips patrick
@ 2017-01-02 9:14 ` Dmitry A. Kazakov
2017-01-02 13:28 ` patrick
2017-01-02 14:02 ` Brian Drummond
` (3 subsequent siblings)
4 siblings, 1 reply; 19+ messages in thread
From: Dmitry A. Kazakov @ 2017-01-02 9:14 UTC (permalink / raw)
On 2017-01-02 03:42, patrick@spellingbeewinnars.org wrote:
> If I want to connect any sort of computer running Linux directly to
> a circuit using "full Ada" with tasking support what are my options?
> By circuit, I mean a variety of electronic components and in this
> case with no microcontroller, an A/D chip is a simple example.
I don't understand what you mean. Modern peripherals do not use
dual-ported RAM, the only way you could have it connected without some
sort of microcontroller.
> I am thinking that single board computers like BeagleBone are my
> best bet, they have plenty of GPIO lines.
>
> Has anyone interfaced directly with chips via SPI or IC2 via a GPIO
> PCI card or GPIO-USB adapter ?
We access GPIO digital and analogue converters using Linux driver.
Ada.Text_IO is basically all what is needed. Well, that's Linux. AFAIK,
no decent Linux driver (with interrupts, IOCTL, asynchronous I/O) is
available. But BB's AD/DA is garbage anyway. You could not use it
without additional hardware which would in the end turn more expensive
than other options.
> Is there any other options?
For quality I/O we are using EtherCAT and ModBus I/O terminals.
EtherCAT is very fast but extremely complicated. Don't believe people
saying they have full EtherCAT stack implementations. That would be no
more than a third of what is really needed to talk to complex terminals.
I have implemented EtherCAT master myself.
ModBus is simple, the stack is free. Terminals are a bit sluggish. With
the internal cycle of 3ms you cannot poll them faster than at 5ms. And
if you have many of them it promptly becomes hundreds of milliseconds.
For both you will need tasking, of course.
There is 1-wire and OWFS. I didn't evaluate this option in depth but
from the S/W design point of view it looks no better than GPIO text I/O.
And it is not much cheaper than I/O terminals.
I would never use a USB adapter because of the nature of USB communication.
PCI card is out question for a BB.
Happy New Year!
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 9:14 ` Dmitry A. Kazakov
@ 2017-01-02 13:28 ` patrick
2017-01-02 17:19 ` Dmitry A. Kazakov
2017-01-03 5:33 ` Shark8
0 siblings, 2 replies; 19+ messages in thread
From: patrick @ 2017-01-02 13:28 UTC (permalink / raw)
Hi Dmitry
Thanks yet again for your help and expertise.
Your suggestions are great and can help but let me give a little more background.
I have been servicing scientific instruments since 1999(or 1998 part time). I can repair them just fine but I have done very little circuit design. I have tinkered with the idea of building my own scientific instrument for years but I have always put it aside again due to the start up costs. I have figured out ways to lower these costs and the idea is back on again.
The circuits I work on feature tri-state logic and parallel digital buses. I want to use a serial bus instead. I don't have much hands on experience with SPI or IC2 but this is probably the way to go for communication with peripheral devices in-circuit.
I find myself in a strange place. I like Ada and I would like to use it for embedded design. It has everything that someone might need for controlling chips yet in the 53lsb of Ada books that I have printed or bought, I can't find a single example of someone doing this.
It seems to be used as embedded middleware most of the time. Jeol makes mass spectrometers and uses Ada as they were featured in an Adacore video:
https://www.youtube.com/watch?v=NiO7OOmwlrc
but I haven't worked with their instruments specifically and I am not sure how they control their circuits and if it's just C controlling peripherals.
Every single instrument I have worked with and this is well into the hundreds, is controlled by Windows(which could still be Ada) but I would like to uses Posix and probably Linux.
Every single instrument uses either a microcontroller or embedded processor with a small amount of external RAM and Firmware, nothing close to a computer with full OS at least not to my knowledge.
I was thinking that a single board computer with GPIO that ran Linux could still interface directly with a circuit through on-board GPIO pins. This would be a huge departure from the instruments I have worked on already and is a bit scary for a first design. However it would also provide valuable tools and might shorten the design period.
What does your GPIO setup look like? Is it not PCI based? Could you tell me more.
EtherCat and ModBus look fine but would this mean that Ada would end up as middleware with a C based microcontroller the likely product on the other end. I am hoping to stick to a solution without this.
Thanks for your input on quality issues too, this is priceless as this information is actually quite hard to find.
Happy new year to you too! -Patrick
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 2:42 Interfacing Ada With Full Runtime Directly to Electronic Chips patrick
2017-01-02 9:14 ` Dmitry A. Kazakov
@ 2017-01-02 14:02 ` Brian Drummond
2017-01-02 15:02 ` Dennis Lee Bieber
` (2 subsequent siblings)
4 siblings, 0 replies; 19+ messages in thread
From: Brian Drummond @ 2017-01-02 14:02 UTC (permalink / raw)
On Sun, 01 Jan 2017 18:42:04 -0800, patrick wrote:
> Hi Everyone
>
> Happy New Year!
>
> Ada-AVR is a neat project and I am not knocking it. It doesn't have
> tasking support yet but this is of course a huge job.
There are ARM-Cortex development boards with a bit more resources, and
Ada support including (Ravenscar) tasking, either bare-bones or over a
small RTOS.
Look for work by Simon Wright in respect of these.
Much simpler than Beaglebone, but not full Linux.
Interfacing to hardware isn't difficult. Generally you abstract the
hardware level into a package which knows where the register addresses
are, and different (related) targets use different implementations of the
packages.
For full Linux, I'd look at the Raspberry Pi. But then you get involved
in writing device drivers - there's a project on the first steps on
writing Linux device drivers in Ada, but it's more complex, and not as
well trodden as Linux device drivers in C.
-- Brian
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 2:42 Interfacing Ada With Full Runtime Directly to Electronic Chips patrick
2017-01-02 9:14 ` Dmitry A. Kazakov
2017-01-02 14:02 ` Brian Drummond
@ 2017-01-02 15:02 ` Dennis Lee Bieber
2017-01-02 16:25 ` Simon Wright
2017-01-03 7:55 ` philip.munts
4 siblings, 0 replies; 19+ messages in thread
From: Dennis Lee Bieber @ 2017-01-02 15:02 UTC (permalink / raw)
On Sun, 1 Jan 2017 18:42:04 -0800 (PST), patrick@spellingbeewinnars.org
declaimed the following:
>
>Has anyone interfaced directly with chips via SPI or IC2 via a GPIO PCI card or GPIO-USB adapter ?
>
Off hand, I'm fairly certain a simple USB to GPIO adapter won't do. Too
many timing idiosyncrasies for those protocols. The adapter would have to
have SPI or I2C (?) protocol logic at the far end, and the USB would be
transferring already processed protocol transfers.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 2:42 Interfacing Ada With Full Runtime Directly to Electronic Chips patrick
` (2 preceding siblings ...)
2017-01-02 15:02 ` Dennis Lee Bieber
@ 2017-01-02 16:25 ` Simon Wright
2017-01-02 16:46 ` patrick
2017-01-04 19:29 ` antispam
2017-01-03 7:55 ` philip.munts
4 siblings, 2 replies; 19+ messages in thread
From: Simon Wright @ 2017-01-02 16:25 UTC (permalink / raw)
patrick@spellingbeewinnars.org writes:
> If I want to connect any sort of computer running Linux directly to a
> circuit using "full Ada" with tasking support what are my options?
>
> By circuit, I mean a variety of electronic components and in this case
> with no microcontroller, an A/D chip is a simple example.
>
> I am thinking that single board computers like BeagleBone are my best
> bet, they have plenty of GPIO lines.
>
> Has anyone interfaced directly with chips via SPI or IC2 via a GPIO
> PCI card or GPIO-USB adapter ?
>
> Is there any other options?
You can talk I2C from a Raspberry Pi; see [1], [2]. It was simple to
install GNAT etc from libre.adacore.com, since Raspbian is a Debian
offshoot.
Beaglebone also supports Debian, see [3] for a report on this.
Both of the above use OS device support via file read/write/ioctl. If
you want to go bare(ish) metal, there is the AdaCore Ada_Drivers_Library
at [4]. This uses cross-compilation for ARM Cortex MCUs, compilers from
AdaCore (or [5], [6] for Mac), with runtimes for boards mostly from
STMicroelectronics (e.g. [7]).
The AdaCore runtimes support Ravenscar tasking[8] and come in two
flavours, small footprint (-sfp-) and full (-full-). The -full- version
supports exception handling and finalization and includes
Ada.Numerics. Neither support containers (easy enough to copy into the
-full- version, I expect).
The Ada_Drivers_Library uses a BSD license. The AdaCore runtimes use a
full-GPL license. If this matters to you I have runtimes for Arduino Due
and STM32F4[9] which are based on FreeRTOS and have the GCC Runtime
Library Exception, allowing release of code on proprietary terms.
Just to indicate the flavour of this bare-metal code, I have some SPI
code for an STM32F427, using interface code generated by AdaCore's
SVD2Ada[10], at [11].
[1] https://sourceforge.net/projects/raspi-i2c-ada/
[2] http://raspi-i2c-ada.sourceforge.net
[3] https://groups.google.com/forum/#!topic/beagleboard/O5AU2XL6NJ8
[4] https://github.com/AdaCore/Ada_Drivers_Library
[5] https://sourceforge.net/projects/gnuada/files/GNAT_GPL%20Mac%20OS%20X/2016-arm-eabi-darwin-bin/
[6] https://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac%20OS%20X/6.1.0/arm-eabi/
[7]
http://uk.farnell.com/stmicroelectronics/stm32f407g-disc1/dev-board-foundation-line-mcu/dp/2506840
[8] https://en.wikipedia.org/wiki/Ravenscar_profile
[9] https://sourceforge.net/projects/cortex-gnat-rts/
[10] https://github.com/AdaCore/svd2ada
[11] https://github.com/simonjwright/multiplexed-io/blob/master/drivers/spi1/src/spi1-device.adb
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 16:25 ` Simon Wright
@ 2017-01-02 16:46 ` patrick
2017-01-04 19:29 ` antispam
1 sibling, 0 replies; 19+ messages in thread
From: patrick @ 2017-01-02 16:46 UTC (permalink / raw)
Thanks Brian
And thanks Simon!
This will take a full day to read through properly, wow!
Thanks very much-Patrick
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 13:28 ` patrick
@ 2017-01-02 17:19 ` Dmitry A. Kazakov
2017-01-03 2:41 ` patrick
2017-01-03 5:33 ` Shark8
1 sibling, 1 reply; 19+ messages in thread
From: Dmitry A. Kazakov @ 2017-01-02 17:19 UTC (permalink / raw)
On 2017-01-02 14:28, patrick@spellingbeewinnars.org wrote:
> Your suggestions are great and can help but let me give a little more background.
>
> I have been servicing scientific instruments since 1999(or 1998 part
> time). I can repair them just fine but I have done very little circuit
> design. I have tinkered with the idea of building my own scientific
> instrument for years but I have always put it aside again due to the
> start up costs. I have figured out ways to lower these costs and the
> idea is back on again.
>
> The circuits I work on feature tri-state logic and parallel digital
> buses. I want to use a serial bus instead. I don't have much hands on
> experience with SPI or IC2 but this is probably the way to go for
> communication with peripheral devices in-circuit.
Probably
> I find myself in a strange place. I like Ada and I would like to use
> it for embedded design. It has everything that someone might need for
> controlling chips yet in the 53lsb of Ada books that I have printed or
> bought, I can't find a single example of someone doing this.
Regardless how you wire your custom device to the main board you need a
driver to deal with it.
> It seems to be used as embedded middleware most of the time. Jeol
> makes mass spectrometers and uses Ada as they were featured in an
> Adacore video:
>
> https://www.youtube.com/watch?v=NiO7OOmwlrc
Embedded as "bare board" or embedded as "small"?
> Every single instrument I have worked with and this is well into the
> hundreds, is controlled by Windows(which could still be Ada) but I would
> like to uses Posix and probably Linux.
Instrument as "a [small] computer" or as "a controller/adapter/useless
junk if unconnected etc"
> Every single instrument uses either a microcontroller or embedded
> processor with a small amount of external RAM and Firmware, nothing
> close to a computer with full OS at least not to my knowledge.
That depends on the instrument. Some consist of not one but multiple
full blown computers.
> I was thinking that a single board computer with GPIO that ran Linux
> could still interface directly with a circuit through on-board GPIO
> pins. This would be a huge departure from the instruments I have worked
> on already and is a bit scary for a first design. However it would also
> provide valuable tools and might shorten the design period.
That will need an interface to the outside world and an interface to the
circuit.
> What does your GPIO setup look like?
Under Linux it is a virtual file system with a text file for each DIO
pin. For AIO it is several virtual file system files. This stuff is
provided through the standard Linux driver.
> Is it not PCI based? Could you tell me more.
BB does not have PCI.
In any case you have to write a driver to allow applications access the
circuit. At least one application must run the outside-world interface
allowing external PCs to communicate with the instrument. A network
based interface is usually the best choice.
[ PC ] <--- Ethernet interface ---> [ BB ]
Within the BB:
[ Application ]
|
driver
|
[ SPI or other bus ]
|
wiring
|
[ Circuit ]
The driver represents the data in the desired form (device class). E.g.
GPIO Linux driver represents GPIO pins as virtual files. Reading that
file causes scanning the pin potential. CAN controller driver represents
CAN messages exchange as a socket [SocketCAN]. The device class choice
is up to you and the nature of data.
> EtherCat and ModBus look fine but would this mean that Ada would end
> up as middleware with a C based microcontroller the likely product on
> the other end. I am hoping to stick to a solution without this.
No, I don't suggested making your instrument an EtherCAT terminal.
Though there are solutions for that too. Beckhoff sells small boards
with EtherCAT slave stack and SPI you could use to attach your circuit.
But you could not program that thing in Ada.
I thought you wanted to attach something like a digital input or
incremental encoder. Forget it.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 17:19 ` Dmitry A. Kazakov
@ 2017-01-03 2:41 ` patrick
0 siblings, 0 replies; 19+ messages in thread
From: patrick @ 2017-01-03 2:41 UTC (permalink / raw)
Thanks again Dmitry and thanks everyone, this will keep me busy for some time-Patrick
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 13:28 ` patrick
2017-01-02 17:19 ` Dmitry A. Kazakov
@ 2017-01-03 5:33 ` Shark8
2017-01-03 10:34 ` Dmitry A. Kazakov
1 sibling, 1 reply; 19+ messages in thread
From: Shark8 @ 2017-01-03 5:33 UTC (permalink / raw)
On Monday, January 2, 2017 at 6:28:50 AM UTC-7, pat...@spellingbeewinnars.org wrote:
>
> I have been servicing scientific instruments since 1999(or 1998 part time). I can repair them just fine but I have done very little circuit design. I have tinkered with the idea of building my own scientific instrument for years but I have always put it aside again due to the start up costs. I have figured out ways to lower these costs and the idea is back on again.
Nice.
I'm looking into starting up manufacturing -- see: https://groups.google.com/forum/#!topic/comp.lang.ada/CYOHKtbeokA -- it involves some custom HW, designed from the ground up with formal methods and security.
>
> The circuits I work on feature tri-state logic and parallel digital buses. I want to use a serial bus instead. I don't have much hands on experience with SPI or IC2 but this is probably the way to go for communication with peripheral devices in-circuit.
That's really interesting, because the system I want to do [ultimately] is a ternary computer -- for which tri-state logic is a perfect fit.
>
> I find myself in a strange place. I like Ada and I would like to use it for embedded design. It has everything that someone might need for controlling chips yet in the 53lsb of Ada books that I have printed or bought, I can't find a single example of someone doing this.
Hm, really, not a single reference?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 2:42 Interfacing Ada With Full Runtime Directly to Electronic Chips patrick
` (3 preceding siblings ...)
2017-01-02 16:25 ` Simon Wright
@ 2017-01-03 7:55 ` philip.munts
4 siblings, 0 replies; 19+ messages in thread
From: philip.munts @ 2017-01-03 7:55 UTC (permalink / raw)
On Monday, January 2, 2017 at 3:42:06 AM UTC+1, pat...@spellingbeewinnars.org wrote:
> Hi Everyone
>
> Happy New Year!
>
> Ada-AVR is a neat project and I am not knocking it. It doesn't have tasking support yet but this is of course a huge job.
>
> If I want to connect any sort of computer running Linux directly to a circuit using "full Ada" with tasking support what are my options?
>
> By circuit, I mean a variety of electronic components and in this case with no microcontroller, an A/D chip is a simple example.
>
> I am thinking that single board computers like BeagleBone are my best bet, they have plenty of GPIO lines.
>
> Has anyone interfaced directly with chips via SPI or IC2 via a GPIO PCI card or GPIO-USB adapter ?
>
> Is there any other options?
>
> Thanks-Patrick
I suggest my own Linux Simple I/O Library (http://git.munts.com/libsimpleio). It provides Pascal calling sequence wrappers around the Linux system calls for I2C, SPI, UART, and raw HID devices and includes some shim packages for GNAT.
I have tested it with both native and cross compilers on the BeagleBones Black and Green and Raspberry Pi 2 and 3. I use it mostly with the Raspberry Pi 2 cross toolchain (which also works fine for the BeagleBone family) from AdaCore and targeted to my own embedded Linux distribution called MuntsOS (http://git.munts.com/arm-linux-mcu).
I also have a collection of packages and example programs for various Mikroelektronika click boards and Raspberry Pi hats that are not published yet. I am in the middle of writing a paper about this very topic.
Phil
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-03 5:33 ` Shark8
@ 2017-01-03 10:34 ` Dmitry A. Kazakov
2017-01-03 18:02 ` Shark8
0 siblings, 1 reply; 19+ messages in thread
From: Dmitry A. Kazakov @ 2017-01-03 10:34 UTC (permalink / raw)
On 2017-01-03 06:33, Shark8 wrote:
> That's really interesting, because the system I want to do
> [ultimately] is a ternary computer -- for which tri-state logic is a
> perfect fit.
Out of curiosity, why tri-state logic and not full four-state one?
Tri-state is incomplete in some operations (e.g. in implication).
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-03 10:34 ` Dmitry A. Kazakov
@ 2017-01-03 18:02 ` Shark8
2017-01-03 20:34 ` Dmitry A. Kazakov
0 siblings, 1 reply; 19+ messages in thread
From: Shark8 @ 2017-01-03 18:02 UTC (permalink / raw)
On Tuesday, January 3, 2017 at 3:34:33 AM UTC-7, Dmitry A. Kazakov wrote:
> On 2017-01-03 06:33, Shark8 wrote:
>
> > That's really interesting, because the system I want to do
> > [ultimately] is a ternary computer -- for which tri-state logic is a
> > perfect fit.
>
> Out of curiosity, why tri-state logic and not full four-state one?
> Tri-state is incomplete in some operations (e.g. in implication).
The completeness of the logic-system depends on which logic-system is being used -- there are several for three-valued logic -- but it is a non-issue because you can use full Boolean logic (e.g.) by defining 0 to be True and ±1 to be False (i.e. using inverse-logic).*
There are some advantages to using a trinary system as well: balanced ternary eliminates the need for an adjust-step like 2's complement has because negative and positive numbers share a representation, simpler construction of components (eg a not-gate can be done with a single transistor, instead of two transistors like a binary computer has), and certain operations become simpler as well (eg rounding and truncation are the same operation in balanced-ternary).
* While you might think that this is wasting the states, it need not. Consider the situation where where you have several related binary operations in a decision-tree -- by structuring your operator correctly you can reduce the number of comparisons needed. Example:
IF a And b THEN
Procedure_1;
ELSIF a Or b THEN
Procedure_2;
ELSE
Procedure_3;
END IF;
We can represent the above with a single operator -- the only time the first condition is true is when both inputs are true (a=0,b=0 ==> 0), then in the second condition things are only true when a=0 [x]or b=0, so we 'commandeer' one of the false-values to represent "condition 1 is false, but true for condition 2", in this case choosing '1' for that value, and the remaining states get the other false-value ('J', so that the table below looks correct w/ monospaced font)
|a=1|a=0|a=J
b=1| J | 1 | J
b=0| 1 | 0 | 1
b=J| J | 1 | J
So there you have it -- demonstrable proof that the ternary system can simplify even code-implementation -- as the above combines two conditions into a single operator. (The same thing can be done when you want to check both 'implies' and whether or not the first operand was true, see the table below.)
|a=1|a=0|a=J
b=1| 1 | J | 1
b=0| 1 | 0 | 1
b=J| 1 | J | 1
corresponds to
IF a And b THEN
statements;
ELSIF a >= b THEN -- Implies(a, b)
statements;
ELSE
statements;
END IF;
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-03 18:02 ` Shark8
@ 2017-01-03 20:34 ` Dmitry A. Kazakov
2017-01-03 20:50 ` Shark8
0 siblings, 1 reply; 19+ messages in thread
From: Dmitry A. Kazakov @ 2017-01-03 20:34 UTC (permalink / raw)
On 2017-01-03 19:02, Shark8 wrote:
> On Tuesday, January 3, 2017 at 3:34:33 AM UTC-7, Dmitry A. Kazakov wrote:
>> On 2017-01-03 06:33, Shark8 wrote:
>>
>>> That's really interesting, because the system I want to do
>>> [ultimately] is a ternary computer -- for which tri-state logic is a
>>> perfect fit.
>>
>> Out of curiosity, why tri-state logic and not full four-state one?
>> Tri-state is incomplete in some operations (e.g. in implication).
>
> The completeness of the logic-system depends on which logic-system
> is being used -- there are several for three-valued logic -- but it is a
> non-issue because you can use full Boolean logic (e.g.) by defining 0 to
> be True and ±1 to be False (i.e. using inverse-logic).*
[...]
I see, it is just a ternary system and not logic in the sense of lattice
and inference, like {False, True, Unknown}.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-03 20:34 ` Dmitry A. Kazakov
@ 2017-01-03 20:50 ` Shark8
2017-01-03 21:41 ` Dmitry A. Kazakov
0 siblings, 1 reply; 19+ messages in thread
From: Shark8 @ 2017-01-03 20:50 UTC (permalink / raw)
On Tuesday, January 3, 2017 at 1:34:31 PM UTC-7, Dmitry A. Kazakov wrote:
> On 2017-01-03 19:02, Shark8 wrote:
> > On Tuesday, January 3, 2017 at 3:34:33 AM UTC-7, Dmitry A. Kazakov wrote:
> >> On 2017-01-03 06:33, Shark8 wrote:
> >>
> >>> That's really interesting, because the system I want to do
> >>> [ultimately] is a ternary computer -- for which tri-state logic is a
> >>> perfect fit.
> >>
> >> Out of curiosity, why tri-state logic and not full four-state one?
> >> Tri-state is incomplete in some operations (e.g. in implication).
> >
> > The completeness of the logic-system depends on which logic-system
> > is being used -- there are several for three-valued logic -- but it is a
> > non-issue because you can use full Boolean logic (e.g.) by defining 0 to
> > be True and ±1 to be False (i.e. using inverse-logic).*
>
> [...]
>
> I see, it is just a ternary system and not logic in the sense of lattice
> and inference, like {False, True, Unknown}.
You can model True/False/Unknown -- just map each value to one of {1,0,J}, obviously.
But how would a lattice & inference system look? Esp. at the gate-level.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-03 20:50 ` Shark8
@ 2017-01-03 21:41 ` Dmitry A. Kazakov
0 siblings, 0 replies; 19+ messages in thread
From: Dmitry A. Kazakov @ 2017-01-03 21:41 UTC (permalink / raw)
On 2017-01-03 21:50, Shark8 wrote:
> On Tuesday, January 3, 2017 at 1:34:31 PM UTC-7, Dmitry A. Kazakov wrote:
>> On 2017-01-03 19:02, Shark8 wrote:
>>> On Tuesday, January 3, 2017 at 3:34:33 AM UTC-7, Dmitry A. Kazakov wrote:
>>>> On 2017-01-03 06:33, Shark8 wrote:
>>>>
>>>>> That's really interesting, because the system I want to do
>>>>> [ultimately] is a ternary computer -- for which tri-state logic is a
>>>>> perfect fit.
>>>>
>>>> Out of curiosity, why tri-state logic and not full four-state one?
>>>> Tri-state is incomplete in some operations (e.g. in implication).
>>>
>>> The completeness of the logic-system depends on which logic-system
>>> is being used -- there are several for three-valued logic -- but it is a
>>> non-issue because you can use full Boolean logic (e.g.) by defining 0 to
>>> be True and ±1 to be False (i.e. using inverse-logic).*
>>
>> [...]
>>
>> I see, it is just a ternary system and not logic in the sense of lattice
>> and inference, like {False, True, Unknown}.
>
> You can model True/False/Unknown -- just map each value to one of {1,0,J}, obviously.
Maybe
> But how would a lattice & inference system look? Esp. at the gate-level.
Logic gates? A lattice has "and", "or", "not", obeying de Morgan rules.
They are same as Boolean when arguments are Boolean. E.g. the truth
table for "and":
and F T U
--+------
F | F F F
T | F T U
U | F U U
I understood that this has little (if anything at all) to do with the
system you had in mind. The similarity of names is coincidental.
Considering flow of control in a logical system with "unknown" state.
Let you have
if A and B then
S1;
else
S2;
end if;
Let A = U and B = T. Then A and B = U. So both S1 and S2 must be
evaluated but their side effects kept aside until some point, where you
become certain what path was to choose. Then you commit the effects of
this only path.
In fuzzy systems it is called defuzzification. I am not familiar with
quantum computing, but I guess it is kind of similar to this. You
"calculate" all possible states and at some point collapse all of them
into just one.
Now if you had a forth state you wold follow no path if A and B would
evaluate it. So it is "one"/true, "another"/false, "any", "none", a
complete set of choices.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-02 16:25 ` Simon Wright
2017-01-02 16:46 ` patrick
@ 2017-01-04 19:29 ` antispam
2017-01-04 20:51 ` Simon Wright
1 sibling, 1 reply; 19+ messages in thread
From: antispam @ 2017-01-04 19:29 UTC (permalink / raw)
Simon Wright <simon@pushface.org> wrote:
>
> Both of the above use OS device support via file read/write/ioctl. If
> you want to go bare(ish) metal, there is the AdaCore Ada_Drivers_Library
> at [4]. This uses cross-compilation for ARM Cortex MCUs, compilers from
> AdaCore (or [5], [6] for Mac), with runtimes for boards mostly from
> STMicroelectronics (e.g. [7]).
>
> The AdaCore runtimes support Ravenscar tasking[8] and come in two
> flavours, small footprint (-sfp-) and full (-full-). The -full- version
> supports exception handling and finalization and includes
> Ada.Numerics. Neither support containers (easy enough to copy into the
> -full- version, I expect).
>
> The Ada_Drivers_Library uses a BSD license. The AdaCore runtimes use a
> full-GPL license. If this matters to you I have runtimes for Arduino Due
> and STM32F4[9] which are based on FreeRTOS and have the GCC Runtime
> Library Exception, allowing release of code on proprietary terms.
IIUC STM runtimes are incompatible with GPL. So combining them
with GPL runtime means that result can not be distributed at
all.
--
Waldek Hebisch
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-04 19:29 ` antispam
@ 2017-01-04 20:51 ` Simon Wright
2017-01-04 22:05 ` antispam
0 siblings, 1 reply; 19+ messages in thread
From: Simon Wright @ 2017-01-04 20:51 UTC (permalink / raw)
antispam@math.uni.wroc.pl writes:
> Simon Wright <simon@pushface.org> wrote:
>>
>> Both of the above use OS device support via file read/write/ioctl. If
>> you want to go bare(ish) metal, there is the AdaCore Ada_Drivers_Library
>> at [4]. This uses cross-compilation for ARM Cortex MCUs, compilers from
>> AdaCore (or [5], [6] for Mac), with runtimes for boards mostly from
>> STMicroelectronics (e.g. [7]).
>>
>> The AdaCore runtimes support Ravenscar tasking[8] and come in two
>> flavours, small footprint (-sfp-) and full (-full-). The -full- version
>> supports exception handling and finalization and includes
>> Ada.Numerics. Neither support containers (easy enough to copy into the
>> -full- version, I expect).
>>
>> The Ada_Drivers_Library uses a BSD license. The AdaCore runtimes use a
>> full-GPL license. If this matters to you I have runtimes for Arduino Due
>> and STM32F4[9] which are based on FreeRTOS and have the GCC Runtime
>> Library Exception, allowing release of code on proprietary terms.
>
> IIUC STM runtimes are incompatible with GPL. So combining them
> with GPL runtime means that result can not be distributed at
> all.
Do you have a reference for this? the STM source licence that I see in
the STM32Cube firmware releases imposes very few restrictions on the
actual use of the software, only requiring inclusion of the STM
copyright notice. There's nothing like the restriction quoted in [1].
But in any case the RTS I'm talking about doesn't use any STM code, just
FreeRTOS. Which uses a GPLv2 licence, which doesn't include the usual
"or later version" test. Which may be a problem.
[1] https://github.com/d-ronin/dRonin/issues/928
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Interfacing Ada With Full Runtime Directly to Electronic Chips
2017-01-04 20:51 ` Simon Wright
@ 2017-01-04 22:05 ` antispam
0 siblings, 0 replies; 19+ messages in thread
From: antispam @ 2017-01-04 22:05 UTC (permalink / raw)
Simon Wright <simon@pushface.org> wrote:
> antispam@math.uni.wroc.pl writes:
>
> > Simon Wright <simon@pushface.org> wrote:
> >>
> >> Both of the above use OS device support via file read/write/ioctl. If
> >> you want to go bare(ish) metal, there is the AdaCore Ada_Drivers_Library
> >> at [4]. This uses cross-compilation for ARM Cortex MCUs, compilers from
> >> AdaCore (or [5], [6] for Mac), with runtimes for boards mostly from
> >> STMicroelectronics (e.g. [7]).
> >>
> >> The AdaCore runtimes support Ravenscar tasking[8] and come in two
> >> flavours, small footprint (-sfp-) and full (-full-). The -full- version
> >> supports exception handling and finalization and includes
> >> Ada.Numerics. Neither support containers (easy enough to copy into the
> >> -full- version, I expect).
> >>
> >> The Ada_Drivers_Library uses a BSD license. The AdaCore runtimes use a
> >> full-GPL license. If this matters to you I have runtimes for Arduino Due
> >> and STM32F4[9] which are based on FreeRTOS and have the GCC Runtime
> >> Library Exception, allowing release of code on proprietary terms.
> >
> > IIUC STM runtimes are incompatible with GPL. So combining them
> > with GPL runtime means that result can not be distributed at
> > all.
>
> Do you have a reference for this? the STM source licence that I see in
> the STM32Cube firmware releases imposes very few restrictions on the
> actual use of the software, only requiring inclusion of the STM
> copyright notice. There's nothing like the restriction quoted in [1].
>
> But in any case the RTS I'm talking about doesn't use any STM code, just
> FreeRTOS. Which uses a GPLv2 licence, which doesn't include the usual
> "or later version" test. Which may be a problem.
>
> [1] https://github.com/d-ronin/dRonin/issues/928
I did not look at STM32Cube (they make download awkward and I do
not need most of it). Most of parts that I was able to
download outside of STM32Cube contain the restriction to
STM devices mentioned in [1]. AFAICS some STM libraries
are only available as C headers + binary blob.
Good to hear that you are independent of STM code.
--
Waldek Hebisch
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2017-01-04 22:05 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-02 2:42 Interfacing Ada With Full Runtime Directly to Electronic Chips patrick
2017-01-02 9:14 ` Dmitry A. Kazakov
2017-01-02 13:28 ` patrick
2017-01-02 17:19 ` Dmitry A. Kazakov
2017-01-03 2:41 ` patrick
2017-01-03 5:33 ` Shark8
2017-01-03 10:34 ` Dmitry A. Kazakov
2017-01-03 18:02 ` Shark8
2017-01-03 20:34 ` Dmitry A. Kazakov
2017-01-03 20:50 ` Shark8
2017-01-03 21:41 ` Dmitry A. Kazakov
2017-01-02 14:02 ` Brian Drummond
2017-01-02 15:02 ` Dennis Lee Bieber
2017-01-02 16:25 ` Simon Wright
2017-01-02 16:46 ` patrick
2017-01-04 19:29 ` antispam
2017-01-04 20:51 ` Simon Wright
2017-01-04 22:05 ` antispam
2017-01-03 7:55 ` philip.munts
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox