 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : May I suggest...
| Author | Message | ||||
knivd Regular Member  Joined: 07/09/2014 Location: United KingdomPosts: 71 |
... for those Nucleo F4 and H7 ports, two things are really missing, and if they were there, could be very useful in a wide range of applications. 1. Servo control has been existing for many years, but stepper control is much more attractive, and having something high-quality like TMC5160 via SPI would be really useful for various robotic projects. I know there are a few Arduino libraries already existing for this, but nothing on the mmbasic front. 2. Proper Ethernet support!! Some of these two might have been included already, for which I apologise. Have not kept myself up to date with the progress. |
||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8567 |
Servo control is certainly do-able - TMC2208/9 seem to be the ones everyone is using in the 3D print world Ethernet is a pretty much non-starter without a major re-write. To make it useful really needs the application to sit on top of a RTOS (e.g. FreeRTOS) and that disrupts everything that relies on timing without a lot of work |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
option 2. How do you propose to connect - at what level do you want it; text stream or sockets? What hardware would be supported? What about DNS? IPv6? WiFi of the ESP stuff or cabled Wizznet? so many permutations! there's a lot of stuff goes on that allows you to do all that which is hidden from view. Above the hardware, it would be fairly easy to implement a "text" stream model which dove-tailed with existing MMBasic models of serial comms because the network does a lot of the work but there are wrinkles - what about disconnects in single transfer protocols e.g. HTTP where the server automatically closes the connection once the file is sent. This threatens the text stream model immediately as you will need to open the connection each time (having watched for it being closed). So immediately you are going to have to deal with automatically closed comms channels. what about UDP? it is a fire & forget protocol - there is no connection that has to be maintained. The buffering would have to be extreme because if you can't service the arriving data quick enough, it is lost (not so much of a problem with TCP due to ACK of each packet so the sender should never exceed the listener's ability to take the data). then you have to look at multiple connections. The ESP8266 et al support five or six and it is reasonably easy to differentiate between each but it is still a fair bit of work to handle for reading where you have multiple inbound channels. even at a fairly high "text stream" level there are so many permutations... remote address if required - e.g. if a "listener" there is none. You'd need some OPTION config to define the hardware and how it is attached... If all this were conquered, something like Open "TCP:[IP Address],[remote port],[local port]" as #1 would allow a good level of control where all aspects of the socket where optional due to the permutations of the connection.so to connect as a client to a web server, something along the lines of Open "TCP:10.20.30.40,80," As #1 could be typical. The local port could be specified or allocated from the list of ephemerals (another thing to manage - or maybe make the reply port mandatory and the user deals with it). and to BE a web server Open "TCP:,,80" As #1 then for some proprietary protocol Open "TCP:10.10.10.20:9999,9998" As #1 would bind specifically to the send/receive ports For UDP (if hardware supports it) you could take a similar approach but only ever one port specified (because no reply), so maybe Open "UDP:[IP Address],[remote port]," As #1 to send a UDP packet or Open "UDP:,,[local port]" As #1 as a UDP listener I quite like the idea of UDP as being able to send SNMPTraps would be very useful and would seriously make me embrace Ethernet more for micro-controllers The handling of the data I think is way beyond the firmware simply because of the permutations. An interrupt when something has arrived would be good and perhaps when something has gone. Processing the data is quite do-able, treating it as a file for reading and writing using Input$ and Print (I did this with my ESP8266 code in my SMS Gateway) so much to think about... and we haven't even got to other common protocols such as ICMP so you could do a ping... but the ESP jobbies have that built in so maybe the mooted firmware update could deal with that by being clever on the hardware Option config. Before you started on something like this, you have to decide where the boundaries are - they are undoubtedly there as a full stack is just not possible (I think) so where are the lines? What do you want to be able to do? whatever, it is a major work and then there would be a lot to do in the application (timeouts, data arriving/leaving, overflows, responses, deep level driving of protocols etc.) because there is a limit what a "one size fits all" firmware can cater for. . Edited 2021-09-14 00:30 by CaptainBoing |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
Stepper control depends very much on what you want. It's easy enough to write simple stepper routines in MMBasic. All you need is to set up a port connected to a driver pcb then run a loop writing suitable values to the port, a delay between each write sets the speed. These are not SBCs. They are microcontroller/SOC demo boards and should be treated as such. They aren't really intended for high level languages, never mind ethernet - the Raspberry Pi does a far better job, even if you have to add more I/O. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| knivd Regular Member Joined: 07/09/2014 Location: United KingdomPosts: 71 |
Regarding the Ethernet, I know it is quite complex (much more than if a sane person would have to design it properly), but I would also argue that many existing implementations have been made and working fine on much weaker hardware, down to even some Arduinos. Yes, some libraries use external hardware controllers, such as those from Wiznet or ENC28J60, but there are others who work directly with the built-in controllers, so I guess it could be possible to work without an underlying OS. But to be honest, I have not investigated this in depth, so my assumptions may very well be wrong. As to the steppers, it is easy when doing it as a very rough control with full steps. When start dealing with the finer microsteps and control curves, then things become far more complicated for simple routines in mmbasic. That's why companies make thos advanced stepper controllers. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
For motion control, it would be nice to have the QEI functionality. I have no use for open-loop stepper motors because, for me at least, "control" = command/verify/correct. Not "hit-n-hope" The H7 + MMBasic can handle a reasonably fast PID and a discretized trajectory profiler. "Settick" appears to be easily up to the "real-time" bit. |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3009 |
It's not the same as integrated firmware, but for UDP, it's not hard for a 'mite to send serial to an ESP-01 running Annex RDS basic, and have it send and receive UDP messages. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
I did TCP to a web API using a 8266. It was fairly straightforward but when I look at the code now I can see a great many areas I could improve things (I was still quite new to MMs and it shows!). The SMS gateway which used that software ran for several years without any problems until made redundant,but I would prefer wired ethernet for such as wifi is a bit, well, you know... not for infra based devices. I did look at the ENC28J60 but it is dizzying so I went for the very-much-simpler-to-talk-to ESP8266 which is frankly a joy to work with, despite it being wifi (meh) and it having an inconsistent way of reporting success/failure for any instruction - it feels (using a modified Hayes AT command set) like it was intended to talk to a terminal where a human would instantly make sense of things but scraping it for a program is un-necessarily hard work. Edited 2021-09-14 03:08 by CaptainBoing |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8567 |
USR-TCP232 |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
ah yes, I have seen those but I think I already had a working ESP-based jobby when that came to my attention. I think I may actually have one which I got to investigate but lack of impetus has seen it lie in a draw somewhere since. Maybe this is the spur I need to have another look. EDIT: No it's Part Name: WIZNET W5100 ETHERNET MODULE Qty: 2 Datasheet Location: CASE 01 apparently Edited 2021-09-14 03:13 by CaptainBoing |
||||
 Print this page |
