I think I have made a royal mess of things with my responses.
Got my head down in the reading and writing and forgot to make
sure that the response was to the list first - - - - mea culpa!!!!!


On Sat, May 13, 2023 at 9:22 AM o1bigtenor <o1bigtenor@???> wrote:
>
> ---------- 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!!!!