---------- Forwarded message ---------
From: o1bigtenor <o1bigtenor@???>
Date: Sat, May 13, 2023 at 9:18 AM
Subject: Re: [DNG] Information request (maybe OT - - - dunno)
To: <karl@???>


On Fri, May 12, 2023 at 10:03 PM <karl@???> wrote:
>
> o1bigtenor:
> > My initial problem is a weighing 'cell'
> > where I'm weighing liquids being deposited in a 'jar'.
> > (A second would be items deposited (and then removed in stages) from a
> > 4 wheel cart.)
>

>    So you will have, I guess:
>  one analogue in for weighing
>  a few buttons
>  perhaps a simple 7-seg. lcd for presentation

don't need the presentation - - - - just want the values recorded
- - - every 0.5 seconds is the idea at present.
The challenge here is to get the weighings and opening a solenoid
(looking like I'll have to make that too!) for dumping the contents
after weighing for that batch is completed. Solenoid will be in a normally
open position (pinch valve closed if you're interested) so that a quick rinse
can happen - - then a dump into a different line followed by system
ready for next round. The weighing completion cleaning and reset
needs to be done in like 90 seconds - - - - sounds like a lot but its not
when you want very high reliability and repeatability.
>
> ...
> > Both of above systems will be connected to databases for information
> > storage or is that just a data logger with subsequent not only storage
> > but analysis.
>
> A simple serial port will suffice unless you need it to be wireless.
> On the receiving box with the databases you can use a usb-serial dongle
> if you don't have any serial ports available.

Hmmmmmmm - - - not sure - - - -thinking maybe RS-485? (haven't
finalized any of this thinking yet!)
>
> > Guidance would be greatly appreciated.
>
> For that, check how many pins you need for the lcd, and pick a smallish
> arm M3 mcu with enough pins for the io above.
>
> If you design you own electronics, then you can include all if. for
> the weighting circuits on the same card, helps minimize the clutter.

Each station (initial idea is for 12 stations - - - round 2 anywhere
from 50 odd
to almost 200) will have its own weigh system.
>
> Simple card examples are test.sch test.pcb in:
> http://aspodata.se/git/openhw/boards_arm_aspo/stm32f100_test_board/
>
> More complex, the .sch and .pcb files in:
> http://aspodata.se/git/openhw/boards_arm_aspo/stm32f105_can/
>
> You could also use arduino, beaglebone, rpi et. al. but you must
> still handle the i/o, so not much would be gained by that.
>
More information to investigate - - - thanks!!!!!

> ////
>
> > How does one decide when a RTOS is more appropriate than an OS?
>
> You can program it:
> . barebone
> . with a rtos
> . with a os
>
> With the project you outlined above, programming this barebone would
> suffice.

That's what I was thinking - - - -thanks for confirming!!!!!
>
> The step up to rtos is needed when you plan to have multiple processes
> running. The rtos is actually just a lib you compile in.
>
> The step up to an os is needed when you need to have protection between
> processes, for that you need a mmu (memory management unit) and the
> your cpu can run in some priviliged mode which is usually reached via
> some trap mechanism so that the user processes cannot interfere with
> the supervising os.
>
A previous poster mentioned compiling in the RT_kernel options.
I'm hoping that might make the change between .barebone and .os
a lot smaller.

Thanks for the ideas!!!!